The goal of this PEP is to define the governance of the PSRT such that the membership is managed by the Steering Council, with a policy that balances having many contributors and risk of handling pre-disclosure vulnerability reports. The PEP also defines the process that vulnerability reports will be handled, by creating a role “Coordinator” who is responsible per-report for moving a particular report through PSRT processes within the industry standard 90 day timeline for handling a security report.
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.
Is there any need for “must be core team members, triagers, or PSF staff”, given that the SC approval is mandatory? (I’m all about not artificially restricting ourselves through specification - the SC is welcome to have a standing policy of requiring it, but I don’t see why we should need a PEP change to make a reasonable exception.)
On first read I thought it might be for GitHub administration purposes, but if we’re also having a psrt group then that shouldn’t matter?
I’d be happier with something like “New PSRT members must be proposed to SC … and are expected to be drawn from core developers, triagers, or PSF staff.” Which doesn’t rule out the possibility of adding someone else, but makes the expectation pretty clear.
Also, want to put something here about who can propose? Nomination by the existing PSRT members? Self-nomination directly to the SC (probably won’t make the SC happy )?
On first thought, a nomination process similar to core dev since reasonable. Meaning, PSRT members may nominate new members, and existing PSRT members would vote, with 2/3rds positive vote to be included, and given no PSC veto.
This PEP proposes adopting GitHub Security Advisories as the system to accept vulnerability reports due to its tight integration with services already in use by relevant projects.
The PSRT only triages a double-digit number of reports every year, meaning there aren’t an abundance of opportunities to “prove” activity on the scale of months. For this reason along with aligning with existing yearly schedules for the Steering Council, a yearly pruning was recommended.
Shouldn’t that last sentence read "For this reason along with aligning with existing yearly schedules for the Steering Council, a yearly pruning is not recommended.
Yeah, if the SC is doing filtering then we can change the requirement into a suggestion. This will also simplify the “legacied” PSRT member story, too.
We could adopt a process similar to core team nominations. So then the Steering Council would only be able to remove PSRT members with their own vote? I do agree with you and @steve.dower that self-nominations to the SC isn’t appropriate.
There were comments from @gpshead, @JacobCoffee, and @hugovk about keeping the PEP as-is and amending the PEP if we were ever to migrate off GitHub, given if we were to stop using GitHub we’d need to change many other PEPs, too. Hopefully this is okay with you?
The PEP recommends a yearly schedule for pruning (or rather, recommending to the Steering Council candidates to prune), so this sentence is correct. Maybe it can be more clear?
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.
The rejected idea is doing this more often than annually, “on the scale of months”:
Should inactive members be more aggressively pruned?
The PSRT only triages a double-digit number of reports every year, meaning there aren’t an abundance of opportunities to “prove” activity on the scale of months. For this reason along with aligning with existing yearly schedules for the Steering Council, a yearly pruning was recommended.
)?