proj2rubric
Self-assessment rubric for a Slack bot project, scoring 22 criteria with evidence links and a total of 88 points.
What this file does
Self-assessment rubric for a Slack bot project, scoring 22 criteria with evidence links and a total of 88 points.
When to use it
- Evaluating your own project against a predefined rubric
- Demonstrating team contributions and tool usage for a course
- Tracking progress on documentation, testing, and automation
- Preparing evidence for a project review or grading
Assumes this stack
| Notes | Self Assessment (Total: 88) | evidence |
|---|---|---|
| Old video | 3 | https://drive.google.com/drive/folders/1JQZsTSv1vNGJiJ4E64Xy0iwKvI64dEz1?usp=sharing |
| Video1 | 3 | https://drive.google.com/file/d/1jt4zNkIMLOoiRRTW-KtmPWn4T0QnvQ8f/view?usp=share_link |
| Bonus: Xfold improvement | 3 | we now support millions of users as we have moved the bot to the cloud. Earlier in project 1, the bot was being run locally. Moving to the cloud gives several advantages like Availability, Fault tolerance and auto scaling. Our application is hosted on digital ocean that will give all the advantages of the cloud whereas project1 did not. Additonally, now the database size is not limited by the local machine's SSD size. Cloud gives the flexibility on databse size and it can auto scale based on load. |
| 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 | GH Insights |
| Number of commits | 3 | From GH Insights |
| Number of commits: by different people | 3 | From GH Insights |
| Issues reports: there are many | 3 | Total issues |
| Issues are being closed | 3 | closed issues |
| DOI badge: exists | 3 | Visible in README |
| Docs: doco generated, format not ugly | 3 | Docs exist |
| Docs: what: point descriptions of each class/function (in isolation) | 3 | Autogenerated docs using sphinx docs present . Go to docs/build/html directory for viewing documents in html format. |
| Docs: how: for common use cases X,Y,Z mini-tutorials showing worked examples on how to do X,Y,Z | 3 | Detailed working demos present in README present |
| 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 | Evident in README |
| Docs: short video, animated, hosted on your repo. That convinces people why they want to work on your code. | 2 | please refer video links at the top of page |
| Use of version control tools | 3 | GH |
| Use of style checkers | 3 | Use of https://peps.python.org/pep-0008/ along with VsCode/PyCharm internal tools and plugins. We also used autopep8 for auto formatting code. |
| Use of code formatters. | 3 | Use of https://peps.python.org/pep-0008/ along with flake8, VsCode/PyCharm internal tools and plugins for pep8. We also used autopep8 for auto formatting code. |
| Use of syntax checkers. | 3 | Use of https://peps.python.org/pep-0008/ along with VsCode/PyCharm internal tools and plugins. We also used autopep8 for auto formatting code. |
| Use of code coverage | 3 | Visible in workflows and code-cov badge |
| Other automated analysis tools | 2 | Yes we used flake8, black and lint when writing code in pyhcarm and vs code |
| Test cases exist | 3 | Test cases present |
| Test cases are routinely executed | 3 | Visible in workflow |
| The files CONTRIBUTING.md lists coding standards and lots of tips on how to extend the system without screwing things up | 3 | CONTRIBUTING.md |
| Issues are discussed before they are closed, even if you discuss in slack, need a sumamry statement here | 3 | closed issues |
| Chat channel: exists | 3 | slack channel |
| Test cases: a large proportion of the issues related to handling failing cases. | 3 | Visible in issues |
| Evidence that the whole team is using the same tools: everyone can get to all tools and files | 3 | Visible in insights |
| Evidence that the whole team is using the same tools (e.g. config files in the repo, updated by lots of different people) | 3 | Visible in insights |
| 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 | Visible in commits |
| Evidence that the members of the team are working across multiple places in the code base | 3 | Visible in GH individual file contributors |
| Short release cycles | 3 | GH Releases |
What's inside
One table with 22 rows, each containing a criterion, score, and evidence URL.
Change this for your project
- Replace
nihar4276/slackpoint-group18with your own repository name - Replace
https://drive.google.com/drive/folders/1JQZsTSv1vNGJiJ4E64Xy0iwKvI64dEz1?usp=sharingwith your own video link - Replace
https://cscgrad.slack.com/archives/C04AK8WCY13with your own chat channel link
Where it goes
Keep it in your repository where the agent or team that needs it will read it.
Worth borrowing
- Using a single table to map rubric criteria to evidence URLs for easy verification
- Including a self-assigned total score to summarize compliance
Related Documents
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.
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.
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.
QualRubric
Defines a qualitative rubric for PhD qualifying exam presentations, focusing on context, organization, and knowledge demonstration rather than numerical scoring.