New issue management guidelines #1386
Conversation
Added new issue guidelines.
There was a problem hiding this comment.
Oops, I had a few comments written here, but forgot to click submit, and @unman merged it the meantime...
Anyway, here are the comments, we can still discuss here I guess, but changes will need to go into a new PR
|
|
||
| An issue should also have a rough estimate how much time it needs, if it's more than one-two days. Of course this might be updated later, if an issue turns out to be more (or maybe less) complicated than it has initially seemed. | ||
|
|
||
| When an issue is done (that is, the completion checklist has been completed), the issue should be moved to **ready** column in the *Current team tasks* project. |
There was a problem hiding this comment.
When the code is completed and waits for review, it should be moved to "in review". When all is merged, it should be moved to "done". Did you meant here moving to "ready" after adding the checklist to the issue description? I'd say it's a condition necessary but not sufficient - issues can be moved to "ready" only when they have the checklist prepared (if applicable, as in, when not clear already in existing description of a bug). But also, issue must not be blocked on anything else to be moved there.
|
|
||
| ### Working on an issue | ||
|
|
||
| Every issue should involve a clear statement of success: when is the issue finished? It might not be clear to the person making the issue, especially if it's an enhancement request, but before work starts, the person working on the issue should make sure that it includes clear completion criteria in the description (via editing the description, if necessary). The completion criteria would ideally be a checklist, and consist of a list of pull requests/features, each preferably no more than two weeks of work. It's also important to remember tests and documentation should also be part of the issue, if applicable. |
There was a problem hiding this comment.
This paragraph is a bit chaotic... But also, should we specify how such section checklist should be named? Or maybe add some skeleton (or placeholder) to the enhancement issue template?
There was a problem hiding this comment.
But also, should we specify how such section checklist should be named?
Do you have a preference for that section heading?
Or maybe add some skeleton (or placeholder) to the enhancement issue template?
Yeah, it makes sense to do that instead of having each person type it manually every time. (Also helps to remember to fill it out.)
There was a problem hiding this comment.
Do you have a preference for that section heading?
"Tasks"? "Work items"?
There was a problem hiding this comment.
Done: QubesOS/qubes-issues@a28f422
I went with "Completion criteria checklist" for clarity and consistency with the language in this paragraph.
|
|
||
| ### Assigning issues | ||
|
|
||
| To avoid a situation where an issue is "dead" - assigned to someone who is not actively working on it - and to help the team organize their work, an issue should be assigned to a person who currently works on it, or will start working on it in a very near future (about a week or two). One person can have several issues assigned at the same time (for example they may be working on one another issue while waiting for review), but if an issue is no longer actively being worked on (for example when it's blocked by something else), it should be unassigned. At that point, if there is some partial work already done, there should be a comment about that, including link to the code (some WIP commit in some branch?) if applicable. |
There was a problem hiding this comment.
Maybe break the first sentence into two?
Added new issue guidelines.