Add docs on our roadmap process #4469
Conversation
This formalized publicly some of our discussions around roadmap and issue priority. Fixes #4233
|
cc @RichardLitt You might have some input here, let me know if this clears up all your questions or if I missed anything. |
docs/roadmap.rst
Outdated
| good time to discuss how to address the problem technically. Skipping this | ||
| phase might result in your PR being blocked, sent back to design decision, or | ||
| perhaps even discarded. It's best to be active here before submitting a PR. | ||
| * The core team will only work on accepted issues, and will only give PR review |
There was a problem hiding this comment.
This looks like it discourages drive-by PRs for small items. Should we add a note that if a PR is small enough, you're welcome to file it - we just may not get to it as soon as if you had gone through an issue process?
docs/roadmap.rst
Outdated
|
|
||
| Point release milestones try to remain static, but can shift upwards on a | ||
| release that included an unexpected feature addition. Milestones are normally | ||
| realistic and stick to semver, which means that only one feature addition issue |
There was a problem hiding this comment.
Might be worth explaining what semver is, or pointing to a description using a link. Same for 'point release'.
docs/roadmap.rst
Outdated
| milestones, to ensure your pull request gets attention. You can also feel free | ||
| to contribute on our Cleanup or Refactoring milestones. Though not a development | ||
| priority, these issues are generally discrete, easier to jump into than feature | ||
| development, and these milestones are not a place the core team can justify |
There was a problem hiding this comment.
and we especially welcome external contributions as these milestones...
There was a problem hiding this comment.
Looks good.
I'm concern about the usage of the group milestone, though. I'm not sure that it's right. If so, I've been adding some issues to those milestones that maybe are incorrect.
I personally prefer to use those group milestones without considering that they have priority. To me, they have to be in an Accepted label and under a release milestone to be considered as the upcoming amount of work.
|
|
||
| We maintain two types of milestones: point release milestones for our upcoming | ||
| releases, and group milestones, for blocks of work that have priority in the | ||
| future. |
There was a problem hiding this comment.
Do you think that group milestones are good for future priority?
I think it's good to use them as a way to group related amount of work. The priority will be given by the Accepted label or when the issue is moved from a group milestone to a point release milestone.
There was a problem hiding this comment.
But we have certain planned features and groups of features that have a priority. For instance in the beginning of the year, this was build stability and admin ux -- and still is. This implies that work in these milestones will be first to be added to our releases, instead of randomly applying issues into our point releases.
There was a problem hiding this comment.
Yeah, that makes sense to me. I was wondering about when to add to any of this milestones. I suppose that we should add them if just "the topic matches" without considering any kind of priority.
There was a problem hiding this comment.
With some of our work shifting, and with point releases thinning out a little bit, we'll be leaking more issues into point releases now. It's been heavily leaning toward bug fixes for a while.
This formalized publicly some of our discussions around roadmap and issue
priority.
Fixes #4233