Proposal 1: to define and establish the “decision-making group” for the League and its membership

Details

WRITTEN: September 14, 2024

VOTE: 43 in favor, 0 opposed

PASSED

Text of proposal

The Decision Making Group

The Website League's decision making group is the group of people that will deliberate on proposals presented, and make the final decision on whether proposals will be accepted or not. Ultimately, members of this group 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.

Members of the Decision Making Group

At the current stage of the Website League's development, membership for the decision making group will be voluntary, and open to members that meet any of the following conditions:

• any person that intends to, or expresses interest in participating in the League as a node's staff member, or

• any person with a relevant skillset or previous experience that would contribute to the planning, coding, hosting, organization, advertising, social harmony, or other such need of the League.

Upon formalization of the League, conditions of membership will be modified to be:

• 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 the existing decision making group membership to become a node's staff member within the League, or

• any person with a relevant skillset, previous 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 the existing decision making group membership.

The consensus mechanism through which decisions will be made, the process for formalization of the League, and the vetting process for becoming a node's staff member will be defined in later proposals.

Notes and areas to work on in the future

Nic has proposed the following distinction for nodes:

• "personal" (doesn't need to mean "for exactly one person", but it conveys that it's small and not growing)

• "community" ("community" conveying that it's a large and/or growing node)

It was noted in the Google document to eventually revise these definitions.

Archive of discussion

ALYAZA: this wording--to me at least--seems like it should guarantee all admins have the choice of being in the group, ensures any of the people currently in here are able to be considered for inclusion in the group, and allows for people to be included who aren't in the initial founding base/don't have the time or knowledge to spin up a node themselves but who are recognized as valuable figures for input

• EXERIAN: is there a good reason to restrict the definition of node here to exclude single creature nodes?

  • ATOMICTHUMBS: they aren't responsible for moderating anything except their own behavior. they're sort of halfway between; the technical stuff is important, but they aren't running a subcommunity

    • EXERIAN: then we should alter that one line and then i'm good with that definition. 

    • RUBY: they are still responsible to ensure their space complies with league rules though, and decisions made can involve additional work on their end to bring their instance in compliance

  • ATOMICTHUMBS: there's also special treatment needed there. defederation is basically the only enforcement mechanism that works, and a person in a self-moderated instance could easily turn on their own global feed and harass people, unless we figure out a way to prevent that working. then the only people able to stop them would be other instance admins. that is just one possibility unique to an instance like that

ATOMICTHUMBS: maybe we need a subset of people for technical consensus and a subset for community consensus. not sure.

• EXERIAN: i vote we do not restrict the initial group of nodes and then all nodes joining afterwards needs a consensus. maybe add a stipulation that any admin of a node with fewer than n users for n length of time may have their voting/consensus rights revoked if there is a consensus/majority vote to do so. 

  • PROPOSED DEFINITIONS: 

    • those expressing a desire to create a node by Oct 1

    • subsequent cutoff: a grace period of 28 days, need a user base of at least 10 individuals with at least one moderator who is not also the instance admin

• ATOMICTHUMBS: I can see situations where consensus becomes very difficult. imagine 24 people trying to make a decision. 12 of them represent 8 instances of 500 people total, the other 12 represent themselves

  • EXERIAN: there are two mechanisms i can think of that alleviate this:

    • require a percentage of the governing body to be people who are not admins and who are there for their community building & maintaining expertise. i'm not sure what the percentage should be. 

    • the second is the ability for the users to collective state that their needs are not being met by the governing body. 

  • EXERIAN: does an instance with more than one vote then have more than one person in the governing body who might vote differently or does their one representative's vote count that many times?

• MAYABOTICS: Places where I could see the need for an expedient votes arising are: 

  • intra-server moderation decisions;

  • inter-server moderation decisions

  • network wide technical issues/urgent decisions

  • certain types of server administrative decisions.

• With perhaps the exception of the last two, I see these as referring to consensus within the moderators/administrators involved. Ideally a servers' moderators would be picked by the active server membership coming to a consensus on a nomination, but in practice it might need to be the looser no-objections form or a vote, since it will likely be impossible to get feedback or input from all members of larger servers.

  • RUBY: yeah, intra-server matters should not require league consensus - that's for instance staff to resolve. although a server failing to handle intra-server matters appropriately could warrant wider league involvement. especially if the issues start leaking out into the wider network

• MAYABOTICS: Network-wide governance issues (like changing the Network Code of Conduct or Guidelines) really should be decided by consensus of everyone participating in the network if possible. (Though supermajority failsafe might be necessary here.) The only ways I know to do this are extremely slow, but I think it's necessary for this sort of major but non-urgent decision. Intra-server decisionmaking probably should be left up to the server and it's membership and whatever system they want to adopt.

• MAYABOTICS: I do think that working groups really should make an effort to make sure a diverse array of voices are involved from the start. A lot of this work is probably going to be dependent on voluntary participation though, and only the final proposal needs the broader consensus.

ALYAZA: general notes

• no perfect voting system or decisionmaking system, we'll always make compromises

• as long as we're mindful of the compromises and why we're making them, it'll probably be fine

• we likely want to lean on consensus the most to avoid voting, but voting is probably inevitable in some cases

• we should therefore think about what we want our voting system to be (the 2/3rds majority seems to be an uncontroversial baseline but whether we might weight votes etc. is something we should discuss--that will likely be moreso)

• we don't need to formally make every decision

• there are important distinctions in types of non-support for an idea we should keep in mind (plain "non-support for this idea but no big deal" / "i personally dislike this idea and i won't implement it myself, but others can if it's agreed to" / "i actively oppose this idea" / "i cannot continue to exist in this group with these ideas")

• there are lots of strategies to work through non-consensus, and we should let context guide us on which strategies to use when (for both our own sakes and others' sake)

SPINEFLU: having been a member of a 36-ish stakeholder group that worked on full consensus [modding a 40k+ member deep fb group network before fb introduced Actually Useful Group Controls], I can say that while consensus does work, it may help with expedience to make it "disagree only" with a quorum for a motion to pass, and a regular, scheduled deadline for people to voice disagreement ahead of a move being taken. I can speak more on the case study of this if you'd like.