28 lines
1.5 KiB
Markdown
28 lines
1.5 KiB
Markdown
|
## Description of the proposal
|
||
|
|
|
||
|
|
<!--
|
||
|
|
Please describe the proposal and add a link to the source (for example, http://www.betterspecs.org/).
|
||
|
|
-->
|
||
|
|
|
||
|
|
### 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: :a:
|
||
|
|
- CHOICE_B: :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 :+1: vs :-1: (remember that [we don't need to reach a consensus](https://about.gitlab.com/handbook/values/#collaboration-is-not-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](https://docs.gitlab.com/ee/development/code_review.html) 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
|
||
|
|
|
||
|
|
/label ~"Engineering Productivity" ~"Style decision" ~"development guidelines" ~"static analysis"
|
||
|
|
|
||
|
|
/cc @gitlab-org/maintainers/rails-backend
|