Reviewing the process for consent decisions

Clearing the Path Governance
#29

Well, there’s an “expand” function at the top post where it quotes the “solution”, so you can expand there and still be looking at the top post, not the actual decision post.

On tags

I agree that we should use tags specific to circles. But let’s populate those as we clarify and make more use of circles. So, let’s go with #decision for now, set all team members to watch that, and only use it when we have a decision-point (not during proposal development).

I made a tag group for Sociocracy processes, by the way. We can keep #proposal as a tag just for organizing even if we haven’t agreed on a formal use of it yet (but we should use it to mark wherever we know that we’re discussing a proposal). When we have a decision that is only for a particular circle, we’ll then make the appropriate circlename-decision tag.

2 Appreciations
#30

If this were a formal proposal, I would “consent, with (serious) concern.”

Concern: This seems like a lot more complexity than necessary.

Alternative:

  • One tag, #driver,[1] applied to any post where the objective is to finalize a proposal and have a consent decision.
  • When we are ready to have a consent decision, post the full text of the proposal, tag @ team, and mark that post as the solution.
  • When the voting period is over, remove the #driver tag.

This has the following outcomes:

  • All team members would receive a ping when their input is requested, with a different icon in the notification (@ vs an arrow), making it clear their input is requested.
  • You can see all decisions in progress by viewing topics with the #driver tag.
    • From there, you can see which are being voted on (solution is marked).

  1. I'm not sure if this is the right name ↩︎

3 Appreciations
#31

But this is no more complex than Sociocracy ideas themselves. Tags should not be thought of as complex, they are a simple tool we should readily use.

Drivers and Proposals are not the same thing. The idea is indeed to apply tags to posts where driver statements or proposals are getting worked on towards a consent-decision. I see no reason not to have separate #driver vs #proposal tags since they are different steps.

This really gets to my point: driver statements being developed is a different thing than developing proposals. The concept otherwise works, but we should have both tags.

I think maybe the better option is to keep the #driver and #proposal tags but use “solution” correctly: mark the final driver statement or accepted proposal. Then, we can see in-progress ones by seeing unsolved topics with those tags.

#32

That seems reasonable and simple enough to me

not sure what that meant, btw?

#33

The proposal discussed today at the meeting:
Use a poll to finalize draft before the formal consent process begins
(on a new thread to keep it obvious and pinned, otherwise will be marked as solution on the discussion thread?)

This will provide an additional buffer for getting input from someone who might miss the deadline of only one poll, etc…

trying to get the workflow right in my mind:

  1. draft proposal and discuss in a thread
  2. poll to move forward with the final draft and make formal proposal
    • if no objection, the proposal is accepted
      • if anyone has an objection, it can be discussed and if resolved without making any changes, the process moves forward.
        • if it is not resolved, or the resolution requires a change to the proposal, a new proposal must be made (as edits trigger the necessity of a new proposal, correct?)
      • if someone notes a valid concern and there’s some degree of consensus that it would be worthy of changing, it also triggers a new proposal? (hopefully this doesn’t happen much as the proposal wouldve gone through a draft process already)
        • I guess one way of instigating this that could be for someone to make their vote into an objection

Just checking to see if I got this right, and we need to make this into a new proposal process anyway :pray: thanks

@wolftune we didn’t make an official next step on the notes but I think you might of intended to do this

#34

Thanks, I indeed was thinking I was taking the task. I see it like this:

  1. Drafting (of either drivers or proposals) in topics, tagged appropriately
  2. When those doing the drafting feel something is a candidate for a consent-decision, it gets marked (how?) as such and the team (or maybe circle if it’s in a specific scope) gets pinged
  3. After some delay (how much?) to give others a chance to participate in further drafting, then a formal consent-decision point is posted

The key is that it can feel awkward if the first reading is also the time to consent. That situation means any update needs either an objection or a later revision process.

Another summary:

  • Bad: ping everyone at the beginning (too much distraction, not everyone can take time to help with every draft)
  • Mediocre: ping everyone only at decision time (people who might want to discuss the draft feel pushed to already consent, feels extra formal)
  • Nice: ping everyone toward the end of drafting but in advance of the formal decision. Gives people a chance to participate while it still feels like open drafting time.

In short: add a delay between announcing a potential final-draft and posting the consent-decision (which may then have some updates). Probably ping everyone at both those times though.

@iko does this seem right by your thoughts on this?

2 Appreciations
WIP: Proposed Consent-decision process v2
#35

I meant maybe #governance or #sociocracy or something else makes more sense as the name of the tag.

1 Appreciation
#36

I agree completely. The thread Consent decision: allow minor edits during consent decisions is a good example of beginning with a consent decision immediately only to notice that more discussion first would have been good.

The reason I removed the “feedback phase” was that there was duplication between a) responding with feedback and b) responding with concerns/objections. The latter is simply the same as giving feedback, but you also attach prioritization (objection vs concern) to it, which is a good idea I think.

The roundtrip necessary for a change in the feedback phase is this: You read the proposal, notice a problem -> verbalize what is wrong and why, post it -> discuss until author agrees -> author edits proposal -> you review if that fixes the problem.

How about reducing it to “You read the proposal, notice a problem -> you edit the proposal”? The entire process would be this:

  • Post a first draft of the proposal, make it a wiki
  • People can edit/discuss as much as they want
  • Once the draft stabilizes, start a consent decision

This way, you can easily contribute before the actual consent decision starts, and it’s very clear to everyone where in the process we are. I also like how well the co-editing stuff works, e.g. over at Driver statement for better milestones and roadmap etc I felt we were really productive.

I see how it would make sense to ping people at just the right moment, but I think this can be done without a formal process. Getting this just right in the process would be “perfect is the enemy of the good” I think. However, maybe the process could be:

  • Post first draft as a wiki
  • Once there’s no activity for 2 days, ping the team
  • Once there’s no activity for 2 days (at least 2 days after the ping), start a consent decision.
3 Appreciations
#37

I like this direction a lot.

A thought I offer for consideration: Maybe a more nuanced human-judgment of pinging the team when the active editors think it’s a good time. No-activity-for-2-days can be a fallback or rule-of-thumb. So, someone could say, “let’s ping the team now” and get buy-in on that, sorta like an informal consent from whoever is active. Also, maybe the human judgment is: “I can’t work on this more until a few days from now, but it’s not ready for pinging the team yet” and so it’s okay that it sits for more than 2 days without activity.

So, rather than the 2-days criteria, I suggest a wording that just captures the gist of when to ping as a judgment call.

I like the idea of a time-frame stated between pinging and resolution after that and starting the constent-decision. I could see giving the team more than 2 days to notice the ping and engage but not sure.

1 Appreciation
#38

I guess the best way forward is to try the wiki thing with the process itself, so here’s the entire document – feel free to edit anything if you think your change has consent:

The draft has been moved to Proposed Consent-decision process v2 (and changed significantly) – the version before the move can be viewed here:

The old draft version

Process for 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

How to create a proposal

Any forum user can start the decision-making process. Begin like this:

  • If possible: Before coming up with solutions for a problem, write about the problem on the forum and get feedback. Make sure everyone agrees it’s a problem that should be solved.
  • Write a proposal for something simple to try, even if it doesn’t solve the problem completely. Don’t waste time on this step. Timebox for a few hours at most, write the best proposal you can write in this very short time, and get it out there soon.
  • Add a proposed review date to the proposal. If unsure, place it 6 months ahead.

Once you’ve written the draft, post it on the forum and make it a wiki by using the admin wrench below your post. If you lack the permissions for doing so, ask {TODO: Who should they ask?} to do it for you.

Once you think the proposal has stabilized and is ready for more attention, ping @-team in a new reply. For example, you could do this once the last activity was 2 days ago.

Once you think the proposal has stabilized again and is ready for a consent decision (you could do this after another 2 days of no activity), proceed like this:

How to start a consent decision

Edit the forum post with the 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.)

Additionally, remove the wiki status (or ask {TODO: Who?} to do it for you) and reply to the post to ping @-team.

If there’s no objections after 7 days and at least two team members (forum group) have consented explicitly, anyone – including you – can post a celebration notice (the default below is available in the canned-replies). That marks the decision effective:

Looks like we have consent! :partying_face:

Feel free to edit the exact content of the notices where appropriate.

Reviewing decisions

On the review date, we will follow the same process again — this time starting the wiki with the current agreement. It’s the secretary’s job to kick this off and to propose a date for the next review by editing the review date included in the agreement.

How to integrate objections

Once there’s an objection:

  • Discuss possible ways to integrate the objection with the objector and the entire group
  • Give the others enough time to propose amendments, instead of rushing to amend it yourself
  • Once there’s a good amendment: Copy the proposal into a new wiki post, edit it there and proceed with the usual process as described above. This time, don’t ping the team in the wiki phase, only ping it for the consent decision. Please also edit the old proposal to add a disclaimer that links to the new one.

Doing 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. If you make a minor change, also post a reasonably precise statement of the change you did.

How to participate in a consent decision

All forum users may participate in consent decisions. You can raise any objections or concerns you have:

  • An objection is an argument demonstrating (or revealing) how a (proposed) agreement or activity can lead to unintended consequences, or that there are worthwhile ways to improve it.
  • 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.

The proposal is accepted if no objections are raised – concerns can be handled in separate consent decisions if it’s worth to invest the time. (See objection (S3 pattern) for more background.)

To participate, do the following:

  • Read the proposal thoroughly, ask questions if you don’t understand everything.
  • If you can find 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 (esp. nice if someone is elected for a role). 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.

How to deal with invalid objections

Only people in the team (forum group) can formally disqualify objections. Here’s how to proceed:

  • Try to integrate the objection anyways. 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 can still 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.

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 at any point.

When team members start consent decisions, they have the option to specify that only team members can raise objections. If they want to permanently withdraw the invitation, a consent decision can be made to remove the invitation from this very proposal.

Open problems:

  • Who should people contact for help if they don’t have the permission to make their post a wiki? (Needs changes in two places above, marked with TODO)

  • Objections cause a huge interruption because the proposal needs to be copied to a new wiki post in order to remove appreciation marks from people who gave their explicit consent to a previous version.

Consent decision: Allow minor edits during consent decisions
Consent decision: Allow minor edits during consent decisions
#39

Hmm, I don’t like how the current draft handles objections. It says to copy the proposal to a new wiki post, edit it there, then make that a new consent decision. This means objections interrupt the whole process and feel very second-class in comparison to editing the proposal in the wiki phase.

Objections should simply be saying “Here’s a problem, I just don’t know how to fix it”. However, since we want to check for consent on the new version of the proposal after the objection is integrated, we need the new version to be in a new post – this way the appreciation marks are removed.

The only reason we need the appreciation marks to be removed is because of the quorum (i.e. we need at least two team members to have marked appreciation for the most recent version, otherwise the decision is not allowed to become effective). They don’t have any meaning besides that. Maybe we should simply remove the quorum and replace it with “only a team member can post the sucess notice”? If we want it to have some minimum level of support, team members can still check if other team members have at least interacted with the decision at some point in the process (e.g. appreciated some version, or made a wiki edit).

@alignwaivers argued against removing the quorum in the above discussion – is there a good reason for it that isn’t fixed by the only-team-members-can-post-success-notice approach?

1 Appreciation
#40

I.e. you ask someone else to fix it, or you want some more exchange to happen first. Given this point of view, does it even make sense to have separate phases for the wiki and the consent decision? After all, editing because of an objection/concern someone else raised is not much different from editing because you have an objection/concern yourself (that you don’t want to raise/discuss first, because it would be a waste of time).

What I mean is: We could simply declare success after X days, once the team has been pinged already. Maybe only edits and objections should be counted as activity. (If we use 7 days here, this is very similar to what we do right now, only that we wouldn’t copy/paste the proposal to new posts all the time.
I think less than 7 would be thinkable, given that we’ve already had some editing/discussion before we pinged the team. Maybe “ping the team, wait until there’s 4 days of inactivity, but at least 7 days after the ping”, sth like that.) We should also have a way to mark unresolved objections, e.g. by simply adding them to the bottom of the proposal like a TODO-list.

1 Appreciation
#41

Just throwing a thought here, for future team growth. Do we want to change 2 people to 20%?

1 Appreciation
#42

I’m now finally getting into the details more. It’s great that we have the starting points. I think the whole thing can be improved by editing and restructuring. As I’m doing that work, I’m coming up with several new concerns:

  • We don’t have the driver-statement process explicit but that should be there as in https://patterns.sociocracy30.org/navigate-via-tension.html
  • Driver consent is basically similar but less celebratory than proposal consent?
  • The team-reference is kind of a stand-in for relevant-roles/domains. So, team makes sense for items affecting the whole team. But the main issue is engaging whatever roles apply (depending on the particular case).
  • I’m adding an initial section about identifying tensions (and adapting that with some Conscious Leadership ideas)

As of this post, I haven’t gotten to reviewing the concern and objection processes.

I hope soon to share an overhauled proposed update. It’s a lot all at once, but I can’t really express it until I make all the pieces fit together.

WIP: Proposed Consent-decision process v2
How to proceed with the process for consent decisions
WIP: Proposed Consent-decision process v2
#43

I have really reviewed and overhauled the whole document now. Way too many changes to be just a simple update, this is essentially a v2. Difficult to summarize even, but:

  • incorporated the S3 tension, driver, proposal ideas as distinct
  • changed wordings to be more concise or just improved language
  • changed orders of sections in the document
  • somewhat minor changes to actual workflow details
  • noted some TODOs (didn’t keep the TODO summary at the bottom though)

The overall concepts are the same. I would like to suggest this update as the starting point for a v2 (I suggest dropping other drafts).

Because of the level of rewrite, I’m going to post it as a new topic.

WIP: Proposed Consent-decision process v2
#44

Thanks, this one was getting a bit hard for me to follow.

1 Appreciation
#45

In my v2 overhaul, I made the suggestion that the edit be made in the original wiki location but that a quote of the changed lines be put in a new reply that includes a consent-decision on just those changes.

Yeah, topics with 40+ replies get pretty heavy. I really think we should move on to the new one (again, link: Proposed Consent-decision process v2 ), but we should read it carefully to check if it addresses concerns.

1 Appreciation
#46

Seeing as

  1. People have agreed this thread has gotten unwieldy
  2. Conversation here has died out
  3. There is a clear successor thread for continued conversation on the topic

…I’m surprised we don’t mark this thread as “closed”. Is that something that we don’t do? It certainly helps organizationally (for me at least) so I’d quickly be able to read from the title that the conversation has moved on (and perhaps identify the latest non-closed thread) without having to read all the way to the bottom.

3 Appreciations
#47

We dropped the process for using the forum this way. See Proposal: drop burdensome forum-based consent process

I agree that this should be closed.

1 Appreciation
#48