1<!-- 2When creating a new cop that could be applied to multiple applications, 3we encourage you to add it to https://gitlab.com/gitlab-org/gitlab-styles gem. 4--> 5 6## Description of the proposal 7 8<!-- 9Please describe the proposal and add a link to the source (for example, http://www.betterspecs.org/). 10--> 11 12### Check-list 13 14- [ ] Make sure this MR enables a static analysis check rule for new usage but 15 ignores current offenses. 16- [ ] Mention this proposal in the relevant Slack channels (e.g. `#development`, `#backend`, `#frontend`). 17- [ ] If there is a choice to make between two potential styles, set up an emoji vote in the MR: 18 - CHOICE_A: :a: 19 - CHOICE_B: :b: 20 - Vote for both choices, so they are visible to others. 21- [ ] 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)). 22- [ ] (If applicable) One style is getting a majority of vote (compared to the other choice). 23- [ ] (If applicable) Update the MR with the chosen style. 24- [ ] Create a follow-up issue to fix the current offenses as a separate iteration: ISSUE_LINK 25- [ ] Follow the [review process](https://docs.gitlab.com/ee/development/code_review.html) as usual. 26- [ ] Once approved and merged by a maintainer, mention it again: 27 - [ ] In the relevant Slack channels (e.g. `#development`, `#backend`, `#frontend`). 28 - [ ] (Optional depending on the impact of the change) In the Engineering Week in Review. 29 30/label ~"Engineering Productivity" ~"development guidelines" ~"static code analysis" 31 32/cc @gitlab-org/maintainers/rails-backend 33