Document the governance model and the path to maintainership

[Pierre-Sassoulas]

Type of Changes

	Type
✓	📜 Docs

Description

This is done due to clarify our standing on moderation issues related to the recent PyCQA discussion, and also as part of the work done for the OpenSSF best practices (that Tidelift is paying me to do to make the software supply chain more secure). To be clear having an autocrat behaving like an asshole as the owner of a project is a liability for everyone in the software supply chain. Making sure that this does not happen for pylint is valuable. The way to become a maintainer is also a frequently asked question.

[codecov]

Codecov Report

Merging #8329 (d357be6) into main (c4f059b) will not change coverage.
The diff coverage is n/a.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #8329   +/-   ##
=======================================
  Coverage   95.46%   95.46%           
=======================================
  Files         177      177           
  Lines       18704    18704           
=======================================
  Hits        17856    17856           
  Misses        848      848           

[cdce8p]

A few suggestion.

In general, I tend to prefer some ambiguity when it comes to these things. Nobody should think they are entitled to become a maintainer / or even an admin.

However, I do understand the intention to have something written and agreed upon.

[Pierre-Sassoulas]

I feel like some defining characteristics of pylint that are not up for discussion should be explained here as well, I'm thinking of:

• We favor false negatives over false positives
• New messages should be opt-in if it's opinionated (even a little)
• We favor correctness over performance, because pylint is not used for its performance, BUT performance is important and need to be taken into account from the get go
• If there's a hard decision to take we try to add an option so that pylint is one size fit all (after configuration)
• ... ?

I'm sure there are other implicit rules that we agree on but I don't think of anything else right now ...

[cdce8p]

Maybe it's self explanatory so not sure it should be added:

Have been a triager for x amount of time / multiple months

If it's added, something similar could be added to the admin section as well.

[Pierre-Sassoulas]

0c634e3

[ollie-iterators]

This is great. Thanks for doing this @Pierre-Sassoulas

[jacobtylerwalls]

👍

[DanielNoord]

Thanks for doing this! I don't care too much about it as I think most of this is fairly self explanatory but might be good to document it.

I said this before but I do feel the OpenSSF is focusing an awful lot on minor details that take away from actually improving projects that fall under it, but oh wel...

[Pierre-Sassoulas]

I'm not doing this only for OpenSSF. There are more fundamental requirements of OpenSSF, but we're already very advanced on what we do regarding fundamental stuff (license/tests/bug reporting/ documentation/CI/rights), so the actual way to make pylint better are becoming more and more "niche". Being explicit about the code of conduct being enforced for everyone is important (to me) due to PyCQA meta issue 54.

I'm open on working for specific aspects that you find more impactful next, see https://bestpractices.coreinfrastructure.org/en/projects/6328

[Pierre-Sassoulas]

Thank you for the review @mbyrnepr2 :)