WIP: Proposed Consent-decision process v2

Clearing the Path Governance
#1

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-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:.
  • 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 https://patterns.sociocracy30.org/test-arguments-qualify-as-objections.html

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.

2 Appreciations
Using GitLab for seeking and integrating objections
Reviewing the process for consent decisions
#3

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.

2 Appreciations
#4

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 Appreciation
#5

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.

#6

Fixed.

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 Appreciation
#7

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?

#8

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 Appreciation
Add asynchronous decision participation to team agreement? [NO]
#9

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…

2 Appreciations
#10

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.

2 Appreciations
#11

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?

2 Appreciations
#12

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.

#13
  • Added a driver statement
  • Increased review date
  • Made the reference to S3 at the beginning easier to read
  • Allowed to skip or lump together parts of the process

Mild concerns left:

  • I feel like we’re changing too much right now, and not on the basis of objections. The others will have to read through all the changes for the final consent decision, so every change has its cost. Maybe we shouldn’t start at the wiki when reviewing? Maybe we should require each change in the wiki phase to also provide an objection that motivates it?

  • Now that I’ve added the driver we originally had for this (See Consent processes for meetings vs forum or other asynchronous), I think parts of the process are a bit wasteful towards this driver. We might want to delete some bits, or split them into their own documents.

I think the best use of time would be to involve the others now, by pinging/inviting and/or starting a consent decision. (Even if it makes sense to still change the proposal, it would be best to focus on what are the most important problems.) @wolftune do you want to do that? I feel less ownership since you changed quite a bit.

2 Appreciations
Why asynchronous consent decisions in the first place?
#14

Yes, I’ll take this on.

Because it led to extra noise and confusion, we turned off the assign plugin here in the forum. I think this v2 idea really needs to get to a good point, capturing those concerns and then do a consent decision to make a jump to an updated (and split up) v2. Evaluating it will need to just be a read of the proposed final-draft of v2 rather than tracking all the changes.

I opened this task for myself: https://gitlab.com/snowdrift/governance/-/issues/69 and plan to do that this week

1 Appreciation
#15

I feel similarly, actually about this whole v2. I feel like I have a decent handle on v1, but we’ve barely used it. I don’t really remember what tensions this is supposed to be addressing, and right now it feels like reviewing these changes is more effort than living with whatever imperfections are present in v1.

Is there a driver for why this rewrite is necessary? Without that, I don’t know how important it is to solve these tensions, so I can’t weigh them against the effort to engage with this post.

1 Appreciation
#16

See the discussion from which this was forked Reviewing the process for consent decisions (it’s linked at the top here as well). The context is pretty clear.

This is a case where v1 was essentially “something for now” and wasn’t worth objecting over being imperfect. But the whole writing wasn’t great, the format wasn’t great, lots and lots of room for editorial improvement. And I expressed that in the discussion I just linked.

But here’s a more formal driver:

Without the process itself in place when we developed and agreed on the first version, we had to wrap up the long and messy process to get to a starting point for iteration. Now, we need to make it easy and accessible for everyone (including newcomers) to easily read and understand the process. By overhauling the formatting and structure (and addressing concerns that arise while working through that), we can get a better reference which will be easy to iterate on going forward. With that in place, we will be best set to follow the process successfully on all our future decisions.

2 Appreciations
How to proceed with the process for consent decisions
How to proceed with the process for consent decisions
#17

Marking “WIP:” in topic titles

As would be done on GitLab, putting “WIP:” in the title might be a good practice as part of the process in order to signal to people that identified improvements are not yet captured. Thus, anyone wanting to help with drafting could help but those wanting to wait to review a more completed proposal should wait.

Thoughts?

Another concern: GitLab is better for reviewing. I think we should consider (but perhaps not part of this v2 overhaul?) using GitLab for its better diffs and review process. The primary downside is that fewer of the general public co-op members etc. will use GitLab, and we don’t want GitLab-user bias in decisions. Perhaps we could do a better hybrid. Just as we capture formal docs in GitLab, we also do work there (rather than here) but we post here and welcome anyone to give feedback here and do any final consent-decisions here.

I’d suggest we allow use of GitLab, especially to collaborate on WIP updates (similar to how any of us could have a meeting and use etherpad while coworking on something). We don’t need rules about tooling except when it comes to doing the official consent decisions. Right? Thoughts?

#18

This post was flagged and temporarily hidden.

2 Appreciations
How to proceed with the process for consent decisions
#19

Some input on how it could be split up (while simultaneously avoiding big changes to the current document):

Actually, the original intention was to specify how the actual “check for objections” step can work on the forum. See the oldest version of the original process (by clicking on the pencil and navigating to the oldest version). The “How to create a proposal” and “Reviewing decisions” sections in the current process were added later as part of restructuring etc.

In fact, the original driver was (though I put it into these words only recently, explanation here): “We don’t want to expect every team member to show up at the weekly meetings. Thus we need to check for objections in a way that enables people to contribute asynchronously.” This was fulfilled well by specifying how the “check for objections” step can work on the forum. (The rest is basic forum usage.) Anything we add beyond that is (mostly) waste towards this driver – thus it should be motivated by its own driver, and belongs in an additional document.

This is the tension that motivated introducing the wiki thing. I would argue that it relates only to the “How to create a proposal” section, and that this section along with the fix should become a new document.

2 Appreciations
#20

I’ve edited this to say “check for objections” instead of “do consent decisions”, as this is what I meant. AFAICT, the term “consent decision” is slightly confusing, because it can either mean the Consent Decision Making S3 pattern or the actual step of the process where a “consent decision” (i.e. a decision made by consent, i.e. in the absence of objections) is made. I’ve used “consent decision” to mean “seeking and integrating objections”. Probably I should not have used the term that way :slight_smile: – I now see how this probably contributes to the difference in viewpoints on what the process is there for (e.g. whether Navigate Via Tensions is related to it or belongs somewhere else).

1 Appreciation
#21

I changed this to say “check for and integrate objections”, since this is obviously what I really meant :slight_smile::

I think seeking and integrating objections belong into the same driver, because the process(es) for these two things heavily influence each other. For instance, the current draft says:

1 Appreciation