[allannienhuis]

I did something like this years ago for a really large team (~50 devs) when first introducing linting into a legacy project. All we did was count the gross total number of errors for the lint run, and simply tracked it as a low-water mark - failing the build if the number was > the existing number of errors, and lowering the stored number if it was lower. So in practice people couldn't introduce new errors. The team was encouraged to use the boy-scout rule of fixing a few things anytime you had to touch a file for other reasons, but it wasn't a requirement. We threw up a simple line chart on a dashboard for visibility. It worked like a charm - total number went down to zero over the course of a year or so, without getting in the way of anyone trying to get new work done.

[NortySpock]

How do you add new linter rules? Do you have to clean up an equivalent number of lines of warnings to enable an additional linter rule?

[allannienhuis]

sorry didn't see this question earlier.

we didn't run into this problem, as we just accepted a popular set of linting rules, and lived with them.

but I imagine you could just manually bump the ceiling number when adding a new linting rule.