This is the first attempt at a proposal for a simple process to document issues raised for the BTR Project Board
To assess and discuss each issue, we need to know:
- The type of issue: is it a bug? is it a gap in documentation?
- The release that is affected.
- The severity of the issue.
Each issue should have at least 3 tags (one of each category):
The name of the release.
I’m conscious that the relationship between severity and priority can raise a lot of questions/discussions. To simplify things my thought process was centred around the question “How difficult does it make installing or running an instance of Open edX?”.
- High: This issue stops the installation or core functionality of the platform and has no workaround.
- Medium: This issue affect a non-core part of the installation or the platform and/or has a workaround.
- Low: This issue doesn’t impact the usability of the platform.
These descriptions are non-exhaustive, it’s safe to say that a security patch should fall under high priority even though it doesn’t impact any functionality.
If in doubt between two levels of priority, assign the highest level and it can be reviewed by other members of the group.
- It is the responsibility of the person creating issue to appropriately describe and tag it (affect, type, priority). The tags can be reviewed and modified by the group.
- It is the responsibility of the Bug triager to link the issues to the appropriate Milestone.
Ideas to improve the experience
- Add a github action to automatically add new issues to the project board.
- Auto-assign new issues to the bug triager.
- Find a way to add a ‘Due date’. I’m not sure how to implement this yet any suggestion is welcome!
I’m planning to issue a weekly update (see next post for an example). This means that until we have a ‘Due date’ system if you have an issue assigned to you, you will get a weekly nudge to provide an update on the issue. Is there any thoughts against that?