We now have only one release milestone, which will be labelled "next release" as long as the version number of the next release hasn't been determined. Once that has happened, it will be renamed to the version number (using the "vX.Y.Z" scheme). Of the open issues/PRs only those deemed mandatory/required for the release get assigned to that milestone. Issues/PRs that are only "optional" won't get a milestone, so being optional for the release will be indicated by not having a milestone (which is the default, obviously).
Distinguishing between issues/PRs that don't need a milstone (like those infrastructure issues/PRs), issues/PRs that are optional, and issues/PRs where a decision about if they are mandatory or not hasn't been made yet won't be done anymore (which shouldn't be a problem, I don't think that has made much of a difference in the past).
When an "optional" issue/PR (which hasn't been assigned to a milestone yet) gets closed/merged, it must get a milestone assigned at that point. When that happens, there are two different cases:
- In case the release branch for the next release hasn't been created yet, it gets assigned to the release milestone ("next release"/"vX.Y.Z"), as all issues/PRs resolved/merged at that point are going to be part of the next release.
- If the release branch for the new release has already been created, it depends on if the fix for the resolved issue or the merged PR becomes part (gets cherry picked into) the release branch. If yes, assign the issue/PR to the release milestone. If not, assign it to a "post release" milestone that gets created together with the release branch (giving the "post release" milestone a different meaning than it had until now!).
To help with prioritizing of issues/PRs within their assigned milestones, two new labels have been introduced: "priority:high" and "priority:low" (the "labels.md" file which contains the descriptions of the different labels and their categories has already been updated accordingly). Use these to tag certain issues/PRs as of especially high or low importance/urgency. "Standard"/"normal"/"medium" priority will be indicated by not having a "priority" label assigned, which is obviously the default and should apply to the majority of issues/PRs.
Typical "high priority" issues/PRs would be critical/game breaking bugs or the main features of the next/upcoming release. As much as possible and reasonable, such issues/PRs should receive the attention of developers and contributers first, before turning to other stuff.
Typical "low priority" issues/PRs would be cosmetical bugs, bugs that are more of a minor annoyance than something that actually impedes gameplay, nice-to-have but not really important feature requests etc. In short things that can, and in certain cases like when we are in the stage of rolling out another stable release, even should be set aside for more important stuff (so they don't consume valuable dev manpower when it's needed elsewhere).
I guess it would be good to put this explanation/description somewhere we can easily refer people to (having it only here, buried a thread, might not be enough). Any suggestions? A wiki page perhaps?
For the upcoming 0.4.9 release I've already created the corresponding milestone and, in a first pass, assigned all issues/PRs I deemed important for that release to it (as well as all issues/PRs that have been resolved/merged since 0.4.8 of course). I then removed the old "next release" milestone from all other issues/PRs and deleted it, so those "optional" issues/PRs are, as intended, without milestone now.
Except for one of my old issues, I haven't assigned any priority labels so far. Feel free to assign those to issues/PRs as you see fit.
If you have any questions, comments, objections, corrections, ideas - feel free to post them here.