Our GitHub Issues Process Until the Release of 4.0

[Tantacrul]

Thought I'd very quickly outline how we're working with GitHub issues until the release of 4.0

Our main goal over the coming weeks is to reduce the amount of time it takes for a developer to get started on an issue by making sure it is succinctly and clearly described as well appropriately tagged. We hope that this will help us to improve our velocity for solving issues over the next few weeks.

However, I'm aware that some aspects of our process are a little unclear, so I'll just state a few points here. Please let me know what you think and I'll modify them accordingly until everyone is happy.

1. We use GitHub issues to organise the upcoming release only. In this case, 4.0.
2. Once we determine that a bug should be fixed in 4.0, we assign it either to Alpha 2, Beta 1 or Beta 2. With a few exceptions, issues we target at Alpha 2 are the ones we deem to be most critical
3. Most issues will be assigned to @vpereverzev who then reassigns a few of them to internal team members each week
4. Community members are still encouraged to work on an issue, even if they are assigned to an internal team member. All you need to do is ask - and if we're not actively working on it and deem it to be appropriate - we will reassign it over to you
5. Sometimes we mark bugs with a Community tag. This is when we suspect the issue is relatively straight-forward to fix - Something not too taxing for those who just want to jump in and contribute something small over an evening, say. However, we are now realising that this tag is confusing to some community members because it implies that we don't want them to work on issues that don't have a Community tag. To be clear - if you think you can easily fix it, please feel free!
6. Issues marked with a 'Sprint' milestone are earmarked for internal team members to work on. If you'd like to work on one of these issues, you can ask the internal developer whether they are happy to transfer it to you, which they may or may not do, depending on the circumstances
7. We use the good first issue tag to mean that the issue is very simple to fix. These are issues that new members can take on just to get a feel for the project and our processes. String changes are a typical example of a good first issue
8. Feature requests and issues that we think should be pushed back until a later release will be closed and tagged as 4.x. These issues are kept in a place where we can assess them once 4.0 is out. Doing this keeps the list of issues down and help us not get distracted by ongoing conversations on these issues. By keeping the list of issues down, it also helps reduce the amount of reading and searching everyone has to do
9. In general, we're trying to dissuade people from engaging in extended discussions on "expected behaviour" in GitHub issues to avoid confusing / overloading the developer tasked with resolving it. Once the correct expected behaviour has been determined, we will often remove many of the comments and updated the issue description to reflect any consensus reached. I've written a short post about this point here: https://musescore.org/en/node/331750