Curation: quick checklist

Quick checklist of some of the most important things that should be true before a repo can be marked READY

The purpose of the repo

  1. If the project is a game, is there a clear “point” to the game, i.e. an object to the game that makes it fun to play?
    If there is not, is there a clear path towards one? (If there is not, strongly consider retiring the repo to the icebox!)
  2. Similarly, if the project is not a game, is there a clear set of user stories for the project, that make sense? That is, is it plausible that someone would actually want to use this piece of software to do something? If not, is there a clear path towards one? (If there is not, strongly consider retiring the repo to the icebox!)

Note: depending on how many projects we need, we may not be able to retire all of the projects that have no clear point other than to be a “toy example project” for CMPSC 56. But eventually, we should try to move towards projects that have a meaningful purpose and reason to exist.

Housekeeping items

  1. Is EVERY outstanding pull request dealt with in some way, either closed or accepted? (That is, there should be no “open” pull requests.)
  2. Does EVERY issue have a point estimate for the CURRENT quarter?
    • Even if there is an estimate from a previous quarter (e.g. if this is W18 and there is an estimate from F17) you STILL need to review that estimate and add, for example, “W18 200 pts” as a comment by a current mentor.
    • Students SHOULD NOT expect points for any issue that doesn’t have a CURRENT QUARTER ESTIMATE from a mentor or instructor.
    • When curating the repos, all issues should be approved and given re-estimated point values or CLOSED (if the issue has been implemented/resolved) before the repo is ready.
    • If there’s an open issue from a previous quarter that’s mostly been implemented but has some bugs, close that issue, then open new issues for those bugs, with appropriate point estimates.
  3. Are there at least 1000 points worth of issues for students to complete, preferably more?
  4. If it is a Java Swing project, is there an issue to migrate it to JavaFX?
  5. Are there issues to add code coverage measurement, and increase the code coverage measurement?

  6. Is the Javadoc published correctly (i.e. is there a clear, easy to identify link to the javadoc from the README.md), and if not, is there an issue to address this?

  7. NEW: Is there an Issue Template. TODO: Come up with a standard issue template for CS56 projects.