Proposal: Responsibilities and Processes for Website League Keyholders
ruby
Public
Seen by 28
Draft Proposal: https://docs.google.com/document/d/1dn3gQ5BHvBDTwA6WJcdMq7dCy0rxkyuSck0ut2f1iJ4/edit
I've drafted a proposal with the intent to codfiy our current ad-hoc practices with regards to central infrastructure management and administration access. Please give it a read and provide any thoughts, modifications or other feedback.
Unless decided otherwise, this proposal will be put to a consensus vote after at least a 3 day comment period.
Katja
Tue 10 Dec 2024 4:30AM
I can't really see anything I have issues with in here? I'm just putting myself down as "no objection" as opposed to "unreserved support" because I don't particularly know one of the proposed initial keyholders (but see zero reason to oppose their inclusion, given what I've seen from them so far!).
Poll Created Wed 11 Dec 2024 12:08AM
Responsibilities and Processes for Website League Keyholders You have until Fri 13 Dec 2024 1:00AM to participate.
Please provide your proposal below.
https://docs.google.com/document/d/1dn3gQ5BHvBDTwA6WJcdMq7dCy0rxkyuSck0ut2f1iJ4/edit
For this proposal to pass, two-thirds of group membership must vote and there must be no major objections. While you are not obliged to provide a reasoning for anything besides a major objection, it may be helpful to others to explain why you support, have reservations with, or must stand aside from a proposal.
Current results
| Current results | Option | % of points | Voters | |
|---|---|---|---|---|
|
|
Endorse | 43.8% | 7 |
|
| No objection | 56.3% | 9 |
|
|
| Minor objection | 0.0% | 0 | ||
| Stand aside | 0.0% | 0 | ||
| Abstain | 0.0% | 0 | ||
| Major objection | 0.0% | 0 | ||
| Undecided | 0% | 23 |
.jpg){kind=avatar}
|
16 of 39 people have participated (41%)
Chaia Eran
Wed 11 Dec 2024 12:08AM
Seems like a good way to adapt standard DevOps procedure into a more democratic setting.
WholeWheatBagels
Wed 11 Dec 2024 12:08AM
I assume any hypothetical critical security updates or misconfigurations that need to be fixed fast are covered under Duties.1.fixing bugs and/or Duties.3?
ruby Wed 11 Dec 2024 12:47AM
@wholewheatbagels That's the intention, yes
Tenna
Wed 11 Dec 2024 12:08AM
I agree with the points made (including that there shouldn’t be an excess number of keyholders), I believe the procedures makes sense (including requirements to vet and onboard new keyholders), and I trust the users listed as initial keyholders.
I do want to make a side comment, however - I feel like there is a lack of information accompanying this document to properly vet these initial keyholders. I am basing my approval of the initial keyholders off of their current contributions, what’s written in the Abilities List document, and what I know of the members listed.
ruby Wed 11 Dec 2024 12:48AM
@tenna I mentioned this in the previous poll that was cancelled, but I'll put it here again for extra visibility:
The current list is composed of "the people who have been doing this work already up until now/people who already have access to these things" - I didn't want to radically change the state of the keyholder group with this proposal, so that list is basically just to codify how things are right now.
WholeWheatBagels
Wed 11 Dec 2024 1:02AM
I assume any hypothetical critical security updates or misconfigurations that need to be fixed fast are covered under Duties.1.fixing bugs and/or Duties.3?
WholeWheatBagels Wed 11 Dec 2024 1:03AM
sent the same message again when I changed to approve, disregard
sirocyl
Wed 11 Dec 2024 12:08AM
revoted
spdx-wl
Wed 11 Dec 2024 12:08AM
i voiced concerns previously re: keyholder accountability and stewardship, but they've been addressed in the current version (that keyholders need to be stewards) so i'm happy to endorse this
Katja
Wed 11 Dec 2024 12:08AM
Everything looks as good as it did on the previous version of this vote, so…!!
ruby · Tue 10 Dec 2024 9:38AM
@17tt The current list is composed of "the people who have been doing this work already up until now/people who already have access to these things" - I didn't want to radically change the state of the keyholder group with this proposal, so that list is basically just to codify how things are right now.