Reviewing the process for consent decisions

I hesitated, first thinking as concern, but I think these issues should be addressed, so I suppose that makes this an objection :gift:

Marking which post

When the proposal is marked as a “solution” so that it shows at the top, it won’t work to mark appreciation or other reactions there. That’s marking the top post. Just want it to be more clear how people should indicate that they’ve read and consent to a proposal.

Use the #proposal tag

I also think that all consent-decision proposals should also have the containing topic marked with the #proposal tag. Team members and others could then watch that tag and also could see it when overviewing the topics. The tag should be removed when the decision is done, but I suppose we should add a tag for the complete decision.

Or actually, maybe “proposal” isn’t right? Do we want multiple tags for each stage of the decision process?

2 Appreciations

Just wanted to mention that while I’d seen this conversation at some point, and definitely thinking that it had been marked as tracking, there were no notifications and I just now caught up…

I suppose, that’s to say that there needs to be a pinging mechanism. Whether this is through the #proposal tag or the "@"team function.

Aside from that, looks like a ton of great suggestions, thanks all for working on this!

2 Appreciations

If the team sets the tag to watched, that could work. But if that’s too noisy for some people (if they aren’t engaged in a particular proposal development process…) well, I think this highlights the value of multiple tags.

How about a tag set for sociocracy-process stuff (topics could have multiple as appropriate), and within that we could have these tags:

  • driver-statement
  • proposal
  • consent-decision

Then, we require that all team members watch the consent-decision tag. This enables non-team to watch the tag also. And no need for the extra @ mention.

We could add more tags as we do more parts of the sociocracy processes.

2 Appreciations

Hmm, does this only apply if the proposal is short enough to fit in the preview at the first post? E.g. for this thread, you need to navigate to the correct post before you can read the entire proposal, so you cannot really read it and then mark appreciation for the wrong post, right? I’m slightly confused but if you insist, I don’t care.

Hmm, “too noisy” reminds me of maybe creating circles around more specific topics. So another idea would be to use sth like #team-decision, #onboarding-decision (if we create an onboarding circle) etc.

I like the other idea too though, this way we would self-select into groups that work e.g. on writing proposals for the larger group to consider etc.

Edit: However, note that formally there’s only the consent-decision stage in the current process. So I would propose to simply use the tag #team-decision. We can still add tags for other stages later on.

2 Appreciations

#taglife

great ideas @wolftune and @photm. I don’t have much of an opinion on which tags would be ideal but “@ team” could be used in conjunction with other tags so I don’t think “# team-decision” would be necessary

I was just wishing there were issue boards / todo built-in to discourse, and just discovered you can filter by whats assigned to you, but tags would be even more filterable

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

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

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.

That seems reasonable and simple enough to me

not sure what that meant, btw?

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

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

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

1 Appreciation

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

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

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.

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

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

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

1 Appreciation

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.

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.