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).
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)
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:
If it’s easy to integrate the decision into the governance docs, do that.
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
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? (Let’s take X days for this)”. If there are no objections after X days, write “Looks like we have consent! ”
People would reply with their objections/concerns in the usual manner. (Maybe they can use / 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.
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.
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.
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!
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 . For example, the amount of people who say something makes no difference. See sociocracy30.org and sociocracyforall.org for more information.
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! ” 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
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