Continuing the discussion from GitHub Gardening - Part 2 - Milestones:
IN PLACE AS OF FRIDAY 27 OCTOBER 2017
Last week @oeoeaio and I had a great session planning out how we’d like to use milestones and labels, and came up with a process for moving things through the pipe to released.
This is the first of 3 topics that I’ll add, and it covers off how we’d like to use milestones (see other topics: how we manage labels and how we manage PRs).
Previously we all agreed to use the GitHub Projects feature to manage project and local instance backlogs, and to leave milestones for managing releases.
From now on we will be following this process for using milestones:
-
We’ll always have a “Current Milestone” milestone set up in GitHub, and this is where anyone merging adds their PRs (only PRs, not the issues).
-
PRs are added to a milestone at the point of merging, not before. This way we don’t have to manually manage what’s in the milestone, moving things from one to the next if they don’t get done.
-
At present only @oeoeaio and @maikel are doing most of the merging, with @enricostn and @lin_d_hop merging more minor changes. It will be the responsibility of these people to add the PR they are merging to the Current Milestone as part of that process.
-
At the end of the month (or when a major release goes out, or an emergency release) whatever is in that milestone will be included in the release and accompanying release notes. Whoever is doing the release will re-label the milestone with the relevant dot point release number and description and will also create a new Current Milestone as a replacement.
