Accepted Proposals

These are proposals that have been voted on and have been accepted by stewards.

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:

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


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":

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

Principles of the Decision-Making Process

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

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:

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:

Audit Log

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

Duties

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

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.

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:

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: