Lint Issue Reporting

[pythongirl325]

Rust has a linting tool known as Clippy that uses an interesting strategy for keeping track of and developing new lints.

Clippy has several categories of lints, that can be enabled individually including one called "nursery". The "nursery" category is for many kinds of experimental lints that probably have mistakes in them, users can opt into this category to get potentially helpful lints at the possibility that they may be wrong or annoying. Clippy also encourages users that encounter bugs in the experimental lints to submit bug reports on their issues page, and as a result, most of the issues are about lints themselves.

Clippy's issue system has labels to keep track of the different kinds of issues with lints including "false positive" (the lint shows up when it shouldn't), "false negative" (the lint doesn't show up when it should), and "suggestion causes error" (where the suggested change is incorrect).

They also have a series of issue templates to make reporting these bugs even easier to users. Resyntax could also include a link to the "false positive" template issue creation page that the user may click on if they believe the suggestion is incorrect (as discussed on discord). Making bug reporting about suggestions very easy to users will get you much more helpful information without the need for anonymous information sharing like was suggested.

[jackfirth]

Putting the adoption barrier label on this because I think it's a mandatory feature before putting Resyntax in the langserver (jeapostrophe/racket-langserver#40) or in a github pull request bot.

One thing I'm wary of is configuration that lives in the tool instead of the code. I don't think Resyntax will be useful if it ships with a million rules of varying quality and asks users to pick and choose which to enable and disable. I want to put this in front of students who are using Racket for the very first time, which means a zero-configuration approach is mandatory. Therefore, I think that the distinction between "experimental" rules and "production-ready" rules should be in when and where they show up. For instance, running experimental rules only on pull requests and not when resyntax is run manually on the command line, to prevent people from creating large refactoring changes and merging them with broken changes from experimental rules included. We could also adopt some sort of gradual rollout strategy, where experimental rules start out as enabled for only 10% of users somehow.

[jackfirth]

Related: #281.