Proposed Consent-decision process v2

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:

Next review: 2020-07-18

We generally follow the S3 patterns related to Respond To Organizational Drivers, but we have adapted them to our tools and combined them with other ideas.

Any forum user may initiate the process, but final decisions must get consent from roles that cover any affected domains.

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


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.


I like the thing overall.

  • It has now become very long, so maybe we could consider splitting it up? (Maybe we could organize the different chunks according to the S3 patterns they fill with specifics? E.g. “Navigate Via Tension”, “Describe Organizational Drivers”, “Consent Decision Making”, etc etc – see Co-creation and evolution for the list)

  • (Rhetorical question) Why do we ping certain people earlier and some later? Are the people we ping later less interested in the agreement, less related to the domain? If so, why are they in the circle that has this domain? I feel like we should always involve everyone – if this doesn’t work, it’s not the decision process which is broken, but the circle structure. (We can also have smaller circles raise proposals in bigger circles. We can even have temporary circles if we want to.)

  • Whether or not we should consent to drivers is an interesting question. AFAICT in S3, whenever a process does something based on a driver, it always begins with a “consent to driver” step. However, what decision is made by consent there? The decision is whether to spend the time on the driver. (Or whether the driver should be changed before it is worth spending the time on it, or it should simply be dropped.) We don’t really spend meeting time on the forum, but is there something we spend if we agree to continue the process given the driver? If there is, we should probably consent to it.

  • Wiki edits are allowed by anyone and we don’t require them to provide a reason for their change. The only safeguard is that there’s a consent decision afterwards… Is this what we want? People could, e.g. change the driver to be about something different, and if that other thing is also worth the time, there will be consent. Then the original thing won’t be done, even though there was no reason for doing something else instead. This can easily happen by accident.

I wonder how we can avoid talking about details here (or designing too much for future requirements that we don’t know well yet) and move forward :slight_smile:. Maybe this will simply sort itself out by a) we fix the TODOs, b) people edit things they think are important enough for their time, c) if something is left that really needs to be fixed, it will surface in the consent decision.


I fixed all the TODOs, except two that I removed, because I was uncertain any change was necessary (or what to change):

  • [TODO: @moderators instead?] (i.e instead of @staff)
  • [TODO: assign drivers to particular roles/domains! Perhaps others ask to help? Delegation? How okay is it if anyone starts proposing whatever? Perhaps roles can choose how open they want to be to inviting anyone to make proposals?]
1 Like

Isn’t a reply with concern (but not objection) also explicit consent?

I was meaning it more like acknowledging that it is possible and okay to invite certain people who might appreciate the ping. So, if I’m working on a proposal and happen to think that a certain person would be good or available to help, I could mention it to them rather than just hope they see it in the general forum activity. But since this is a casual thought, we don’t need to include it in the process explicitly. I just didn’t want it to seem like the only way to draw initial attention is by hoping people see the post.

That’s a good concern to bring up. I think whoever starts the draft should “own” it so to speak unless they delegate it to someone else. That person should review the edits.

Otherwise, there’s always a chance to kind of see if the initial tensions seem resolved by an end proposal. And if they aren’t resolved, they will likely arise again.


I’m OK with the current approach regarding the other topics I raised. I think it is very possible that people would behave the right way naturally – we should try it out.

1 Like

I have some desires to clean things up further given some feedback above. I hope to get to that soon and then move this forward.

Another concern: what happens if we do not get consent? What if not enough people respond? What if the decision is to not go ahead with any proposal? Is that possible? Or is it more that we need to address any tension, and we’ll consent on some proposal. Maybe the consent decision is to make no changes and that still counts as a decision?

After the process is done, do we keep the tags?

When there’s an objection, and we’re dealing with updating the proposal, do we remove the #decision tag and then add it again when a new proposal is ready for a consent decision?

Participating as a circle member should maybe become part of the team agreement. Beyond that, this problem would likely occur if decisions are not important enough. Maybe we should have a prioritized backlog of decisions to make, sort-of as if we had meeting agendas to fill? This way, the less important things could be captured but they would get less time. (But let’s not over-optimize here, this is for a separate proposal/decision if at all.)

I think if there’s a driver, then it should always be possible to agree on some proposal, possibly after lots of discussion. If it turns out to be impossible/hard, then maybe we should review the driver at some point.

1 Like

I notice sometimes it feels pedantic to do any of this process when something seems simple, but then I realize it’s nice to make sure we have consensus. However, I find myself making driver and initial proposal at once.

This seems better than only doing a proposal without a driver. Without the driver, people may be confused why the proposal is needed. And posting at once still lets people challenge or adjust the driver, including scrapping the proposal if we don’t agree on the driver or it changes a lot.

Is it okay that I’m lumping them at all? Should we always first just have the driver and not post any proposals until we have agreement on the driver? If so, I guess one could note proposal ideas to themselves and just not share until that stage. I do know that it somewhat affects the flow if a driver is first presented already with a potential proposal…


This is also a concern I have myself: I feel like it should be possible to make the process more lightweight and flexible, so that it gets out of the way when the driver/proposal is not controversial. I think the consent decisions used in S3-style meetings are lightweight in this way. (If there’s consent, it takes 10 seconds for everyone to raise their thumbs. But if there’s an objection, or an objection to an objection etc, the entire process is there and can be used.)

The first advantage of being lightweight is not feeling pedantic. The second one is: You can easily use it all the time to bring consent into more places. For instance, in proposal forming (S3 pattern) you can do a quick consent round using hand signals after each step (e.g. consent on “is the list of consideration questions good enough for now?”). This is very much impossible with our process currently.

I think it makes a lot of sense to do so, or at least try it out. After all, if you “find yourself” doing this, then it’s the natural thing to do. We could easily find ourselves doing this more in the future, so we might as well try it out formally to see if we like it.


We could make it explicit that all these stages (tension/driver/proposal/consent) are useful to build the strongest decisions — but the heaviness (especially in non-real-time on the forum) is often too costly.

So, we could say that anyone can lump together or even skip any part of the process if they think it’s unnecessary (e.g. even jumping right to a simple proposal with consent decision open immediately). But anyone may object with a call for doing the full process.

Does that make sense?

1 Like

This seems absolutely reasonable to me. \o/

Totally agree, it’s ideal to have both (if one comes first I think driver statement), but this is a good baseline to shoot for (to knockout both in one fell swoop in order to optimize time and streamline the process), and allow people to make decision to bypass any aspects they deem fit.