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.
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?
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.
0 voters
I have two concerns 
:
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 
. For example, the amount of people who say something makes no difference. See sociocracy30.org and sociocracyforall.org for more information.
Another concern 
:
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
(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:
Feature updates! (I just upgraded Discourse)
Sweet!!`
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
Staff notice seems perfect for “this personal opinion does not reflect Snowdrift” disclaimers.
Staff color seems perfect for the opposite: “this is definitely our universal position on this, feel free to quote it”.
Sorry, 2 days late but I do actually have an objection here (that partially caused the lateness): It’s quite awkward to have the decision poll in a different place than the proposal text. In this case, it lead to me:
I don’t have a suggestion yet, and I need to get to work so I’m posting this without, so I don’t delay any further.
Nice! Since the objection doesn’t relate to the changes we did, but simply is part of the review, I’ll interpret the situation this way: The objection came too late, and the consent decision was made. However, you then immediately triggered a review and raised an objection. I will thus use the new process to propose a fix for your objection :
Any forum user can start a consent decision. To start one, write a forum post with these contents:
- Your proposal, or a reference to the proposal. (Use permanent links, and if it’s editable, specify the last-edited timestamp or number of edits.)
Replace the bullet point with:
=== Consent decision ===
Are there any objections 
or concerns to this? (Let’s take 7 days for this.)
I hesitated, first thinking as concern, but I think these issues should be addressed, so I suppose that makes this an objection 
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.
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?
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!
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:
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.
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.