Github issue labels and milestones

Development
1

I’ve updated the documentation on issues and milestones. Please take note of the recent changes:

  • The good-first-issue label is new, so that we follow the Github standard on this. (Previously we had easy.)

  • The unreleased label should only be added to issues (not pull requests) that represent bugs never seen in a released version. That is, only when we introduce a problem in an RC, file an issue, and resolve that issue before the full release. The only purpose of this label is to tell my scripts “do not include this in the release notes”.

  • There are now milestones for each release. These are essentially auto generated, I have a script that creates them and adds issues (referenced by “fixes #…”) as appropriate. As a final step before release, a script generates the changelog based on these milestones.

As a side effect of the per-release milestone stuff it’s also easy to just look at a resolved issue and see which release it went into. That’s helpful.

Also please help me consider the following: the “Planned” and “Unplanned” milestones are essentially worthless. The original intention was good, but

  1. We don’t actually plan to any real extent, so “Planned” is unused.
  2. Hence everything gets thrown into the “Unplanned” milestone.
  3. When someone asks if something is ongoing or going to be fixed they get a variant of “no, idiot, it’s Unplanned!” as reply.

None of this seems helpful.

A side use case for the milestones (for me, at least) was to track issues that had been triaged and accepted. This is probably covered perfectly fine by just the enhancement/bug issues.

Remove? Other suggestions? I was apparently thinking about this last year as well but we didn’t do anything about it then.

2

I agree that planned and unplanned milestones are worthless if nothing is actually planned. I do not think there is a need for more planning unless additional developers emerge from the woodwork.

1 Like