I’m new to GitHub milestones, but this plan seems reasonable. I’ve long wanted a lightweight way to focus.
Critical issues with the current canary [2.0.3.9] had a different method, and neither is a fancy tracker tool…
Any time there’s tracking, even just GitHub Issues, there’s a certain amount of administration so let me ask whether initial use starts with self-service honor-system as to what’s added? I hope justification is supplied unless it’s hugely obvious. This would be somewhat similar to promoting a feature request except maybe a feature request would have to work harder if the milestone is already full of critical bugs that need attention.
CheckingErrorsForIssue1400 and FoundIssue1400Error test case, analysis, and proposal #3868 is one I’m pointing to as a possible example of how to justify making the Upcoming beta milestone. It’s much-reported (statistics supplied) and reproducible (steps supplied). Those two make it potentially actionable, but for any near (and I hope it’s near) milestone, the bar may be higher. This one is analyzed to code, and has fix PoC. What is doesn’t have is an assignment (which Brave tries to use). I propose that as a “bonus” for an “Add”.
I also propose that regressions from previous Beta found in Canary or Experimental get on list more easily although not automatically. For a given area, quality should increase, even if initial ship is less than perfect.