-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense to me.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and we especially welcome external contributions as these milestones...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty good to me! I suggest some small changes, but overall this is very useful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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