Skip to content

Commit ba65de3

Browse files
AA-Turnerezio-melotti
authored andcommitted
Split out triage team from triaging
1 parent 74f2168 commit ba65de3

File tree

6 files changed

+115
-109
lines changed

6 files changed

+115
-109
lines changed

core-developers/committing.rst

Lines changed: 4 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -52,8 +52,8 @@ to enter the public source tree. Ask yourself the following questions:
5252
developer can apply the label ``needs backport to X.Y`` to the pull
5353
request. Once the backport pull request has been created, remove the
5454
``needs backport to X.Y`` label from the original pull request. (Only
55-
core developers and members of the `Python Triage Team`_ can apply
56-
labels to GitHub pull requests).
55+
core developers and members of the :ref:`Python Triage Team <triage-team>`
56+
can apply labels to GitHub pull requests).
5757

5858
* **Does the pull request pass a check indicating that the submitter has signed the CLA?**
5959
Make sure that the contributor has signed a `Contributor
@@ -224,11 +224,10 @@ Note that cherry_picker.py_ adds the branch prefix automatically.
224224

225225
Once the backport pull request has been created, remove the
226226
``needs backport to X.Y`` label from the original pull request. (Only
227-
core developers and members of the `Python Triage Team`_ can apply
228-
labels to GitHub pull requests).
227+
core developers and members of the :ref:`Python Triage Team <triage-team>`
228+
can apply labels to GitHub pull requests).
229229

230230
.. _cherry_picker.py: https://github.com/python/cherry-picker
231-
.. _`Python Triage Team`: https://devguide.python.org/triaging/#python-triage-team
232231

233232

234233
Reverting a merged pull request

developer-workflow/development-cycle.rst

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -273,6 +273,8 @@ who no longer necessitate this level of access will be removed with notice.
273273
Multi-Factor Authentication must be enabled by the user in order to remain an
274274
Owner of the Python Organization.
275275

276+
.. _current owners:
277+
276278
Current Owners
277279
--------------
278280

triage/index.rst

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -9,3 +9,4 @@ Issues and Triaging
99
triaging
1010
labels
1111
github-bpo-faq
12+
triage-team

triage/issue-tracker.rst

Lines changed: 2 additions & 26 deletions
Original file line numberDiff line numberDiff line change
@@ -151,7 +151,7 @@ Python:
151151
Python's test suite, having that written can be very helpful.
152152

153153
This is all helpful as it allows triagers (i.e.,
154-
:ref:`people with the Developer role on the issue tracker <devrole>`) to
154+
:ref:`people with the Developer role on the issue tracker <triagers>`) to
155155
properly classify an issue so it can be handled by the right core developers in
156156
a timely fashion.
157157

@@ -168,7 +168,7 @@ by making sure the patch:
168168
* includes proper documentation changes
169169
* submitter is listed in ``Misc/ACKS``, either already or the patch adds them
170170

171-
Doing all of this allows core developers and :ref:`triagers <devrole>` to more
171+
Doing all of this allows core developers and :ref:`triagers` to more
172172
quickly look for subtle issues that only people with extensive experience
173173
working on Python's code base will notice.
174174

@@ -182,30 +182,6 @@ specific kinds of issues (e.g. the "Windows" label if you are a Windows
182182
developer, "Extension Modules" if you are familiar with C, etc.).
183183

184184

185-
.. _devrole:
186-
187-
Gaining the "Triager" Role on the Issue Tracker
188-
===============================================
189-
190-
When you have consistently shown the ability to properly
191-
help triage issues without guidance, you may request that you
192-
be given the "Triager" role on the `issue tracker`_. You can make the request
193-
to any person who already has the Triager role. If they decide you are ready
194-
to gain the extra privileges on the tracker they will then act as a mentor to
195-
you until you are ready to do things entirely on your own. There is no set rule
196-
as to how many issues you need to have helped with before or how long you have
197-
been participating. The key requirements are that you show the desire to
198-
help, you are able to work well with others (especially those already with the
199-
Triager role), and that have a firm grasp of how to do things on the issue
200-
tracker properly on your own.
201-
202-
Gaining the Triager role will allow you to set any value on any issue in the
203-
tracker, releasing you from the burden of having to ask others to set values on
204-
an issue for you in order to properly triage something. This will not only help
205-
speed up and simplify your work in helping out, but also help lessen the
206-
workload for everyone by gaining your help.
207-
208-
209185
.. seealso::
210186

211187
`The Python issue tracker <https://github.com/python/cpython/issues>`_

triage/triage-team.rst

Lines changed: 105 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,105 @@
1+
.. _triage-team:
2+
.. _triagers:
3+
4+
===========
5+
Triage Team
6+
===========
7+
8+
The Python triage team is a group dedicated towards improving workflow
9+
efficiency through thoughtful review and triage of open issues and pull
10+
requests. This helps contributors receive timely feedback and enables core
11+
developers to focus on reviewed items which reduces their workload. The
12+
expectations of this role expand upon the "Triager" role on the
13+
:ref:`issue tracker <tracker>`. The responsibilities listed below are primarily centered
14+
around the Python GitHub repositories. This extends beyond CPython, and, as
15+
needed, to other repos such as devguide and core-workflow.
16+
17+
Responsibilities include:
18+
19+
* PR/issue management
20+
- Reviewing PRs
21+
- Assisting contributors
22+
- Notifying appropriate core developers
23+
* Applying appropriate labels to PRs/Issues
24+
- Skip news
25+
- Skip issue
26+
- Good first issue
27+
- Other categorizations
28+
29+
Although triagers have the power to close PRs, they should generally not do so
30+
without first consulting a core developer. By having triagers and core developers work together,
31+
the author receives a careful consideration of their PR. This encourages future
32+
contributions, regardless of whether their PR is accepted or closed.
33+
34+
Nonetheless, triagers should feel free to close a PR if they judge that the
35+
chance of the PR being merged would be exceedingly low, even if substantial
36+
revisions were made to the PR. This includes (but is not limited to) the
37+
following:
38+
39+
* PRs proposing solely cosmetic changes
40+
* PRs proposing changes to deprecated modules
41+
* PRs that are no longer relevant. This includes:
42+
- PRs proposing fixes for bugs that can no longer be reproduced
43+
- PRs proposing changes that have been rejected by Python core developers
44+
elsewhere (e.g. in an issue or a PEP rejection notice)
45+
46+
If a triager has any doubt about whether to close a PR, they should consult a core
47+
developer before taking any action.
48+
49+
Triagers can also make use of the ``invalid`` and ``stale`` labels to suggest that a
50+
PR may be suitable for closure. For more information, see the
51+
:ref:`GitHub PR labels <github-pr-labels>` section.
52+
53+
Note that it is of paramount importance to treat every contributor to the Python
54+
project kindly and with respect. Regardless of whether they're entirely new
55+
or a veteran core developer, they're actively choosing to voluntarily donate their
56+
time towards the improvement of Python. As is the case with any member of
57+
the Python Software Foundation, always follow the `PSF Code of Conduct`_.
58+
59+
.. _PSF Code of Conduct: https://www.python.org/psf/conduct/
60+
61+
62+
Becoming a member of the Python triage team
63+
===========================================
64+
65+
Any Python core developers are welcome to invite a Python contributor to the
66+
Python triage team. Triagers will be responsible to handle not just issues, but
67+
also pull requests, and even managing backports. A Python triager has access to
68+
more repositories than just CPython.
69+
70+
Any existing active contributor to the Python repository on GitHub can
71+
transition into becoming a Python triager. They can request this to any core
72+
developer, and the core developer can pass the request to the `Python
73+
organization admin
74+
<https://devguide.python.org/devcycle/?highlight=organization%20admin#current-owners>`_
75+
on GitHub. The request can be made confidentially via a DM in Discourse, or
76+
publicly by opening an `issue in the core-workflow repository
77+
<https://github.com/python/core-workflow/issues/new?template=triage_membership.md>`_.
78+
79+
For every new triager, it would be great to announce them in the python-committers
80+
mailing list and core-workflow category in Discourse. `Example announcement
81+
<https://discuss.python.org/t/abhilash-raj-has-been-granted-triage-role-on-github/2089>`_.
82+
83+
84+
Gaining the "Triager" Role on the Issue Tracker
85+
===============================================
86+
87+
When you have consistently shown the ability to properly
88+
help triage issues without guidance, you may request that you
89+
be given the "Triager" role on the `issue tracker`_. You can make the request
90+
to any person who already has the Triager role. If they decide you are ready
91+
to gain the extra privileges on the tracker they will then act as a mentor to
92+
you until you are ready to do things entirely on your own. There is no set rule
93+
as to how many issues you need to have helped with before or how long you have
94+
been participating. The key requirements are that you show the desire to
95+
help, you are able to work well with others (especially those already with the
96+
Triager role), and that have a firm grasp of how to do things on the issue
97+
tracker properly on your own.
98+
99+
Gaining the Triager role will allow you to set any value on any issue in the
100+
tracker, releasing you from the burden of having to ask others to set values on
101+
an issue for you in order to properly triage something. This will not only help
102+
speed up and simplify your work in helping out, but also help lessen the
103+
workload for everyone by gaining your help.
104+
105+
.. _issue tracker: https://devguide.python.org/tracker/

triage/triaging.rst

Lines changed: 1 addition & 78 deletions
Original file line numberDiff line numberDiff line change
@@ -9,87 +9,10 @@ users and developers.
99
Contributors with the Triager role on the issue tracker can triage issues
1010
directly without any assistance.
1111

12-
Additionally, this section provides an overview of the Python triage team.
13-
14-
Python triage team
15-
------------------
16-
17-
The Python triage team is a group dedicated towards improving workflow
18-
efficiency through thoughtful review and triage of open issues and pull
19-
requests. This helps contributors receive timely feedback and enables core
20-
developers to focus on reviewed items which reduces their workload. The
21-
expectations of this role expand upon the "Triager" role on the
22-
`issue tracker`_. The responsibilities listed below are primarily centered
23-
around the Python GitHub repositories. This extends beyond CPython, and, as
24-
needed, to other repos such as devguide and core-workflow.
25-
26-
Responsibilities include:
27-
28-
* PR/issue management
29-
- Reviewing PRs
30-
- Assisting contributors
31-
- Notifying appropriate core developers
32-
* Applying appropriate labels to PRs/Issues
33-
- Skip news
34-
- Skip issue
35-
- Good first issue
36-
- Other categorizations
37-
38-
Although triagers have the power to close PRs, they should generally not do so
39-
without first consulting a core developer. By having triagers and core developers work together,
40-
the author receives a careful consideration of their PR. This encourages future
41-
contributions, regardless of whether their PR is accepted or closed.
42-
43-
Nonetheless, triagers should feel free to close a PR if they judge that the
44-
chance of the PR being merged would be exceedingly low, even if substantial
45-
revisions were made to the PR. This includes (but is not limited to) the
46-
following:
47-
48-
* PRs proposing solely cosmetic changes
49-
* PRs proposing changes to deprecated modules
50-
* PRs that are no longer relevant. This includes:
51-
- PRs proposing fixes for bugs that can no longer be reproduced
52-
- PRs proposing changes that have been rejected by Python core developers
53-
elsewhere (e.g. in an issue or a PEP rejection notice)
54-
55-
If a triager has any doubt about whether to close a PR, they should consult a core
56-
developer before taking any action.
57-
58-
Triagers can also make use of the ``invalid`` and ``stale`` labels to suggest that a
59-
PR may be suitable for closure. For more information, see the
60-
:ref:`GitHub PR labels <github-pr-labels>` section.
61-
62-
Note that it is of paramount importance to treat every contributor to the Python
63-
project kindly and with respect. Regardless of whether they're entirely new
64-
or a veteran core developer, they're actively choosing to voluntarily donate their
65-
time towards the improvement of Python. As is the case with any member of
66-
the Python Software Foundation, always follow the `PSF Code of Conduct`_.
67-
68-
Becoming a member of the Python triage team
69-
-------------------------------------------
70-
71-
Any Python core developers are welcome to invite a Python contributor to the
72-
Python triage team. Triagers will be responsible to handle not just issues, but
73-
also pull requests, and even managing backports. A Python triager has access to
74-
more repositories than just CPython.
75-
76-
Any existing active contributor to the Python repository on GitHub can
77-
transition into becoming a Python triager. They can request this to any core
78-
developer, and the core developer can pass the request to the `Python
79-
organization admin
80-
<https://devguide.python.org/devcycle/?highlight=organization%20admin#current-owners>`_
81-
on GitHub. The request can be made confidentially via a DM in Discourse, or
82-
publicly by opening an `issue in the core-workflow repository
83-
<https://github.com/python/core-workflow/issues/new?template=triage_membership.md>`_.
84-
85-
For every new triager, it would be great to announce them in the python-committers
86-
mailing list and core-workflow category in Discourse. `Example announcement
87-
<https://discuss.python.org/t/abhilash-raj-has-been-granted-triage-role-on-github/2089>`_.
88-
8912
.. _github-pr-labels:
9013

9114
GitHub Labels for PRs
92-
'''''''''''''''''''''
15+
---------------------
9316

9417
An important component of triaging PRs for the CPython repo involves
9518
appropriately categorizing them through the usage of labels. For this

0 commit comments

Comments
 (0)