Back to .md Directory
proj2rubric
Scores a project against a 30-point rubric covering documentation, testing, tooling, and team collaboration.
ai rag workflow
View sourceWhat this file does
Scores a project against a 30-point rubric covering documentation, testing, tooling, and team collaboration.
When to use it
- Grading a software engineering project submission
- Evaluating your own repo against a standard rubric
- Reviewing a pull request for completeness
Repository link: https://github.com/agupta15k/ncsu_se_fall22_22_pr_2
Total Score: 83
| Notes | Points | evidence |
|---|---|---|
| Video1 | 3 | Video can be found here |
| Bonus: Xfold improvement | 2 | We have tackled scalability from various avenues. First we added a functionality to onboard new doctors and hospitals allowing for a higher availability of the application. Also, we tackled scalability from the perspective of time spent by a customer. Previously, when user wanted to book an appointment, it'd have taken over a minute, but now it takes 18 seconds. |
| Docs: what: point descriptions of each class/function (in isolation) | 3 | Frontend and Backend 'what' documentation exists |
| Use of style checkers | 3 | Using eslint for frontend and flake8 for backend |
| Use of code formatters. | 3 | Using default code formatters provided by vscode. Some formatting configuration present in the .vscode folder |
| Use of syntax checkers. | 3 | Using eslint for frontend and flake8 for backend |
| Use of code coverage | 3 | Codecov badge present. Codecov run automatically using Github Actions |
| Other automated analysis tools | 3 | Github actions used for frontend and backend |
| Workload is spread over the whole team (one team member is often Xtimes more productive than the others but nevertheless, here is a track record that everyone is contributing a lot) | 3 | Responsibilites of individual modules were deligated to different subgroups, thus all of the group members have contributed to the project. Contributors |
| Number of commits | 2 | There are a total of 446 commits in the repo while 90 were done only for project 2 |
| Number of commits: by different people | 3 | The number of commits are balanced across all contributors |
| Issues reports: there are many | 2 | Most of the discussion happened over meetings and chat channels, thus not a lot of issues were needed |
| Issues are being closed | 3 | All open issues are closed |
| DOI badge: exists | 3 | DOI badge exists |
| Docs: doco generated, format not ugly | 3 | Documentation present |
| Docs: how: for common use cases X,Y,Z mini-tutorials showing worked examples on how to do X,Y,Z | 3 | Execution screenshots can be found here. Video showing the execution is also available |
| Docs: why: docs tell a story, motivate the whole thing, deliver a punchline that makes you want to rush out and use the thing | 3 | 'why' documentation present in the README file |
| Docs: short video, animated, hosted on your repo. That convinces people why they want to work on your code. | 3 | Video and execution screenshots available |
| Use of version control tools | 3 | Git is used in this project |
| Test cases exist | 2 | Dozens of test cases exist |
| Test cases are routinely executed | 3 | Github actions used |
| The files CONTRIBUTING.md lists coding standards and lots of tips on how to extend the system without screwing things up | 3 | Descriptive CONTRIBUTING.md file present |
| Issues are discussed before they are closed | 2 | Closed issues do have little discussion |
| Chat channel: exists | 3 | Private chat channel exists, some discussion screenshots can be found here |
| Test cases: a large proportion of the issues related to handling failing cases. | 1 | Some issue related to failed test cases discussed |
| Evidence that the whole team is using the same tools: everyone can get to all tools and files | 3 | All the code is in github. The dependency closure is available for both frontend and backend. Also, vscode IDE configuration present |
| Evidence that the whole team is using the same tools (e.g. config files in the repo, updated by lots of different people) | 3 | vscode IDE configuration present |
| Evidence that the whole team is using the same tools (e.g. tutor can ask anyone to share screen, they demonstrate the system running on their computer) | 3 | Everybody contributed to development |
| Evidence that the members of the team are working across multiple places in the code base | 3 | Though the responsibility of developing the modules was divided among team members, everybody contributed to the code base, design, testing, and documentation. |
| Short release cycles | 3 | There are regular commits on the repository |
What's inside
30 rubric rows with points, notes, and evidence links
Change this for your project
- Replace
agupta15k/ncsu_se_fall22_22_pr_2with your own repository link - Replace
Shubham1309Jain/WolfCarewith your own repository name - Update evidence URLs to point to your own docs, videos, and screenshots
Where it goes
Keep it in your repository where the agent or team that needs it will read it.
Worth borrowing
- Rubric as a Markdown table with evidence column for each criterion
- Bonus points for measurable improvements (e.g., appointment time reduced from 60s to 18s)
Related Documents
RUBRIC.md
AICA PRD Quality Rubric
Defines a 10-dimension scoring rubric (0-5 each) to evaluate and create PRDs, with a target score of 36+ for agent-driven implementation.
aiagentllm
0
4
lucasblimaRUBRIC.md
Judging Rubric
Defines a 100-point scoring rubric for an AI-for-social-good hackathon, covering five criteria with detailed score bands and tie-breaking rules.
aievalworkflow
0
3
rudra496RUBRIC.md
Liscribe v2 — Rubric of Success
Defines the complete UI specification, success criteria, and non-negotiable principles for a macOS transcription app with three independent workflows.
airagworkflow
0
3
LenniottRUBRIC.md
QualRubric
Defines a qualitative rubric for PhD qualifying exam presentations, focusing on context, organization, and knowledge demonstration rather than numerical scoring.
aieval
0
3
adsarwate