Standardize how to propose new lint rules

[valentincalomme]

I just submitted an issue (#9148) to propose a new rule to be added to ruff. As I did it, I realized that I wasn't certain how to best do that:

• Create an issue (and if yes, how to structure the request)
• Start a discussion (like here)
• Go to Discord etc.

What would be the preferred way to do this? My personal opinion would be to create an issue using a template representing how the rules are documented in the documentation:

# rule-name (RUF-0XX) 

<!-- Pick a hyphen-cased name for the rule -->

## What it does

<!-- Briefly discuss what the rule does -->

## Why is it bad?

<!-- Describe what issues the rule would prevent. -->

## Example

<!-- Please describe how a developer would need to fix the rule -->

Use instead:

This would structure rule proposals and hopefully save time for everyone involved. Ideally, users could pick the template when creating an issue and it would automatically label it.

PS: I'm a HUGE fan of how the rules are documented. I often refer to ruff even in projects that don't use ruff for its documentation alone. The "Why is it bad" section is extremely helpful to make my point across when I want to introduce lint rules or certain coding standards.

[MichaReiser]

I think we avoided templates until now to avoid friction when opening an issue (not that user don't open an issue when they can't find the right template).

But I do like your proposed template, so we could start with a generic empty template and one for lint rules.

One thing I would find useful to add to the template is when not to use that explains the cases in which you shouldn't use/dont want to the lint rule.

[valentincalomme]

An empty issue by default makes sense, but yes, I think it would help users who know that they want to propose a new rule that there is a structured way to do it.

I'm intrigued by the "when not to use the rule" idea. I can't think of a scenario that would be rule-specific. Could you give an example?

If a rule conflicts with another, that would make sense to add.

[MichaReiser]

I'm intrigued by the "when not to use the rule" idea. I can't think of a scenario that would be rule-specific. Could you give an example?

It's something I've seen from ESLint and pattern books and appreciate. For most non-correctness rules it's often personal preference whether you want to use them or not and it helps users if we can explain them when you generally don't want to use the rule. Some examples:

• opinionated rules that aren't necessarily about the correctness of your code but enforcing a specific style: If you don't care about that specific style, don't use the rule
• rules that catch typing errors: It may be unnecessary to use these rules if you use a type checker alongside ruff (except that ruff gives you faster feedback)
• Typing specific lints or lints that enforce type hints: Don't use them if you don't want to use typed Python
• Stylistic rules: May be unnecessary or even conflicting when using a code-formatter.
• The section can also cover cases where it is known that the rule raises false-positives, similar to no-await-in-for in eslint.

[valentincalomme]

Thanks for sharing! Had a look at the ESLint documentation, and I also quite like the way they do it.