simplify support regression escalation process
2 unresolved threads
2 unresolved threads
The last iteration of this was a little wordy and duplicated things from the product resource. Removed the fluff and made it more direct and actionable.
Merge request reports
Activity
Filter activity
mentioned in merge request !5584 (merged)
66 66 67 67 We aim to fix [regressions](/handbook/glossary/#regression) in patch releases, when possible. However, not all regressions are created equal - we will work to patch the high-impact ones first. 68 68 69 For all regressions, add the `~regression` label. For high-impact regressions, 69 Support is responsible for reproducing regressions before labling them as such, and making sure all steps to reproduce are clearly 66 66 67 67 We aim to fix [regressions](/handbook/glossary/#regression) in patch releases, when possible. However, not all regressions are created equal - we will work to patch the high-impact ones first. 68 68 69 For all regressions, add the `~regression` label. For high-impact regressions, 69 Support is responsible for reproducing regressions before labling them as such, and making sure all steps to reproduce are clearly 70 outlined so developers can also reproduce. Once you have reproduced regressions, add the `~regression` label. For high-impact regressions, 70 71 also add `~"Next Patch Release"` and add the **current** _development month_ milestone. @lbot thanks, I think this is a good clarification!
Please register or sign in to reply