The process by which we modify how the space operates.
This page describes the Modding process, which is how we modify how Queerious Labs operates. This process is used when there is community-wide impact and when it's hard to undo the change. If the effect of a change is relatively small, or isolated to a few people, or is very easy to undo, probably local consensus among the affected people suffices, and you should operate in Immediate Mode instead.
Mods: Track the state of mods
The progress of a mod is tracked through various states on the Mods page. However, the total history of the mods is kind of hard to use, so the current state of all the mods is kept up to date on the Mods page, in a separate section called Active Mods. The cumulative effect of the modding process is to change the operating principles of the Queerious Labs community, and so we also track the state of those on the Operating Principles page.
After identifying a way that Queerious Labs could be improved, the improvement is brought to a meeting as a new mod. They can either be published on the Mods page or brought to the meeting directly. Mods should be goal's we'd like to achieve, ways that we can better achieve and embody our values as a space and a community, rather than particular changes to achieve those goals. For instance, "Queerious Labs' tools are operational and accessible." is a goal to achieve, but not a means to achieve that goal, and is thus a GOOD candidate for a mod. On the other hand, "Anyone who breaks a tool must repair the tool." is a means to achieve that goal, and is thus a BAD candidate for a mod.
At the meeting, the participants brainstorm possible ways to achieve the goal. All the ideas people can imagine as relevant should be written down and put up on a board. This includes the default idea of "Do nothing."
Ideas are clustered into groups based on similarity: ideas which vary only by specific details (e.g. duration, places, etc.) should be considered equivalent and grouped together. Each cluster should represent a core idea of what kind of action to take, but not the parameters that such an action can have. For instance, "Open hours are from 7pm-12pm" and "Open hours are from 6pm to 11pm" are variations on the same core idea of "There are specified open hours", and so would get clustered together. On the other hand, "There are no specified open hours" is fundamentally a different kind of thing to do, and so would be clustered separately. Clustering is done by consensus of those at the meeting. Clusters can also be deleted by consensus. The result of clustering is a single proposal for each cluster, which is a patch to the pages referenced by Operating Principles as operating principles.
The mod and its proposals are then published on the Mods page as a mod in the state "Rating". The mod should also be published to the Discourse, in the Community Design category. The mod is now in the "Rating" state, and progresses through the following steps:
a. Rating State: Every member of the community has the opportunity to rate each proposals 1-5, or to block it entirely, during the first week of it being published on the Mods page. Members can rate or block any number of proposals as they see fit. Blocks must come with explanations, and should only happen if the proposal is thought to be detrimental to the values of the community. Blocks can take place either in the thread on Discourse for the Mod in question, or it can take place via
firstname.lastname@example.org during either the first or second meeting where the proposals are discussed.
b. Ranking State: During the first meeting after the mod was first published, the ratings for each proposal are averaged, and then sorted, with all blocked proposals sorted after all non-blocked proposals, and then sorted by average rating. A proposal that hasn't been blocked is said to have been accepted. The ratings and sort should be reflected in the mod's entry on the wiki.
c. Implementation State 1: The highest rated proposal is chosen as the proposal to try. The mod and it's top proposal is now in Implementation State 1. If there are multiple proposals that are equally highest, the members at the meeting decide on the order by approval voting on the proposals, each order slot (1st, 2nd, 3rd, etc.). If within each slot there is a tie, then the tie is broken by random choice, and the winner is removed from the remaining order slots since it has been chosen for a higher slot.
d. Implementation State 2: After one month at State 1, the mod is brought up for review. If no one wishes to add more proposals, the mod and its top proposal progresses to Implementation State 2. If anyone DOES wish to add more proposals, this is done, and we return to the step 3 of the modding process, tho old ratings are used by default for pre-existing proposals in absence of new ratings. If after ranking, the top-rated mod is still the same, then it also proceeds to State 2, otherwise the top proposal changes to the new one, and it enters State 1 as usual.
e. Implementation State 3: After two months at State 2, the mod is brought up for review. If no one wishes to add more proposals, the mod and its top proposal progresses to Implementation State 3. If anyone DOES wish to add more proposals, this is done, and we return to the step 3 of the modding process, tho old ratings are used by default for pre-existing proposals in absence of new ratings. If after ranking, the top-rated mod is still the same, then it also proceeds to State 3, otherwise the top proposal changes to the new one, and it enters State 1 as usual. When a proposal reaches State 3, it is considered Implemented, and the modding process stops.
In the future, after a mod has reached Implementation State 3, a new modding process can be started, for the same mod. All of the previous proposals should be carried over as initial proposals to start clustering with, and a new version of the mod should be created (which will supercede the old version once it reaches Implementation State 1), tho the old ratings should be discarded.