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.
Thanks everyone for weighing in, there didn’t seem to be any disagreement about adopting a similar process to the core team nomination process, so I went forward with that:
This moves the nomination process to:
An existing PSRT member nominates a member.
There’s a vote of PSRT members on the nominee, requiring two-thirds positive to pass.
The Steering Council will have an opportunity to veto the nomination.
Finally, I added that the Steering Council has the ability to remove members of the PSRT with a simple vote, rather than requiring 4 positive votes to remove a member as is done for the core team. Removing any specifics about PSRT members (core team, triagers, etc) removes the need to define “legacied” members as all (thanks for the suggestion @steve.dower).
I’m not on the PSRT so don’t want to hold things up if you’re all in agreement, but you should think twice before adopting such a formal process. A formal vote is stressful, takes time, and requires more effort to take care of the formalities. For CPython, the team is large enough that a formal process makes sense, but I don’t know if that’s true for the PSRT. If possible, I’d stick with what I assume is the current process: the existing members decide using an informal process. If there’s disagreement they can’t resolve, they can escalate to the Steering Council for a decision.
As a PSRT member I’m willing to try out the more formal process and see how it goes (I guess that’s part of why I’m a PEP sponsor? ) - if some of us feel it isn’t working we should be willing to speak up with why and propose changing it.
Formalizing the process makes it possible to understand how to become a member. Up until now it has basically been a “know someone and ask” situation which never feels great.
It’ll be interesting to compare this to how a few committees I helped bootstrap a few years ago (Typing Council, Editorial Board and C API Workgroup). Those are less formal. But they are also smaller (5 members each, though that’s not fixed).
Steve earlier suggested anyone can join, although with an expectation of where from:
However, the PEP draft still has this which limits the pool:
This PEP proposes limiting PSRT membership only to active coordinators of security vulnerabilities that are core developers or triagers, members involved in oversight (Steering Council), and members who need information about security releases (Release Managers).
)?
) - if some of us feel it isn’t working we should be willing to speak up with why and propose changing it.