Proposal 2: process of coming to agreement in the bootstrapping stage of the League

Details

WRITTEN: September 17, 2024

VOTE: 17 yes, 0 no, 0 abstain/no opinion

PASSED

Text of proposal

provisional proposal

1. proposals can be drafted by anyone in the decision-making group

2. proposals will seek to have consensus from those around (or explicit approval from 2/3rds of the decision-making group) before being voted on

3. proposals will then be voted on, with a voting period of at least 24 hours

4. proposals must receive the support of 2/3rds of the decision-making group to go into effect (ignoring explicit abstentions)

5. if a member of the decision-making group expresses they want to veto a proposal, the proposal also immediately fails

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

proposed principles of the decision-making process

my suggested guiding principles for the decision-making process are the Zapatista principles of “good government”, which are:

• 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 (to listen to the people we are building this for) not above (toward 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.

Future potential amendments/modifications

PROPOSAL 2a by wenchcoat: mechanical procedures of consensus

Initial proposal

we want to lean on consensus

consensus will be achieved between prospective node operators and others who bring relevant experience to the table

when consensus fails, we fall back on a vote

• how does the vote operate? i think in the bootstrapping phase, the 67% majority system is acceptable, but later on it may not - this should remain open to modification when we are more established, but in the interest of being able to get stuff moving quickly, i don't anticipate any major issues going with 67% majority vote

once we are established (some formalization process? once nodes are operational?), consensus becomes:

• founding node operators

• current node operators

• people with relevant experience

• anyone agreed through consensus of the prior 3 to be involved in the consensus process

Archive of discussion

questions (carried over from Proposal 1)

• how much voting power should be given to personal nodes, and what is the best way to represent their interests versus community nodes?

  • Wenchcoat notes: "too many voices in the consensus pool clogs things up badly. we want to avoid that; too much decisive power for small nodes makes the decision to add them far heavier."

• how can we ensure personal nodes aren't used to hijack the League (for ex: if someone were to demand a large number of personal nodes receive voting rights)?

• what limits, if any, might be imposed on personal nodes to prevent such an attack (this question seems to have been the initial basis of the section of notes i'm calling chunk one)?

• if several nodes of a similar type are a part of the League, should they be given representation (and the right to decide on someone to represent them) in the decision-making group?

wenchcoat notes

• too many voices in the consensus pool clogs things up badly. we want to avoid that.

• too much decisive power for small nodes makes the decision to add them far heavier.

• single-creature nodes probably shouldn't have much power. they represent only themselves and without the right handling could be played for leverage by bad actors.

• but small nodes, even two or three users, represent real community bonds and shouldn't be drowned out entirely.

exerian notes

• if you are the admin of the node and you are the only one that's actually using the node but all the other nodes have a bunch of people on them, should you really have a personal vote in the governing body since you're really just the one person?

• i will personally be voting that we make this place as welcoming as possible for single creature instances. hopefully we'll get several and rather than just not have a single creature node admin in the governing body i would want all of the single creature admins to nominate someone to represent the intrests of single creature nodes in the governing body.

mayabotics notes

• 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.

>>>>>>> (artemis) notes

• Per discussion of small nodes, i think there’s a useful distinction to be made between voting and non-voting nodes. Many may not actually be interested in the decision-making process, and that’s fine as long as they’re willing to take the results of decisions as they come. Other node operators may be interested, and I think there is value in that if they are participating on behalf of the network as a whole. Certainly anyone voting, no matter what node they’re on, is imposing their view of what they believe the network should be. that is after all the point. Someone without other people to represent may see things differently than someone with; question is, is that valued?

  • (What challenges would a category of non-voting single/small nodes impose?)

Froggebip notes

• I kind of feel like, to keep things flexible in the bootstrapping phase, instead of coming up with a solid definition of “established” (at which point we switch to our new limited group of deciders etc.) we can say something along the lines of “established status will be ratified in a future proposal.” Essentially a switch we can flip on when we’re ready, rather than getting bogged down in definitions of what our starting point officially is.

• These principles of governance will be a helpful mantra for me 🙏

• I think 1 representative for all personal nodes is a good starting point. We may need to (and should leave room to) tweak this balance later, based on e.g. the number of personal nodes and the average user count of community nodes. Those metrics feel really difficult to anticipate right now.

• I share exerian’s view that personal, single-creature, single-body, and otherwise small friend-group nodes should be maximally welcomed, so whatever we decide on their voting power should reflect that

• If we’re running with the “no objections, if not full agreement” idea of consensus, then I do think 100% consensus is something we should strive for. If we are running with the “full agreement only” idea of consensus, I’m less certain. 67% seems okay in that scenario, depending on the importance of the decision.

Nic notes

I'm specifically thinking about:

• How many big decisions that require active buy-in from people will we be making? Probably not a lot past the initial startup

• How much does "we must be able to post a public poll" and "we must provide push notifications" lock us down, platform-wise?

• Presuming we move off discord (because I think we should; I'm already sick of writing paragraphs into a five-line text box) how can we invite community feedback without requiring everyone to make yet another account?

Atomicthumbs notes

i worry about the potential to make all of this way more complicated than it has to be, to the point it will immediately deter people wanting to set up a server

if I came in here having just found out about the project, not knowing anything yet, and wanting to participate, the pages and pages of discussion on the minutiae of decisionmaking mechanics would cause me to give up and leave the discord server.

they are important to set up for the future but we need to boil this down to the simplest system possible or we will get nothing done 

the discussion needs to be had but we also need a cohesive set of rules and procedure that fit in like, three paragraphs maximum, and not big ones

i don't want this system to die because it immediately sprouted a bureaucracy before needing or being able to sustain one