Thats a copy of https://governance.funkwhale.audio/d/XairNQBZ/issue-management
I started working on understanding the process of managing issues and wrote a Draft for me to take some notes and probably for reference in the future. While working on this I noticed some points which might be problems or I just got wrong. I'll write them down to start a discussion or probably get some input to understand better how it is meant to be.
My draft is here: https://pad.funkwhale.audio/Ticket-workflow
Backlog as Milestone
I don't really like managing the backlog in a Milestone. We already have labels representing the status of a ticket and being ready and waiting for implementation is a state. The backlog is just a collection of tickets being ready for implementation. So I'd like to use the already existing label "Status: Ready" as marker for the backlog.
Label "review wanted"
This label is described by "This merge request is needing reviews from other people before being merged". Gitlab supports marking Merge Requests as Work In Progress by adding WIP: as prefix to the title. All MRs not marked as WIP need a review, so I'd suggest to remove this label.
These issues needs to be closed to keep the tracker clean. I don't think there is any advantage in labeling closed issues. I suggest to remove this label.
Types vs Area vs Component
I am a little bit confused by the distinction between type, area and component. It seems like a type describes the work which needs to be done, like fix a bug or built new functionality. The Area seems to describe where the work needs to be done. Maybe its something in the backend, the frontend or working on our CI. The component describes the part of the application from a user perspective.
There are some violations of this differentiation:
- UX/UI and Accessibility aren't types but areas.
- Development isn't a area. Actually I think we don't need this label.
- Moderation isn't a area but a component.
- Performance and Security aren't areas but maybe types.
- Doing should be a Status
- Todo should be a Status, although I think adding a ticket to a milestone should mark this state.
I am aware that my assumptions described above can be wrong. All suggested changes are just ideas of mine I want to discuss, so any feedback is welcome.