| 3 |
short release cycles |
in GH |
| 3 |
workload is spread over the whole team (so one team member is often Xtimes more productive than the others... |
in GH |
| 3 |
Docs: why: docs tell a story, motivate the whole thing, deliver a punchline that makes you want to rush out and use the thing |
README.md, Improvements.md and Software Documentation |
| 3 |
the files CONTRIBUTING.md lists coding standards and lots of tips on how to extend the system without screwing things up |
in GH |
| 3 |
Docs: doco generated , format not ugly |
in GH |
| 3 |
evidence that the whole team is using the same tools (e.g. config files in the repo, updated by lots of different people) |
in GH actions |
| 3 |
evidence that the members of the team are working across multiple places in the code base |
in GH |
| 3 |
Docs: what: point descriptions of each class/function (in isolation) |
in Software Documentation |
| 3 |
Number of commits: by different people |
in GH |
| 3 |
issues are being closed |
evidence in GH |
| 3 |
issues are discussed before they are closed |
in issue comments |
| 3 |
Use of syntax checkers. |
Super Linter in Github actions |
| 3 |
Issues reports: there are many |
in GH |
| 3 |
Use of code formatters. |
Super Linter in Github actions |
| 3 |
Use of style checkers |
Super Linter in Github actions |
| 3 |
Docs: short video, animated, hosted on your repo. That convinces people why they want to work on your code. |
in README.md |
| 3 |
test cases exist |
in test_app.py |
| 3 |
Use of code coverage |
in GH |
| 3 |
other automated analysis tools |
Super Linter in Github actions |
| 3 |
test cases:.a large proportion of the issues related to handling failing cases. |
in GH |
| 3 |
test cases are routinely executed |
github actions |
| 3 |
Documentation describing how this version improves on the older version |
Improvements.md |
|
This version is a little(1), some(2), much(3) improved on the last version. |
Tutor's assessment. |
|
Total |
|