home | syllabus | groups | moodle | video | review | © 2022
This project has the same structure as Project1.
Important Notes:
- Copy the following rubric to a markdown file. Fill it in. Where needed, add links into your repo to justify your answers. And that document to your repo as docs/proj2rubric.md.
- The following table has two new rows (see last two)
- We are need to see a significant improvement in Project2, compared to Project1. So some of these rows score much more than the others.
Prepare a markdown with three columns:
- Column1 has all the following points PLUS all the points from the Software Sustainability Evaluation.
- Column2 is your self-assessment. For each items, score yourself zero (none), one (a litte), two (somewhat), three (a lot).
- Column3 is for any links you are adding to support your claim in column two.
- At the top, show the sum of column2,
| Notes | evidence |
|---|---|
| Video1 | Very important: A 5min video of new functionality, showing a significant delta from old. |
| Bonus: Xfold improvement | In some aspect of the code; theoretical complexity, runtime, memory, developer time... |
| Docs: what: point descriptions of each class/function (in isolation) | |
| Use of style checkers | config files in GH showing your config |
| Use of code formatters. | config files in GH showing your this formatter's config |
| Use of syntax checkers. | config files iin GH showing this checker's config |
| Use of code coverage | config files in GH |
| Other automated analysis tools | config files in GH |
| 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) | evidence in GH |
| Number of commits | in GH |
| Number of commits: by different people | in GH |
| Issues reports: there are many | |
| Issues are being closed | evidence in GH |
| DOI badge: exists | in GH |
| Docs: doco generated, format not ugly | in GH |
| Docs: how: for common use cases X,Y,Z mini-tutorials showing worked examples on how to do X,Y,Z | doc page entries |
| Docs: why: docs tell a story, motivate the whole thing, deliver a punchline that makes you want to rush out and use the thing | |
| Docs: short video, animated, hosted on your repo. That convinces people why they want to work on your code. | |
| Use of version control tools | |
| Test cases exist | dozens of tests and those test cases are more than 30% of the code base |
| Test cases are routinely executed | E.g. travis-com.com or github actions or something |
| The files CONTRIBUTING.md lists coding standards and lots of tips on how to extend the system without screwing things up | |
| Issues are discussed before they are closed | even if you discuss in slack, need a sumamry statement here |
| Chat channel: exists | Link or screenshots |
| Test cases: a large proportion of the issues related to handling failing cases. | If a test case fails, open an issue and fix it |
| Evidence that the whole team is using the same tools: everyone can get to all tools and files | |
| Evidence that the whole team is using the same tools (e.g. config files in the repo, updated by lots of different people) | |
| 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) | |
| Evidence that the members of the team are working across multiple places in the code base | |
| Short release cycles | (hard to see in short projects) project members are committing often enough so that everyone can get your work |