PEP 811: Adopt similar nomination process to core team

peps/pep-0811.rst

@@ -59,10 +59,9 @@ Onboarding new contributors to the PSRT
 
 Unlike most open-source contributions, the work of the PSRT doesn't happen
 in the open. Instead, most work occurs privately by a trusted group to limit
-access to undisclosed
-vulnerability reports. Given the sensitive nature of this work, it appears opaque from the outside, and
-it's difficult to get started as a newcomer and to understand the
-expectations of the group.
+access to undisclosed vulnerability reports. Given the sensitive nature of this
+work, it appears opaque from the outside, and it's difficult to get started as a
+newcomer and to understand the expectations of the group.
 
 In practice this has meant that relatively few new members join the PSRT,
 which over time could negatively impact the group's ability to triage reports
@@ -154,19 +153,21 @@ Specification
 PSRT Membership Policy
 ----------------------
 
-The Python Steering Council may add or remove members and admins of the PSRT.
-New PSRT members must be core team members, triagers, or PSF staff,
-and must be `proposed to and accepted`_ by the Steering Council.
+The PSRT will run nominations `similar to core team nominations`_, where
+a nomination of a new member is brought to the PSRT by an existing PSRT member
+and then that nomination is voted on by existing PSRT members.
+It is granted by receiving at least two-thirds positive votes from a vote of
+existing PSRT members that is open for one week and is not vetoed by the
+Steering Council.
 
-Once the Steering Council votes on a membership change to the PSRT then
-PSRT admins will enact the change.
 A list of PSRT members will be published publicly and kept up-to-date by PSRT
 admins.
 
 Once per year the Steering Council will receive a report of inactive members of
 the PSRT with the recommendation to remove the inactive users from the PSRT.
 "Inactive" is defined here as a member who hasn't coordinated or commented on a
 vulnerability report in the past year since the last report was generated.
+The Steering Council may remove members of the PSRT with a simple vote.
 
 Members of the PSRT who are a Release Manager or Steering Council
 member may remain in the PSRT regardless of inactivity in vulnerability reports.
@@ -176,11 +177,7 @@ in the past year and without an exemption for minimum activity (Steering Council
 Release Managers) prior to publication of this PEP. At the time of writing, this
 would reduce the PSRT membership size to ~15 members from ~30.
 
-This PEP also proposes not removing members of the PSRT who are active but
-not yet core team members or triagers, allowing them to be "legacied" in
-to the new PSRT Membership Policy.
-
-.. _proposed to and accepted: https://github.com/python/steering-council/
+.. _similar to core team nominations: https://devguide.python.org/core-team/join-team/
 
 PSRT Admins
 ~~~~~~~~~~~
@@ -236,7 +233,7 @@ following additional responsibilities:
 
 * Managing the GitHub team, mailing list, Discord channel, and other
   PSRT venues to ensure they are synchronized with the canonical list of
-  PSRT members determined by the Steering Council.
+  PSRT members.
 * On a yearly basis, providing the Steering Council with a report including
   a list of inactive PSRT members.