Accepted Proposals

• Defining the Website League's Stewards
• [Temporary] Bootstrapping Coming to Agreements
• Steward Procedures
• Responsibilities and Processes for Website League Keyholders

Defining the Website League's Stewards

Stewards

The Website League's stewards will deliberate on proposals presented, and make the final decision on whether proposals will be accepted or not. Ultimately, stewards will be the ones to make decisions on matters relating to how the League operates and is structured, such as the rules that instances and communities within the League will follow, and what the structure of the League will look like.

Steward Membership

The current process for becoming a steward is better defined in Proposal 4 (Steward Procedures).

Becoming a steward is voluntary.

Prior to October 1st, 2024, stewardship was open to members that met any of the following conditions:

• Any person that intended to, or expressed interest in, participating in the League as a node's staff member, or
• Any person with a relevant skill set or prior experience that would contribute to the planning, coding, hosting, organization, advertising, social harmony, or other such need of the League.

Currently, conditions of membership require at least one of the following:

• Any person who has acted, or is currently acting as, a node's staff member at the time of League formalization, or
• Any person vetted by existing stewards to become a node's staff member within the League, or
• Any person with a relevant skill set, prior experience, or other such need that would contribute to the League's health and continuation, or
• Any person that does not fit into the prior three categories, but is otherwise agreed to by consensus of existing stewards.

---

Last updated: Friday, November 8th 2024 03:17:20 UTC

This proposal was voted on in the Discord #announcements channel on September 14th, 2024. It was accepted unanimously, with 43 votes in favor of and 0 against.

This proposal was modified from the original document to reflect the League's current formalization, as well as reflect the decision made October 1st, 2024 to rename the "decision making group" to "stewards" (link)

Original document, along with discussion: Proposal 1 (The Decision-Making Group)

[Temporary] Bootstrapping Coming to Agreements

This proposal is explicitly temporary, and will be replaced in the future with a more permanent procedure.

Provisional Process of Coming to an Agreement

(Drafted by Alyaza, minor edits by Tenna)

Proposals can be drafted by any steward.

Proposals will seek to have consensus from those around (or explicit approval from 2/3rds of stewards) before being voted on. Once started, the voting period will last no less than 24 hours, and must receive the support of 2/3rds of stewards (excluding explicit abstentions) in order to go into effect.

If a steward expresses they wish to veto a proposal, it immediately fails.

In a crisis/emergency situation, procedure is to exercise best judgement in the moment - there will be a time later to talk things over for a better outcome.

Proposed Principles of the Decision-Making Process

(Drafted by Alyaza, minor edits by Tenna)

The guiding principles for the decision-making process are the Zapatista principles of "good government":

• to serve others not oneself;
• to represent not supplant;
• to build not destroy;
• to obey not command;
• to propose not impose;
• to convince not defeat;
• to go below (listen to the people we are building this for) not above (towards the accumulation of our own power as a group).

This is with the ultimate goal of working for the survival of the collective Website League, and fulfilling any responsibilities that are defined by the communities in the League.

---

Last modified Friday, November 8th, 2024 03:47:42 UTC

This proposal was brought to a vote on September 17th, 2024. It passed with 17 votes in favor, 0 against, 0 abstain, 0 no opinion.

Minor edits were made to the verbiage of the document to reflect the change from "decision-making group" to "stewards", as well as changes to structure. No factual/mechanical changes were made to the proposal in this edit.

Original Document (with discussion): Google Docs: Proposal 2 (Coming to Agreement, Bootstrap Stage)

Steward Procedures

(Drafted by Alyaza, minor edits by Tenna)

Steward Expectations

• Some time available to at least read proposals and provide any input you feel is necessary.
  • Having time to skim chats would also be useful. Efforts will be made to synthesize or copy over any important points to a more accessible venue.
• The willingness to speak up, even if you may be the only one who will for an issue you feel needs addressing.
  • The point of a consensus system is to incorporate everyone's concerns - otherwise, there's no sense in it versus regular voting.
• An openness to changing your mind when others give feedback.
• The willingness to sometimes make compromises, especially about ideas you feel attached to, without feeling attacked or taking it personally.
• The ability to handle and regulate some level of frustration.
  • It is likely at least some conversations in the process will be painful, irritating, frustrating, or long-winded, and this will grate on you.
• The ability to work in good faith with people, even if you may not personally like them.

Principles of the Decision-Making Process

Zapatista principles of "good government" that are the basis of everything else so far:

• to serve others not oneself;
• to represent not supplant;
• to build not destroy;
• to obey not command;
• to propose not impose;
• to convince not defeat;
• to go below (listen to the people we are building this for) not above (towards the accumulation of our own power as a group)

This is with the ultimate goal of working for the survival of the collective Website League, and fulfilling any responsibilities that are defined by communities in the League.

Adding Stewards

There are three ways to become a steward:

• A person (or group of people) apply to start a new node, and voluntarily ask to become a steward.
  • This will require vetting the node itself (for adhering to our requirements), and each member of staff that wants to be a steward.
• Staff of an existing node nominate a new staff member to become a steward, or a staff member asks to become a steward.
  • This will require vetting the individual.
• A steward nominates a new member based on other criteria.

Consensus will be sought on all additions to the group, regardless of the method of joining; if no consensus is reached, they will not be added.

If no consensus can be reached, but the situation is deemed extraordinary (such as a crisis or emergency), a vote may be taken instead. This would require a 2/3rds majority to pass, and any person(s) added by vote must eventually go through the typical process to remain a steward.

---

Last edited Friday, November 8th, 2024 03:10:08 UTC

This proposal was brought to a vote on September 21st, 2024. It passed with 17 endorsements, 1 non-objections, 0 minor objections, 0 stand asides, 0 major objections, and 1 abstain.

Minor edits have been made by Tenna to reflect a change from "decision-making group" to "stewards", as well as minor changes to structure. No changes to facts/mechanical process have been made.

Viviridian added a hyperlink to a page with instructions on how to seek consensus on Loomio.

Original Document: Google Docs: Proposal 4 (Procedures of the DMG)

Responsibilities and Processes for Website League Keyholders

Also available at: https://docs.google.com/document/d/1dn3gQ5BHvBDTwA6WJcdMq7dCy0rxkyuSck0ut2f1iJ4/view

Last updated: 2024-12-13

Rationale

To facilitate collaboration between Stewards, as well as to ensure all users have visibility into the workings of the Website League, the League operates a set of central, self-hosted services. The nature of these services requires a heightened level of trust in people that are given full administrative access to them, as a bad actor could use that access for a variety of malicious purposes (changing access permissions for various users, exfiltrating user data stored on central infrastructure such as emails, messages (both public and private), etc.).

In mitigating this risk, we introduce the concept of a “Keyholder” role. Keyholders are designated Stewards who have full administrative access to central infrastructure services, and are tasked with ensuring that infrastructure remains operational, secured, and up to date. The set of Keyholders should ideally remain limited to minimize the attack surface of central infrastructure, and Keyholder status should only be granted to people who can be trusted with its sensitive nature.

While Keyholders are trusted with access to more of the Website League’s infrastructure, this should not elevate them beyond the status of any other Steward in governance. The purpose of the Keyholder role is to ensure smooth operation of central League services, and to minimize the attack surface of those services by granting access to as few people as possible. Keyholders are not to be viewed as “above” Stewards in any sense, and Keyholders must not abuse their elevated access to attempt to subvert, disrupt, or overrule League governance processes.

Current Keyholders

This list reflects the current state of who is granted Keyholder status. If, at any time, Keyholder status has been granted or revoked from any person, this section of the proposal is to be amended to reflect those changes.

The current list of people granted Keyholder status is as follows:

• srxl (Ruby)
• atomicthumbs
• sirocyl

Audit Log

Any changes made to the list of Keyholders must be logged here, as an amendment to this proposal, for transparency.

• 2024-12-13 - srxl, atomicthumbs and sirocyl formalized as initial Keyholders

Duties

Keyholders have a set of duties and expectations that they must follow as part of their role. These duties are as follows:

• Perform various system administration tasks on central League infrastructure as required. This includes, but is not limited to:
  • Configuring central services and ensuring they function as required by League members
  • Fixing any bugs/issues in central infrastructure identified by League members
  • Assigning/revoking roles that grant Stewards access to services needed to perform their duties
• Providing technical support for central infrastructure services to League members on a best-effort basis
  • This is not exclusively the domain of Keyholders - however sometimes a Keyholder is required to modify central infrastructure to fix an issue
  • Keyholders should, within reason, try to respond to support queries at their earliest convenience
• Perform regular maintenance on central infrastructure to keep services up to date
• Onboard new Keyholders, and offboard former Keyholders as Keyholder status is granted to/revoked from League members
• Send out announcements on the Buttondown newsletter and Broadcast as necessary
• Refrain from accessing any data stored on central infrastructure services, particularly user information or private messages, unless required to carry out any other Keyholder duties

Processes

To ensure central infrastructure operates smoothly, and Keyholders remain aware of how to carry out their duties, there are a set of processes that Keyholders should follow.

• If changes are made to any central infrastructure, ensure that change is documented somewhere. This can include:
  • Bookstack
  • The “Infrastructure Operations” channel in Coordination
  • Consensus, if relevant to a discussion held there
• In the event of central infrastructure downtime (planned or unexpected), League members should be notified through at least one of the following channels, where available/necessary:
  • The Announcements channel in Coordination
  • Broadcast
  • The #announcements channel in the Website League Discord server
• If downtime is planned, an announcement should be made prior to the downtime occurring. The advance notice period is determined by Keyholders on a case-by-case basis, with longer downtimes requiring further advance notice.
• A regular update of all central Infrastructure services should be performed at least once every 3 months.
  • This should be conducted by one Keyholder, who is nominated to perform that specific update by all Keyholders.
  • Unless an update to a service would cause that service to stop working without significant work to mitigate the breakage, all services should be updated to their latest versions during these runs.
  • Any services that are not updated during a regular update should be logged with a ticket in Planning to ensure the update is eventually performed.
• To onboard a new Keyholder, the following tasks must be performed:
  • Create a new user on the central infrastructure VPS, and add an SSH key to that user
  • Add their Authentication account to the following groups:
    • Infrastructure Operators
    • Information Admins
  • Create a login with the requested username and password for Observation
  • Send out an invite to Vaultwarden and grant access to the credential vault
• To offboard a former Keyholder, the above tasks must be undone by removing accounts/keys as necessary.
• When a newsletter issue or a Broadcast announcement has been drafted, one Keyholder should be nominated to send out that announcement.

Access

Keyholders require elevated permissions and access to various central infrastructure services to perform their duties. The additional access granted to Keyholders is as follows:

• Administrator (full) rights on the following services:
  • Coordination
  • Consensus
  • Broadcast
  • Information
  • Authentication
  • Planning
  • The website-league organization on GitLab
  • The Website League Discord server
• Individual accounts on the following services:
  • Observation
  • Vaultwarden
  • SSH to the central infrastructure VPS
• Credentials for the following accounts:
  • @league@websiteleague.org on Broadcast
  • Buttondown account for the newsletter
  • The infrastructure@websiteleague.org email inbox
  • The Google account managing our shared Google Drive
  • The SMTP service provider account
• Entry into the private “Infrastructure Operations” channel in Coordination

Membership

Any Steward can be nominated to be a Keyholder through a proposal on Consensus. The process for nominating a Keyholder is the same as our process for nominating Stewards. Keep in mind that a very high level of trust is required for Keyholders, and as such, Keyholders should only be nominated if more Keyholders are desired, and if the nominee has demonstrated a high level of trustworthiness within the Website League already. Only existing Stewards are eligible to be nominated as Keyholders, to ensure that Keyholders are held accountable to the Stewardship body through the same mechanisms as all other Stewards.

At any time, a Keyholder may decide to temporarily relieve themselves of their duties for whatever reason, such as changes in personal circumstances leading them to be unable to adequately perform their duties as a Keyholder. In this event, access to all services listed under the Access section must be temporarily disabled, and a note is to be recorded in the Audit Log section of this document. At any time, they may choose to return to Keyholder duties, in which case an active Keyholder should re-enable all their Keyholder access and record another note in the Audit log.

Keyholders can also be removed from the role for the following reasons:

• If a Keyholder decides to voluntarily step down from their role, for whatever reason
• If a Keyholder has been inactive and unreachable in an official League capacity for at least 1 month
• If a Consensus vote is held to relieve a Keyholder from their duties for whatever reason, such as abuse of their elevated access or lack of trust by the community