[WIP] Issue management process #16
Conversation
This document attempts to define a standard process for the BOINC community to use in creating and managing issues in Github.
| Issues should be reviewed prior to development beginning on them. Other members on the BOINC community should look for issues that have not been reviewed and determine, if they are able, whether an issue is suitable for development now, in the future, or not at all. The following labels determine the review status: | ||
| - Verified: a good candidate for current development | ||
| - Discussion Needed: bring up on the BOINC Contributors call for discussion | ||
| - Parked: likely to be a candidate for development in the future, but not now |
There was a problem hiding this comment.
I think that parked mixes status and prioritization. We have the labels P: and E: for prioritization and estimation respectively. This should be mentioned here in the document. Whether an issue is being working on is more to do with someone's willingness to get it done rather than someone else's judgement on the issue. Discussion is really Needs Consensus, discussion is just part of that, a vote could be another approach. I recently started using the label validate for issues that need testing.
| ## 2. Use Cases | ||
|
|
||
| ### 2.1 New Contributor | ||
| A user looking to make first contributions to the BOINC community can use the "good first issue" label to find a list of issues that the community has deemed to be friendly ways to get involved and learn some of the ins and outs of BOINC development. |
There was a problem hiding this comment.
I started using the label Newbie for this purpose. Should I change the label in git or should we change the label in the document?
| ### 2.4 Tracking Release Status | ||
| The release manager for the client or server software can use a milestone for a specific release version and add issues to that milestone that should be included in the release. All issues that have been resolved as part of a pull request to the master branch after the previous release branch was cut should already be included in this current release milestone, so the release manager can see the history of all changes that are being included. | ||
|
|
||
| ### 2.5 Stalled Issues |
There was a problem hiding this comment.
I am not sure that this is required and also misses an important point. It is not how old the issue is but a combination of factors such as priority, impact, estimation etc. that determines if an issue is overdue for being addressed.
First draft at describing the standard procedures for managing issues. Work in progress, changes welcome.