1.5 KiB
1.5 KiB
Description of the proposal
Check-list
- Make sure this MR enables a static analysis check rule for new usage but ignores current offenses
- Create a follow-up issue to fix the current offenses as a separate iteration: ISSUE_LINK
- Mention this proposal in the relevant Slack channels (e.g.
#development,#backend,#frontend) - If there is a choice to make between two potential styles, set up an emoji vote in the MR:
- CHOICE_A: 🅰️
- CHOICE_B: 🅱️
- Vote yourself for both choices so that people know these are the choices
- The MR doesn't have significant objections, and is getting a majority of 👍 vs 👎 (remember that we don't need to reach a consensus)
- (If applicable) One style is getting a majority of vote (compared to the other choice)
- (If applicable) Update the MR with the chosen style
- Follow the review process as usual
- Once approved and merged by a maintainer, mention it again:
- In the relevant Slack channels (e.g.
#development,#backend,#frontend) - (Optional depending on the impact of the change) In the Engineering Week in Review
- In the relevant Slack channels (e.g.
/label ~"Engineering Productivity" ~"Style decision" ~"development guidelines" ~"static analysis"
/cc @gitlab-org/maintainers/rails-backend