Apply suggestions from code review

Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>

Author: sethmlarson

peps/pep-0811.rst

@@ -4,7 +4,7 @@ Author: Seth Michael Larson <seth@python.org>
 Sponsor: Gregory P. Smith <greg@krypto.org>
 Status: Draft
 Type: Process
-Created: 23-Oct-2025
+Created: 22-Oct-2025
 
 Abstract
 ========
@@ -35,7 +35,7 @@ Limit access to pre-disclosure vulnerability reports
 
 Vulnerability report information prior to disclosure is sensitive,
 Python users can be substantially harmed if vulnerabilities are exploited.
-For this reason it's critical to limit access to information to only users
+For this reason it's critical to limit access to information to only people
 involved in the remediation of the vulnerability at hand.
 
 The historical approach to collaboration on patch development was to manually
@@ -52,14 +52,14 @@ either.
 Onboarding new contributors to the PSRT
 ---------------------------------------
 
-Unlike most open source contributions, the work of the PSRT doesn't happen
+Unlike most open-source contributions, the work of the PSRT doesn't happen
 in the open. Instead, most work occurs privately to protect undisclosed
 vulnerability reports. This means the work is opaque from the outside
 so 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 groups ability to triage reports
+which over time could negatively impact the group's ability to triage reports
 and develop remediations with the core team.
 
 Lack of defined ownership for vulnerability reports
@@ -129,7 +129,7 @@ vulnerability reporting and management platform:
 * "Pull request"-like user interface for developing remediations.
 * Tracking reporter, coordinator, credits, submission time, CVE ID, and severity
   for each report within the UI.
-* Programatic API for integrating with other services (like CVE) and bots.
+* Programmatic API for integrating with other services (like CVE) and bots.
 
 However, features that are missing from GHSA are:
 
@@ -138,7 +138,7 @@ However, features that are missing from GHSA are:
   creating comments on a GHSA report.
 
 These missing features have been reported to GitHub and none are blocking
-the adoption of GHSA. Some work will need to be done to work-around the
+the adoption of GHSA. Some work will need to be done to work around the
 lack of a complete API for the GHSA feature.
 
 Specification
@@ -148,7 +148,7 @@ PSRT Membership Policy
 ----------------------
 
 The Python Steering Council may add or remove members and admins of the PSRT.
-New PSRT members must core team members or triagers and must be `proposed to
+New PSRT members must be core team members or triagers and must be `proposed to
 and accepted`_ by the Steering Council.
 
 Once the Steering Council votes on a membership change to the PSRT then
@@ -158,15 +158,15 @@ 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" defined here as a member who hasn't coordinated or commented on a
-vulnerability report in the past year since the report was generated.
+"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.
 
-Members of the PSRT that are a Release Manager or Steering Council
+Members of the PSRT who are a Release Manager or Steering Council
 member may remain in the PSRT regardless of inactivity in vulnerability reports.
 
 This PEP proposes removing all members from the PSRT who haven't been active
 in the past year and without an exemption for minimum activity (Steering Council,
-Release Managers) prior to pubication of this PEP. At the time of writing, this
+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
@@ -193,17 +193,17 @@ Responsibilities of PSRT members
 --------------------------------
 
 The responsibilities of PSRT members will be documented publicly in the
-`Python Developer Guide`_, so prospective members know what to expect before
+`Python Developer's Guide`_, so prospective members know what to expect before
 applying to join the PSRT. These responsibilities include:
 
 * Being knowledgeable about typical software vulnerability report handling
   processes, such as CVE IDs, patches, coordinated disclosure, embargoes, etc.
 * Not sharing or acting on embargoed information about the reported vulnerability.
-  Examples of disallowed behavior include, sharing information with colleagues
+  Examples of disallowed behavior include sharing information with colleagues
   or publicly deploying unpublished mitigations or patches ahead of the advisory
   publication date.
 * Acting as a "Coordinator" of vulnerability reports that are submitted
-  to projects. Coordinators responsibility is to move a report through the PSRT
+  to projects. A coordinator's responsibility is to move a report through the PSRT
   process to a "finished" state, either rejected or as a published advisory and
   mitigation, within the industry standard timeline of 90 days.
 * As a Coordinator, involving relevant core team members or triagers where
@@ -217,20 +217,20 @@ applying to join the PSRT. These responsibilities include:
 * Coordinators that can no longer move a report forwards for any reason must
   delegate their Coordinator role to someone else in the PSRT.
 * PSRT members that are admins will have additional responsibilities.
-* PSRT members that are staff of the Python Software Foundation, as an
+* PSRT members who are staff of the Python Software Foundation, as an
   "Open Source Steward" defined in `Article 24 of the Cyber Resilience Act`_,
   have `additional responsibilities`_, such as reporting actively exploited
   vulnerabilities to ENISA/CSIRTs.
 
 .. _security-announce@python.org: https://mail.python.org/archives/list/security-announce@python.org/
 .. _Article 24 of the Cyber Resilience Act: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#art_24
 .. _additional responsibilities: #responsibilities-of-psf-staff-psrt-members
-.. _Python Developer Guide: https://devguide.python.org/developer-workflow/psrt/
+.. _Python Developer's Guide: https://devguide.python.org/developer-workflow/psrt/
 
 Responsibilities of PSRT Admins
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-PSRT members that are designated as admins by the Steering Council have the
+PSRT members who are designated as admins by the Steering Council have the
 following additional responsibilities:
 
 * Managing the GitHub team, mailing list, Discord channel, and other
@@ -250,7 +250,7 @@ These requirements can be summarized as:
 
 ➤ Maintain a vulnerability disclosure policy fostering the voluntary reporting of vulnerabilities.
 The policy shall include aspects related to documenting, addressing, and remediating vulnerabilities
-and promote the sharing of information concerning discovered vulnerabilities within the open source community.
+and promote the sharing of information concerning discovered vulnerabilities within the open-source community.
 
 ➤ Cooperate with EU market surveillance authorities (ENISA and CSIRTs) to
 mitigate cybersecurity risks.
@@ -285,7 +285,7 @@ page on python.org and project security policies.
 
 Along with responsibilities the PSRT process for handling vulnerability
 reports using GHSA, such as how to assign a Coordinator and calculating
-severity, will be added to the `Python Developer Guide`_.
+severity, will be added to the `Python Developer's Guide`_.
 
 Adopting GHSAs will coincide with disabling the ``python/psrt`` private
 repository (which shares a slug with the GitHub team) and syncing machinery,