Update the doc and code following PyCQA migration

[Pierre-Sassoulas]

Type of Changes

	Type
✓	📜 Docs

Description

Refs PyCQA/meta#54

[Pierre-Sassoulas]

Readthedoc and pre-commit should be fixed, I'm still working on re-syncing codecov (will finish tonight), but I don't understand the issue with python 3.11 tests not launching.

[Pierre-Sassoulas]

Added kanga333/comment-hider@*,tibdex/backport@*,to the list of authorized action as it seems to be an organisation wide settings.

[Pierre-Sassoulas]

And codecov/codecov-action@*

[codecov-commenter]

Codecov Report

Merging #8514 (abceaba) into main (9ac524a) will decrease coverage by 0.02%.
The diff coverage is 100.00%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8514      +/-   ##
==========================================
- Coverage   95.92%   95.91%   -0.02%     
==========================================
  Files         174      174              
  Lines       18362    18362              
==========================================
- Hits        17613    17611       -2     
- Misses        749      751       +2     

Impacted Files	Coverage Δ
pylint/__init__.py	96.87% <ø> (ø)
pylint/__main__.py	100.00% <ø> (ø)
pylint/__pkginfo__.py	100.00% <ø> (ø)
pylint/checkers/__init__.py	93.93% <ø> (ø)
pylint/checkers/async.py	97.77% <ø> (ø)
pylint/checkers/bad_chained_comparison.py	100.00% <ø> (ø)
pylint/checkers/base/__init__.py	100.00% <ø> (ø)
pylint/checkers/base/basic_checker.py	97.88% <ø> (ø)
pylint/checkers/base/basic_error_checker.py	95.51% <ø> (ø)
pylint/checkers/base/comparison_checker.py	100.00% <ø> (ø)
... and 164 more

[DudeNr33]

From what I have read so far in the linked issue I understand and support the decision.

However I think for the FAQ this is too much detail. What do you think about this as an alternative?

Over the years, the views on the definition and enforcement of policies and moderation guidelines 
have diverged between the PyCQA organization as a whole and the Pylint team itself. 
As some decisions in GitHub Organizations have impacts on all included projects, 
it became necessary to migrate to an independent organization, where we have 
the freedom to define and follow our own policies.

[DanielNoord]

Agreed! I would even be okay with not mentioning the policies and just say: "Github Organisations share a lot of settings that are sometimes better set per project. By creating a new organisation we can control these better for the pylint associated projects".

In 2 years time nobody will probably care about the specifics anymore.

[Pierre-Sassoulas]

The fact that PCManticore and myself were both demoted and that we could not administrate our own repo felt important, but we might also not add anything to the FAQ at all if we want to be super consensual. It's doubtless that it's interesting for a lot of persons anyway. Imo the important doc addition was #8329. I can remove the commit altogether

[DanielNoord]

I would be okay with removing. Let's leave this behind us.

[Pierre-Sassoulas]

I'd like to reinstate readthedoc integration before merging, I'm looking into it.

[Pierre-Sassoulas]

Regarding right management, I realized that "member" in "pylint-dev" have no right (except seeing private repositories in the org, and we don't (won't?) have any). I'm wondering if we should:

• Give triage right everywhere to all member ?
• Add triager in each repositories ?
• (Add member as a "honorary status" for 1 PR merged or 5 issues opened ?)

pytest-dev is giving contributor right to everything on the first merged PR, which feels nice and makes me want to simplify thing and give triage right to member. Thought ?

[DanielNoord]

I'd like to reinstate readthedoc integration before merging, I'm looking into it.

Should be fixed now!

Regarding right management, I realized that "member" in "pylint-dev" have no right (except seeing private repositories in the org, and we don't (won't?) have any). I'm wondering if we should:

• Give triage right everywhere to all member ?

Let's not. Let's keep this a bit more fine-grained, or make the member more of a top-level thing with maintainers/triagers of individual projects not being members of the full organisation immediately.

• Add triager in each repositories ?

Yes. If we start adding more plugins it will be good to have fine-grained access levels.

• (Add member as a "honorary status" for 1 PR merged or 5 issues opened ?)

That limits us in what we can do with rights.

pytest-dev is giving contributor right to everything on the first merged PR, which feels nice and makes me want to simplify thing and give triage right to member. Thought ?

This would be easier, but I can see how not everybody might want to add their project to this org if there are 20+ people with global triage rights.

[Pierre-Sassoulas]

All right, for the moment "member" is honorary (but all current members would be at least triager) and I'm going to add person one by one with actual rights in pylint/astroid. This feel like a whole discussion, let's not mix it with the current doc change..

[Pierre-Sassoulas]

Thank you for fixing readthedoc btw !

[github-actions]

🤖 According to the primer, this change has no effect on the checked open source code. 🤖🎉

This comment was generated for commit abceaba