Re: PR Milestone policy
> we should try to assign milestones to PRs we want
> to get in
Can you please define “we”? Do you mean committers, PMC members, release managers, everyone?
> On Nov 26, 2018, at 8:43 AM, Roman Leventov <leventov@xxxxxxxxxx> wrote:
> About a year ago, Gian wrote (
> "For milestones, I think it would work to use them only for PRs/issues that
> are truly release blockers -- should be limited to critical bugs discovered
> after a release branch is cut. We could make release notes the way you
> suggest, by walking the commit history."
> Today, Fangjin wrote (
> "I think where possible we should try to assign milestones to PRs we want
> to get in and aim to have the PR reviewed and merged before then. If the PR
> needs to be pushed back to a future release we can always do that."
> Personally I don't agree with the second take and differentiating non-bug
> fixing PRs by their "importance". I think the proportion of PRs that are
> assigned the next milestone by committer will depend on self-confidence of
> the committer and politics, not the objective importance of the PRs. It
> will also make possible for some minor PRs to be sidetracked for extremely
> long time if not forever, because there always other more important PRs to
> work on. While true in the short and mid run, this is very frustrating for
> the authors and could turn them away from contributing into Druid, that is
> bad in the long run. Actually this thing happens already sometimes and we
> should think how to address that, but differentiating PRs could
> only exacerbate this effect.
> Instead, I think the importance of PR should grow with the time passed
> since the author addressed all comments (or just created the PR) and the PR
> passed automated checks. I. e. a freshly created PR may be not super
> important, but if it passes all checks and is open for two months without
> reviews, the PR becomes more important to review. This should help to
> reduce the variance in PR's time-to-merge and improve the average
> contributor experience. In the long run I think it's healthier than
> squeezing one extra feature into the very next release.
To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxx