1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
|
============
Governance
============
How to become part of the project ?
-----------------------------------
How to become a contributor ?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- Follow the code of conduct
- Search by yourself before asking for help
- Open an issue
- Investigate an issue and report your finding
- Open a merge request directly if you feel it's a consensual change
Reporting a bug is being a contributor already.
How to become a triager ?
^^^^^^^^^^^^^^^^^^^^^^^^^
- Contribute for more than 3 releases consistently.
- Do not be too opinionated, follow the code of conduct without requiring emotional
works from the maintainers. It does not mean that disagreements are impossible,
only that arguments should stay technical and reasonable so the conversation
is civil and productive.
- Have a maintainer suggest that you become triager, without you asking
- Get unanimous approval or neutral agreement from current maintainers.
How to become a maintainer ?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- Contribute two big code merge requests over multiple releases (for example
one checker in 2.13 and the following bug after release and one complicated
bug fixes in 2.14). Otherwise contributing for more than 3 releases consistently
with great technical and interpersonal skills.
- Take ownership of a part of the code that is not maintained well at the moment
or that you contributed personally (if we feel we can't merge something without
your review, you're going to be able to merge those yourself soon).
- Triage for multiple months (close duplicate, clean up issues, answer questions...)
- Have an admin suggest that you become maintainer, without you asking
- Get unanimous approval or neutral agreement from current maintainers.
How to become an admin ?
^^^^^^^^^^^^^^^^^^^^^^^^
- Contribute for several hundreds of commits over a long period of time
with excellent interpersonal skills and code quality.
- Maintain pylint for multiple years (code review, triaging and maintenance tasks).
- At this point probably have another admin leave the project or
become inactive for years.
- Have an admin suggest that you become an admin, without you asking.
- Get unanimous approval or neutral agreement from current admins.
How are decisions made ?
------------------------
Everyone is expected to follow the code of conduct. pylint is a do-ocracy / democracy.
You're not allowed to behave poorly because you contributed a lot. But if
you're not going to do the future maintenance work, your valid opinions might not be
taken into account by those that will be affected by it.
What are the fundamental tenets of pylint development?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
General:
- We favor correctness over performance, because pylint is not used primarily
for its performance. Performance is still important and needs to be taken into
account from the get go.
- We then favor false negatives over false positives if correctness is
impossible to achieve.
- We try to keep the configuration sane, but if there's a hard decision to take we
add an option so that pylint is multiple sizes fit all (after configuration)
Where to add a new checker or message:
- Error messages (things that will result in an error if run) should be builtin
checks, activated by default
- Messages that are opinionated, even slightly, should be opt-in (added as :ref:`an extension<plugins>`)
- We don't shy away from opinionated checks (like the while checker), but there's such a
thing as too opinionated, if something is too opinionated it should be an external
:ref:`pylint plugin<plugins>`.
How are disagreements handled ?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
When something is not consensual users, maintainers, and admins discuss until an
agreement is reached.
Depending on the difficulty of the discussion and the importance of a fast resolution,
a decision can be taken:
- Unanimously between discussion participants, contributors and maintainers (preferably)
- By asking discussion participants for their opinions with an emoji survey in the
issue and then using the majority if no maintainers feel strongly about the issue.
- By majority of admins if no admins feel strongly about the issue.
- By asking all users for their opinions in a new issue that will be pinned for
multiple months before taking the decision if two admins feel strongly on an
opposite side of the issue. Once the result is obvious the majority decision
is not up for discussion anymore.
|
