Proposal: Responsibilities and Processes for Website League Keyholders
ruby
Public
Seen by 36
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 Closed Fri 13 Dec 2024 1:00AM
A total of 16 Stewards voiced no objections to the proposal, meeting the current quorum of 13 as of poll closing (2024-12-13). The proposal is considered accepted and noted as a matter of record.
Moving forward, items listed in Access shall only be granted to Keyholders - any of these permissions granted to non-Keyholder Stewards will be revoked.
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.
Results
| 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% | 22 |
.jpg){kind=avatar}
|
16 of 38 people have participated (42%)
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
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.