🧰 Task
We are currently rethinking how milestoning works, especially for napari/napari.
We are starting to settle on not adding a milestone as a way to "track" the priority of PRs because this overloads the milestone with too much responsibility. Instead, the milestone should be added only if it's specifically either blocking release or is explicitly targeted for the upcoming release.
In addition, merge is no longer blocked by absence of a PR (but remains blocked if it's a milestone that is not the current one) and the milestone will be added after merge, in order to emphasize that milestoning is not how we track.
However, if we continue in this trajectory we need to find a way to siginal high priority issues and PRs. We have started using the "napari milestone" to know how to prioritize other needed changes, such as in napari-plugin-manager or npe2
Also, milestoning is not automatic on merge in napari/docs so our workflow here is out of sync with napari/napari cc: @Czaki
🧰 Task
We are currently rethinking how milestoning works, especially for napari/napari.
We are starting to settle on not adding a milestone as a way to "track" the priority of PRs because this overloads the milestone with too much responsibility. Instead, the milestone should be added only if it's specifically either blocking release or is explicitly targeted for the upcoming release.
In addition, merge is no longer blocked by absence of a PR (but remains blocked if it's a milestone that is not the current one) and the milestone will be added after merge, in order to emphasize that milestoning is not how we track.
However, if we continue in this trajectory we need to find a way to siginal high priority issues and PRs. We have started using the "napari milestone" to know how to prioritize other needed changes, such as in
napari-plugin-managerornpe2Also, milestoning is not automatic on merge in
napari/docsso our workflow here is out of sync withnapari/naparicc: @Czaki