Reviewing the process for consent decisions

Continuing the discussion from Process for consent decisions on the forum:

Let’s do a review! I hereby invite everyone to reflect about what works and what doesn’t, and discuss it here. After 1 week, we’ll do a consent decision about keeping the process as-is (which will take another week).


Finalizing a proposal is relevant to this: There seems to be a lack of clarity at the very end of the process – how do we make sure the documentation is updated?

1 Like

Having the overall plan in my comment at Brainstorm help on defining full working team structure in mind, there’s two obvious areas of improvement for the consent decision process:

  • Reviewing proposals should work very solidly, there shouldn’t be a single-point-of-failure for that (currently the secretary). The review of the consent decision process should actually have happened on 2020-03-23. We need a solid amount of trust in our review process, because this helps us make decisions quickly – to try stuff out – instead of wanting to arrive at the perfect agreement.
  • The process should be made lighter and speedier where this is possible. If every decision takes 2 weeks (1 wk feedback + 1 wk poll), doing a series of decisions like a) driver statement for finding a driver statement, b) driver statement, c) define roles, d) assign people, takes a lot of time. (2 months in this case, plus delays caused by objections and writing proposals. We’ve started doing this exact series over at Driver statement for better milestones and roadmap etc)

A good way to speed up the process would be to remove the feedback phase: Questions can be asked during the consent phase too, and if there’s feedback about changing something, categorizing it as objection/concern means we use our time for what is important.

What is left is whether the consent decision should take 7 days, or if we can reduce it to less, say 4 days. It would be kinda cool if a tension can be brought up at a weekly meeting, and writing a proposal + making a decision is already done by the next meeting.

However, having the decision run for 7 days implies always having a weekend within that time frame – some people find their spare time/energy mostly on weekends. Do you think people still have enough capacity on workdays to raise objections? (pinging @smichel17 in particular – see your objection to the first version of the process)


Let’s find out — if I have the capacity, I’ll take a look this afternoon :slight_smile:

I’d adjust the phrasing to “a few hours at most”, otherwise it might seem like this is expected to take a few hours, which is quite a lot for the initial step, I think.

I started composing this message and this was not clear to me. Then I got distracted, came back and re-read it and it was clear. I think it’s probably too complicated. Here’s an attempt at an update

On the review date, we will follow the same process again — this time to decide whether to keep the decision. It’s the secretary’s job to kick this off, by posting an invitation for reflection and discussion, along with the next proposed review date.

I also have a concern that so much reviewing may be hard to keep track of for the secretary and/or undue bureaucracy for everyone. The first issue can be mitigated by using the forum’s shared draft feature (for moderators only?), which allows auto-publishing a post at a future date. The second can be mitigated by choosing review dates that are far enough in the future.

I debated whether I should delete this part because I am not proposing it: It’s also a lot of burden on the secretary — alternatively, the original proposer

I think this section could be condensed and then moved to a bullet point under the initial instructions, something like “decide whether non-team members can vote” with another short sentence for clarification. But I don’t feel strongly.

I agree the process is missing a final step of capturing it somehow. I think this we should amend the decision to add a section on this, which says there are two ways to resolve this:

  1. If it’s easy to integrate the decision into the governance docs, do that.
  2. If not, open an issue on the governance repo with the step to close it of integrating the decision.

I did, but maybe only because I committed to it this morning :laughing:

1-2 weeks is a little bit long for turnaround to make a decision. I think it’s ok for now, because this is specifically governance changes we’re talking about; regular day-to-day decisions are made by whoever fills the relevant roles. An idea for later, if it turns out 1-2 weeks is too long, is that any discussion/proposal can be expedited by discussion in a meeting.

What does everyone think about replacing the polls with something simpler? Here’s why I’d like to avoid polls:

  • I find it hard to remember the exact settings, so I have too look them up every time. I can remember the rest of the process.

  • They make the impression that the results are mainly about how many people “voted” for which option (or whether someone objected etc), while in reality the focus should be on the contents of the objections. Without polls, objecting would feel more like replying than like voting.

  • They make consent decisions feel very heavy, extraordinary and important. I would like to see consent decisions used casually or for not-super-important things as well.

  • Polls cannot be edited 5 minutes after they’re created; in particular, the automatic close date cannot be changed. It would be cool if you could respond to a consent decision with “Can we please extend this to be X days in total? I have some thoughts, but don’t want to allocate time until next weekend”.

A different idea would be to simply ask “Any objections? :gift: (Let’s take X days for this)”. If there are no objections after X days, write “Looks like we have consent! :partying_face:

People would reply with their objections/concerns in the usual manner. (Maybe they can use :gift:/:thinking: to mark objections/concerns.) To express your consent, you can like, react with an emoji, reply (esp. nice if someone is elected for a role), anything goes.

1 Like

I like the idea of just X days to get objections. It would be good to use tags or otherwise a certain sort of markup to make proposals stand out (polls had an effect in that direction).

We’d want to make sure that we have a quorum in terms of how many people at least acknowledge the proposal. What should that be?

I’m otherwise fine enough with the ideas above. What does an updated process look like all spelled out?

If we’re going to assume that people have gitlab accounts, maybe we can simply ask for all consent decisions to be made about git commits in the first place? It’s already allowed by the current version of the process – maybe we should encourage it.

I’d argue to try it out for the next consent decision about the process itself – I’ve already edited the process in my local git checkout, since that’s the most natural way to interact with the document. If we like it, we can still add it to the process in a separate decision.

I will definitely remove the feedback phase (have done so in my git checkout already), since there’s a lot of duplication between giving feedback that sth should be changed (like the present discussion) and objecting. This is aleady a 2x speedup, so I don’t feel strongly about reducing the consent phase from 7 to 4 days.

However, note that with a 4-day consent phase, decisions would still take 1-2 weeks usually, since there’s objections usually. The more objections, the more time it takes – i.e. it might automatically take more time for governance changes, because we pay more attention.

The current draft can be found at this permalink, differences to the previous version can be viewed best using git log -p, but you can try your luck at this merge request. The commit messages contain rationale.

1 Like

So, I think the new draft is good enough. I guess open an old style poll for the very last time to accept the new non-poll approach?

1 Like

Proposal: See this permalink (notice the changes from the above draft), differences to the previous version can be viewed best using git log -p --word-diff --ignore-space-change (or replace log with diff 9295c4f 2f7a0c2 to view all changes at once), but you can try your luck at this merge request. The commit messages contain rationale.

The most important difference from the above draft is Explain the difference between objection/concern.

Review date: 2020-07-18, as stated by the proposal.

  • Objection (explain it in a reply)
  • Consent with Concern (explain it in a reply)
  • Consent

0 voters

I have two concerns :thinking::

  • Recently it was hard to distinguish the current proposal text from other versions flying around in the discussion. Maybe we can do sth about it?

  • We didn’t do anything about the review not happening. Maybe we should experiment with scheduled posts? Maybe add a remark that anyone who notices that a review should have happened, should trigger it? @alignwaivers any input on whether it makes sense that you should trigger it, would be very appreciated.


Sounds like we’re essentially talking about LiquidFeedback.

I’ve always kinda thought the quorum and the end date should be tied together. If 80% of people have already responded positively within the first day, perhaps it should close within a few days. If It’s been a week and so far only one person approves, the closing date gets pushed further out. This way you only spend the right amount of time per-proposal!

Anyway, not terribly important, so, carry on…

Liquidfeedback is about liquid democracy (i.e. direct democracy combined with allowing people to delegate their voting rights, and allowing people to change that delegation at any time). The consent decisions process is about consent decisions, which is entirely different :slight_smile:. For example, the amount of people who say something makes no difference. See and for more information.

1 Like

Another concern :thinking::

If there’s no objections after 7 days, and at least two team members (forum group) have consented explicitly, anyone can post something like this – this makes the decision become effective:

This isn’t clear enough about what should happen if 7 days pass without two team members consenting explicitly.

Idea for fixing this: Remove the quorum, and instead have a team member, but not the person who started the consent decision, post the “Looks like we have consent! :partying_face:” message. This would also make the decision feel more official at the same time.


Some of this might be acceptable to be on a case by case basis (perhaps by the proposing party how to proceed) - but having some sort of hard limit such as for acceptance: at least two team members must consent AND 7 days must pass.

I think a standard would be ideal - unfortunately I haven’t found a way to pin a post to the top of the topic (as far as I can see, you can only pin a topic in more global contexts)

I think it makes sense, especially for proposals, for the version with the poll to be updated when there are more minor changes, but a mechanism for integrating feedback on a rolling basis while people are voting on it…
Best immediate though I have is to just cancel the poll if there is agreement about an objection raised and make a new poll with integrated solution once found

tldr polls should indicate the most recent ‘versioning’ and VCS can be traced through looking at the polls edit history

(and discussion if you want to go that deep)

There’s two other things mods can do that I forgot to mention. I’ve applied them both to this post. Just to note though, the more we rely on mod-only functionality, the more burdensome the process becomes if we don’t make all team members mods (although that’s not unreasonable). Anyway:

  • add “staff color” (yellow here) to the background color of a post.
    • I’d prefer to reserve this to indicate that I’m speaking in some official capacity. Open to changing my mind, though.
  • add an official “staff notice” at the top of a post

Feature updates! (I just upgraded Discourse)

  • Bookmarks can have reminders now!! This should do it for us to prompt reviews!
  • I turned on the new function that lets anyone use canned-replies (although we could limit it to certain groups if needed)
    • Canned replies could be used for certain sorts of process steps in consent
1 Like


Definitely agree with that - the staff notice seems redundant but maybe we can use those to flag posts in specific staff ways

The bookmark reminders seem particularly useful - nice :slight_smile: