There has been discussion in other threads about how the project is managed and how issues are reported and tracked. I am opening this topic to allow us to discuss the issue tracking methodology and (hopefully) agree a process.
@jofemodo manages the GitHub project and has set up repositories (with issue trackers), projects and kanban boards. I think we should have:
- Process for reporting and tracking issues
- Process for updating issue status (kanban board)
- Identify roles
- Describe what each issue (kanban) status means
- Specify which roles nominally perform which tasks
I started to draft some of this out for discussion. I have created flowcharts for the kanban (which I think needs an extra column for backlog) and initial triage process which are attached to this post.
I think we need these roles:
- Project Manager - overall control of the project
- Defect Manager - responsible for overall issue progress
- Team Member - anyone with permission to alter issue status
- User - anyone who reports issues or contributes to issue resolution
Note that roles are not necessarily mapped to individuals, i.e. one person may have multiple roles and one role may be performed by multiple people.
The kanban flowchart shows the role that is nominally responsible for moving tickets between columns. The rectangular blocks represent kanban columns.
It is possible for tickets to be moved back to Backlog, e.g. if progress has stopped, maybe due to a team member being unavailable or deciding they are unable to progress the issue.
The initial triage process shows how a new ticket is reviewed and added to the kanban board. Colour indicates who performs each task.
I think we should have these types of ticket:
- Defect / Bug - An issue with the product or supporting tools which impairs normal functionality
- Feature / Enhancement - A change to functionality
- Other - Anything that may not directly require change to the product or supporting tools, e.g. a discussion topic - though these should really be directed to Discourse
I think we should have issue status that aligns with the kanban columns. We should be able to mark a ticket as resolved / done (I prefer resolved) to indicate that the team has offered a resolution to the original reporter (or community at large).
It may be advantageous to have a resolution type which might include:
- Won’t Fix
- Cannot reproduce (which may be covered by Invalid if we want to avoid subtle differences)
GitHub only really provides tags for indicating status so team members will need clear guidance on what tags represent what status and which tags are mutually exclusive, e.g. there should only be one resolution type.
I know this kind of thing can look complex / labour intensive / process heavy but may I assure you that having a consistent set of processes improves quality of issue reports and improves productivity. The trick is to get the minimal process that works and to adjust (and update docs) in light of experience.