Sociocracy: proposal phase

I posted about Sociocracy 3.0: Drivers before. Reading on and sharing thoughts as I go through more of the system:

Proposals

After good driver statements that we all agree on, we then need to make proposals and refine them. The process of even coming up with proposals can be individual or collaborative, whatever works.

Concerns and Objections

Once we have proposals to consider, we should always check with anyone relevant who might have suggestions, concerns, or objections. So, doing a round with participants checking for any feelings of tension from anyone is a good practice. Co-Create Proposals (and other links around that part of the guide).

They suggest a distinction between “objections” which really have to be addressed vs “concerns” which should be heard but don’t block progress if we can’t resolve them easily. Objections

Misc notes

Those ideas are pretty straightforward.

S3 is a Work-In-Progress

Incidentally, there’s been some notable revisions and improvements to the S3 Guide this year. It’s more readable and moving even more toward comfortable language like use of “team”. I’m as confident as ever that S3 (that’s the shorthand I’ll use from now on) is the best primary foundation for us, although all of it is adaptable however we find useful.

As I read more, I see that while it’s clear the ideas are pretty-well thought out, this is rough in some ways still. The new introductory section of the S3 Guide starts out great but then has a lot of not-so-well-structured sentences and statements that are hard to parse and sometimes erroneously duplicated. I may help contribute to improving the guide once I can process it better myself.

I’d love others to look into this more too and discuss our thoughts as we go.

2 Appreciations

A good test case:
https://gitlab.com/snowdrift/design/issues/111

@mray and @msiep particularly pinging you here

We should use these guidelines to settle on proposals so we can move forward as effectively as we can. We have consent on a good driver for this situation already. We now have a couple starts of proposals (a “status” link vs a “not quite functioning” or similar text). We’re somewhere through Proposal Forming

So, do either of you specifically want anyone else involved? Either it’s between you two or you and whoever else you feel should be invited. (None of this is technically difficult, so there’s no need to get input from the coding side).

Key point:

Proposals become agreements when they are considered good enough for now and safe enough to try until the next review.

So, keep that in mind. I like that phrasing better than “perfect is enemy of the good”.

Note also:

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.

So, we shouldn’t agree on a proposal if there are any unresolved objections. We don’t want to move ahead just because a proposal isn’t harmful. We do want to optimize it if we have objections and/or concerns that will readily help improve the proposal.

I just suggest this is a useful framing as we work to get to agreement. I hope we can put this into practice in ways that help us. I don’t want it to be a rigid formula for its own sake, of course.