Continuing the discussion from Reviewing the process for consent decisions:
Here is a proposed overhauled update of the consent-decision process for the forum (this is a wiki post). Below is the entire proposed updated document:
Consent Decisions on the Forum
The following consent decisions have been made (i.e. reached consent) about this process itself:
- Closed 2020-02-03: Process for consent decisions on the forum - #22 by photm
- Closed 2020-02-13: Resolving concerns to process for consent decisions - #5 by photm
- Closed 2020-04-25: Reviewing the process for consent decisions - #12 by photm
Next review: 2020-09-01
Why do we have this process? We don’t want to expect every team member to show up at the weekly meetings. Thus we need to check for and integrate objections in a way that enables people to contribute asynchronously. (This type of statement is called a “driver” below.)
We generally follow the S3 (short for: Sociocracy 3.0) patterns related to Respond To Organizational Drivers, but we have adapted them to our tools and combined them with other ideas. (See the S3 Concepts and Principles for more background. You don’t need to perfectly know S3 in order to understand this document.)
Any forum user may initiate the process, but final decisions must get consent from roles that cover any affected domains. Feel free to skip any steps or take multiple steps at once as you think is appropriate. (For example, it’s fine to post a simple driver + proposal and start the final consent decision at once.)
Notice tension(s)
Based on the Navigate Via Tension pattern.
- Check how you feel about the project and your relation to it
- Take a few minutes to bring thoughts to mind
- Notice emotions, body sensations
- Write about any tensions on the forum
- Describe the facts using unarguable language (i.e. what a video camera could show and what raw sensations you experienced)
- Separately, describe the stories you have about the tension
- For the stories, consider using Driver Statement format, but don’t worry about being pedantic
- If resolution comes from the initial processing or immediate discussion, great! Perhaps existing issues already capture the concerns. Otherwise, continue:
Describe driver(s)
Before forming a proposal, we first form a driver statement. To kick this off, post the draft of a driver statement and proceed as described below for “Forming proposal(s)”, including the consent decision. Use the #driver
tag instead of #proposal
.
Forming proposal(s)
Given a clear driver statement that has consent, write a proposal:
- Start with something simple to try — even if it doesn’t solve the problem completely.
- Get the initial draft published without too much delay. Timebox for a few hours at most.
- Add the driver statement to it, as part of the proposal.
- Add a review date as part of the proposal. If unsure, place it 6 months ahead.
Once you have the draft of a proposal:
- Post it on the forum
- Make the post a wiki
- The setting is in the admin wrench below the post.
- If you lack the permissions, ping
@staff
for someone else to do it.
- Mark the topic with the
#proposal
tag. - Use the share function to invite specific people you think should help with initial drafting
- Collaboratively develop the draft
- Has the drafting process stabilized?
- Perhaps all active drafters are satisfied?
- Perhaps there’s no activity for a couple days
- Given a potential final draft, invite all relevant roles to the topic to assure that anyone affected has a chance to weigh in.
- Once the drafting has stabilized again, we’re ready for a consent decision!
Start a consent decision
-
Edit the final-draft post for a driver or proposal and add the following notice at the bottom (available from the canned-replies feature):
`=== Consent decision ===` Are there any objections :gift: / concerns :thinking: to the above? (Let's take 7 days for this.)
-
Remove the wiki status (or ask someone from
@staff
) -
Add the
#decision
tag to the topic -
Invite either the whole team or the relevant circle
How to participate in a consent decision
All forum users may participate in consent decisions including raising objections or concerns.
- An objection is an argument demonstrating (or revealing) how a (proposed) agreement or activity:
- might lead to unintended consequences
- or can be readily improved enough to be worth delaying the decision
- A concern is an assumption that doing something (even in the absence of objections) might stand in the way of (more) effective response to a situation.
Only objections block the decision. Concerns may be discussed, of course, and if that leads to worthwhile updates, those could be included in separate consent decisions.
To participate:
- Read the proposal thoroughly and ask questions if you don’t understand everything.
- If you have an objection or a concern, explain it in a reply.
- Mark objections with
:gift:
and concerns with:thinking:
.
- Mark objections with
- Other responses may include marking appreciation with the thumb’s-up button and/or posting a reply. This will make it explicit that you’ve read the proposal, even if you didn’t find objections or concerns.
- Participate in any follow-up discussion. Contribute ideas for improving the proposal in a way that fixes objections.
Finalizing a consent decision
Accepting consent requires:
- At least 7 days after the invitation to all relevant roles
- At least 4 days without edits
- Explicit consent (by marking appreciation or replying without denoting an objection) from the greater of 2 people or 20% of the relevant roles
- No outstanding objections
A team member may then mark the decision effective by posting a celebration notice (the default below is available in the canned-replies).
Looks like we have consent! :partying_face:
Feel free to edit the exact content of the notices where appropriate.
How to integrate objections
Once there’s an objection:
- Discuss possible ways to integrate the objection with the objector and the entire group
- Objectors should give others time to propose amendments, instead of rushing to amend themselves
- Once there’s a good amendment:
- Quote the amended section in a new reply
- Add a new consent-decision notice in that reply
- Include @ mention to prompt the relevant roles to the new consent decision.
How to deal with invalid objections
Only team members may formally disqualify objections. Here’s how to proceed:
- Try to integrate the objection anyway. If there’s a good way to integrate it, there’s no need to disqualify the objection.
- Discuss the matter with the objector. If you can convince them while the decision is still running, they may drop it. If they’re convinced only after the time is up, start a new decision. Be open to the possibility that the objection is valid after all.
- If the matter really cannot be resolved differently, here’s how an objection can be disqualified formally:
- A team member starts a consent decision, proposing to disqualify the objection. Give a good reason, i.e. an objection to the objection. Make it clear that only team members can participate in this consent decision.
- Start a new consent decision for the original proposal that was objected to. Make it clear that the original objection cannot be raised again. Be friendly and open to other objections from the original objector.
See Test Arguments Qualify as Objections
Making minor/trivial changes
The following changes can be made to proposals/agreements at any time:
- Trivial changes, i.e. typo fixes or changes in formatting
- Minor changes, i.e. small changes that don’t impact the implementation of the agreement; but make sure to post a reasonably precise statement summarizing any minor changes.
Reviewing decisions
The secretary is accountable for tracking review dates, starting reviews, and updating the review dates into the future.
A review follows the same process as initial drafting but starts the wiki post with the existing agreement.
The power remains with the team
The team invites all forum users to participate in consent decisions. However, it reserves the right to withdraw this invitation. When team members start consent decisions, they have the option to specify that only team members can raise objections. Once co-op Bylaws are finally in place, authority will be determined as to the degree of autonomy of the team or the power of the co-op membership.