Repository Management: Mention assigning pull requests to milestone #5887
Conversation
|
Mentioned in the thread, I'm ok trying this, but I fear I'll still be looking at all changes occurred since last release to compile changelog and that I won't look at the milestone in fear it's not exhaustive. |
| @@ -115,6 +115,8 @@ A pull request can generally be merged once it is: | |||
|
|
|||
| The final pull request merge decision is made by the **@wordpress/gutenberg-core** team. | |||
|
|
|||
| Please make sure to assign your merged pull request to its release milestone. Doing so creates the historical legacy of what code landed when, and makes it possible for all project contributors (even non-technical ones) to access this information. | |||
There was a problem hiding this comment.
To be clear, this doesn't "create" a history; "surfaces" might be more accurate phrasing. The history already exists regardless, and the milestoning could be retroactively applied at any time (which may be interesting for the thousands of existing pull requests which could be milestoned to existing releases).
There was a problem hiding this comment.
This change is a good idea, it's a minor amount of effort on the part of the person merging the PR, and it provides a much simpler historical view of changes made in a given version.
This is similar to the Core process, all tickets are milestoned to the release they were closed in. As Gutenberg shifts from being a plugin to a Core feature, this process will become a requirement, rather than just a convenience for the person writing the Gutenberg release post.
@WordPress/gutenberg-core: when you're merging PRs from now on, please milestone them if they're not already. It'll take a little bit of practice, so don't worry if you forget. We can double check for each other. 🙂
|
👍 |
|
@pento we have work that is tracked in non-version milestones, like "Feature Complete", which we use to keep track of progress at a higher level. Not sure it would make sense to reassign those as we lose the ability to check the feature complete milestone, for example. |
|
Do we need to check the Feature Complete milestone for things that have been completed? If so, it seems like a Label would be better suited for this purpose, so we can group Feature Complete issues/PRs by when they landed. |
See conversation in #5858 (comment)