Split out triage team from triaging

python · ezio-melotti · Jul 11, 2022 · Jun 14, 2022 · Jun 15, 2022 · Jun 15, 2022
commit 9a77665ee5c1720cafdbe52cf9a3fa7c09c1edc3
diff --git a/core-developers/committing.rst b/core-developers/committing.rst
@@ -52,8 +52,8 @@ to enter the public source tree. Ask yourself the following questions:
    developer can apply the label ``needs backport to X.Y`` to the pull
    request. Once the backport pull request has been created, remove the
    ``needs backport to X.Y`` label from the original pull request. (Only
-   core developers and members of the `Python Triage Team`_ can apply
-   labels to GitHub pull requests).
+   core developers and members of the :ref:`Python Triage Team <triage-team>`
+   can apply labels to GitHub pull requests).
 
 * **Does the pull request pass a check indicating that the submitter has signed the CLA?**
    Make sure that the contributor has signed a `Contributor
@@ -224,11 +224,10 @@ Note that cherry_picker.py_ adds the branch prefix automatically.
 
 Once the backport pull request has been created, remove the
 ``needs backport to X.Y`` label from the original pull request. (Only
-core developers and members of the `Python Triage Team`_ can apply
-labels to GitHub pull requests).
+core developers and members of the :ref:`Python Triage Team <triage-team>`
+can apply labels to GitHub pull requests).
 
 .. _cherry_picker.py: https://github.com/python/cherry-picker
-.. _`Python Triage Team`: https://devguide.python.org/triaging/#python-triage-team
 
 
 Reverting a merged pull request

diff --git a/developer-workflow/development-cycle.rst b/developer-workflow/development-cycle.rst
@@ -273,6 +273,8 @@ who no longer necessitate this level of access will be removed with notice.
 Multi-Factor Authentication must be enabled by the user in order to remain an
 Owner of the Python Organization.
 
+.. _current owners:
+
 Current Owners
 --------------
 

diff --git a/triage/index.rst b/triage/index.rst
@@ -9,3 +9,4 @@ Issues and Triaging
    triaging
    labels
    github-bpo-faq
+   triage-team
diff --git a/triage/issue-tracker.rst b/triage/issue-tracker.rst
@@ -151,7 +151,7 @@ Python:
   Python's test suite, having that written can be very helpful.
 
 This is all helpful as it allows triagers (i.e.,
-:ref:`people with the Developer role on the issue tracker <devrole>`) to
+:ref:`people with the Developer role on the issue tracker <triagers>`) to
 properly classify an issue so it can be handled by the right core developers in
 a timely fashion.
 
@@ -168,7 +168,7 @@ by making sure the patch:
 * includes proper documentation changes
 * submitter is listed in ``Misc/ACKS``, either already or the patch adds them
 
-Doing all of this allows core developers and :ref:`triagers <devrole>` to more
+Doing all of this allows core developers and :ref:`triagers` to more
 quickly look for subtle issues that only people with extensive experience
 working on Python's code base will notice.
 
@@ -182,30 +182,6 @@ specific kinds of issues (e.g. the "Windows" label if you are a Windows
 developer, "Extension Modules" if you are familiar with C, etc.).
 
 
-.. _devrole:
-
-Gaining the "Triager" Role on the Issue Tracker
-===============================================
-
-When you have consistently shown the ability to properly
-help triage issues without guidance, you may request that you
-be given the "Triager" role on the `issue tracker`_. You can make the request
-to any person who already has the Triager role. If they decide you are ready
-to gain the extra privileges on the tracker they will then act as a mentor to
-you until you are ready to do things entirely on your own. There is no set rule
-as to how many issues you need to have helped with before or how long you have
-been participating. The key requirements are that you show the desire to
-help, you are able to work well with others (especially those already with the
-Triager role), and that have a firm grasp of how to do things on the issue
-tracker properly on your own.
-
-Gaining the Triager role will allow you to set any value on any issue in the
-tracker, releasing you from the burden of having to ask others to set values on
-an issue for you in order to properly triage something. This will not only help
-speed up and simplify your work in helping out, but also help lessen the
-workload for everyone by gaining your help.
-
-
 .. seealso::
 
    `The Python issue tracker <https://github.com/python/
8000
cpython/issues>`_

diff --git a/triage/triage-team.rst b/triage/triage-team.rst
@@ -0,0 +1,105 @@
+.. _triage-team:
+.. _triagers:
+
+===========
+Triage Team
+===========
+
+The Python triage team is a group dedicated towards improving workflow
+efficiency through thoughtful review and triage of open issues and pull
+requests. This helps contributors receive timely feedback and enables core
+developers to focus on reviewed items which reduces their workload. The
+expectations of this role expand upon the "Triager" role on the
+:ref:`issue tracker <tracker>`. The responsibilities listed below are primarily centered
+around the Python GitHub repositories. This extends beyond CPython, and, as
+needed, to other repos such as devguide and core-workflow.
+
+Responsibilities include:
+
+* PR/issue management
+    - Reviewing PRs
+    - Assisting contributors
+    - Notifying appropriate core developers
+* Applying appropriate labels to PRs/Issues
+    - Skip news
+    - Skip issue
+    - Good first issue
+    - Other categorizations
+
+Although triagers have the power to close PRs, they should generally not do so
+without first consulting a core developer. By having triagers and core developers work together,
+the author receives a careful consideration of their PR. This encourages future
+contributions, regardless of whether their PR is accepted or closed.
+
+Nonetheless, triagers should feel free to close a PR if they judge that the
+chance of the PR being merged would be exceedingly low, even if substantial
+revisions were made to the PR. This includes (but is not limited to) the
+following:
+
+* PRs proposing solely cosmetic changes
+* PRs proposing changes to deprecated modules
+* PRs that are no longer relevant. This includes:
+    - PRs proposing fixes for bugs that can no longer be reproduced
+    - PRs proposing changes that have been rejected by Python core developers
+      elsewhere (e.g. in an issue or a PEP rejection notice)
+
+If a triager has any doubt about whether to close a PR, they should consult a core
+developer before taking any action.
+
+Triagers can also make use of the ``invalid`` and ``stale`` labels to suggest that a
+PR may be suitable for closure. For more information, see the
+:ref:`GitHub PR labels <github-pr-labels>` section.
+
+Note that it is of paramount importance to treat every contributor to the Python
+project kindly and with respect. Regardless of whether they're entirely new
+or a veteran core developer, they're actively choosing to voluntarily donate their
+time towards the improvement of Python. As is the case with any member of
+the Python Software Foundation, always follow the `PSF Code of Conduct`_.
+
+.. _PSF Code of Conduct: https://www.python.org/psf/conduct/
+
+
+Becoming a member of the Python triage team
+===========================================
+
+Any Python core developers are welcome to invite a Python contributor to the
+Python triage team. Triagers will be responsible to handle not just issues, but
+also pull requests, and even managing backports. A Python triager has access to
+more repositories than just CPython.
+
+Any existing active contributor to the Python repository on GitHub can
+transition into becoming a Python triager. They can request this to any core
+developer, and the core developer can pass the request to the `Python
+organization admin
+<https://devguide.python.org/devcycle/?highlight=organization%20admin#current-owners>`_
+on GitHub. The request can be made confidentially via a DM in Discourse, or
+publicly by opening an `issue in the core-workflow repository
+<https://github.com/python/core-workflow/issues/new?template=triage_membership.md>`_.
+
+For every new triager, it would be great to announce them in the python-committers
+mailing list and core-workflow category in Discourse. `Example announcement
+<https://discuss.python.org/t/abhilash-raj-has-been-granted-triage-role-on-github/2089>`_.
+
+
+Gaining the "Triager" Role on the Issue Tracker
+===============================================
+
+When you have consistently shown the ability to properly
+help triage issues without guidance, you may request that you
+be given the "Triager" role on the `issue tracker`_. You can make the request
+to any person who already has the Triager role. If they decide you are ready
+to gain the extra privileges on the tracker they will then act as a mentor to
+you until you are ready to do things entirely on your own. There is no set rule
+as to how many issues you need to have helped with before or how long you have
+been participating. The key requirements are that you show the desire to
+help, you are able to work well with others (especially those already with the
+Triager role), and that have a firm grasp of how to do things on the issue
+tracker properly on your own.
+
+Gaining the Triager role will allow you to set any value on any issue in the
+tracker, releasing you from the burden of having to ask others to set values on
+an issue for you in order to properly triage something. This will not only help
+speed up and simplify your work in helping out, but also help lessen the
+workload for everyone by gaining your help.
+
+.. _issue tracker: https://devguide.python.org/tracker/
diff --git a/triage/triaging.rst b/triage/triaging.rst
@@ -9,87 +9,10 @@ users and developers.
 Contributors with the Triager role on the issue tracker can triage issues
 directly without any assistance.
 
-Additionally, this section provides an overview of the Python triage team.
-
-Python triage team
-------------------
-
-The Python triage team is a group dedicated towards improving workflow
-efficiency through thoughtful review and triage of open issues and pull
-requests. This helps contributors receive timely feedback and enables core
-developers to focus on reviewed items which reduces their workload. The
-expectations of this role
EAD4
 expand upon the "Triager" role on the
-`issue tracker`_. The responsibilities listed below are primarily centered
-around the Python GitHub repositories. This extends beyond CPython, and, as
-needed, to other repos such as devguide and core-workflow.
-
-Responsibilities include:
-
-* PR/issue management
-    - Reviewing PRs
-    - Assisting contributors
-    - Notifying appropriate core developers
-* Applying appropriate labels to PRs/Issues
-    - Skip news
-    - Skip issue
-    - Good first issue
-    - Other categorizations
-
-Although triagers have the power to close PRs, they should generally not do so
-without first consulting a core developer. By having triagers and core developers work together,
-the author receives a careful consideration of their PR. This encourages future
-contributions, regardless of whether their PR is accepted or closed.
-
-Nonetheless, triagers should feel free to close a PR if they judge that the
-chance of the PR being merged would be exceedingly low, even if substantial
-revisions were made to the PR. This includes (but is not limited to) the
-following:
-
-* PRs proposing solely cosmetic changes
-* PRs proposing changes to deprecated modules
-* PRs that are no longer relevant. This includes:
-    - PRs proposing fixes for bugs that can no longer be reproduced
-    - PRs proposing changes that have been rejected by Python core developers
-      elsewhere (e.g. in an issue or a PEP rejection notice)
-
-If a triager has any doubt about whether to close a PR, they should consult a core
-developer before taking any action.
-
-Triagers can also make use of the ``invalid`` and ``stale`` labels to suggest that a
-PR may be suitable for closure. For more information, see the
-:ref:`GitHub PR labels <github-pr-labels>` section.
-
-Note that it is of paramount importance to treat every contributor to the Python
-project kindly and with respect. Regardless of whether they're entirely new
-or a veteran core developer, they're actively choosing to voluntarily donate their
-time towards the improvement of Python. As is the case with any member of
-the Python Software Foundation, always follow the `PSF Code of Conduct`_.
-
-Becoming a member of the Python triage team
--------------------------------------------
-
-Any Python core developers are welcome to invite a Python contributor to the
-Python triage team. Triagers will be responsible to handle not just issues, but
-also pull requests, and even managing backports. A Python triager has access to
-more repositories than just CPython.
-
-Any existing active contributor to the Python repository on GitHub can
-transition into becoming a Python triager. They can request this to any core
-developer, and the core developer can pass the request to the `Python
-organization admin
-<https://devguide.python.org/devcycle/?highlight=organization%20admin#current-owners>`_
-on GitHub. The request can be made confidentially via a DM in Discourse, or
-publicly by opening an `issue in the core-workflow repository
-<https://github.com/python/core-workflow/issues/new?template=triage_membership.md>`_.
-
-For every new triager, it would be great to announce them in the python-committers
-mailing list and core-workflow category in Discourse. `Example announcement
-<https://discuss.python.org/t/abhilash-raj-has-been-granted-triage-role-on-github/2089>`_.
-
 .. _github-pr-labels:
 
 GitHub Labels for PRs
-'''''''''''''''''''''
+---------------------
 
 An important component of triaging PRs for the CPython repo involves
 appropriately categorizing them through the usage of labels. For this