2021-03-11 19:13:27 +05:30
<!--
When creating a new cop that could be applied to multiple applications,
we encourage you to add it to https://gitlab.com/gitlab-org/gitlab-styles gem.
-->
2020-03-13 15:44:24 +05:30
## 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
2022-01-26 12:08:38 +05:30
ignores current offenses.
- [ ] Mention this proposal in the relevant Slack channels (e.g. `#development` , `#backend` , `#frontend` ).
2020-03-13 15:44:24 +05:30
- [ ] 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:
2022-01-26 12:08:38 +05:30
- Vote for both choices, so they are visible to others.
- [ ] 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.
2020-04-22 19:07:51 +05:30
- [ ] Create a follow-up issue to fix the current offenses as a separate iteration: ISSUE_LINK
2022-01-26 12:08:38 +05:30
- [ ] Follow the [review process ](https://docs.gitlab.com/ee/development/code_review.html ) as usual.
2020-03-13 15:44:24 +05:30
- [ ] Once approved and merged by a maintainer, mention it again:
2022-01-26 12:08:38 +05:30
- [ ] In the relevant Slack channels (e.g. `#development` , `#backend` , `#frontend` ).
- [ ] (Optional depending on the impact of the change) In the Engineering Week in Review.
2020-03-13 15:44:24 +05:30
2021-01-03 14:25:43 +05:30
/label ~"Engineering Productivity" ~"development guidelines" ~"static code analysis"
2020-03-13 15:44:24 +05:30
/cc @gitlab -org/maintainers/rails-backend
