About a year ago, Gian wrote ( https://groups.google.com/forum/#!msg/druid-development/QPZUIzLtZ2I/eZyw8BoVCgAJ ):
"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 ( https://github.com/apache/incubator-druid/pull/6656#issuecomment-441698159): "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.
