Adopt S3 seven principles?

What do you think about adopting the S3 seven principles? Here’s the principles (source):

The Principle of Effectiveness: Devote time only to what brings you closer toward achieving your objectives.
The Principle of Consent: Raise, seek out and resolve objections to decisions and actions.
The Principle of Empiricism: Test all assumptions you rely on, through experiments and continuous revision.
The Principle of Continuous Improvement: Change incrementally to accommodate steady empirical learning.
The Principle of Equivalence: Involve people in making and evolving decisions that affect them.
The Principle of Transparency: Record all information that is valuable for the organization, and make it accessible to everyone, unless there is a reason for confidentiality.
The Principle of Accountability: Respond when something is needed, do what you agreed to do, and take ownership for the course of the organization.

I think they would sometimes provide a good basis for objections. E.g. when a proposal lacks a review date, you can argue that it’s not aligned to The Priciple of Continuous Improvement. To quote from the Adopt The Seven Principles S3 pattern: “Adopting the Seven Principles reduces the number of explicit agreements required, and guides adaptation of S3 patterns to suit the organization’s context.”

1 Like

I like the S3 principles and support our ratification.

Maybe the README at could have a clearer statement about general principles we follow. It would reference our Code of Conduct, Bylaws (still needing drafting), and Sociocracy in general along with explicit mention of Sociocratic items (like the S3 principles) that we’ve reviewed and embraced.

Proposal: In the README at the governance repo, add the following section in between the “Decision-making processes” and “Circles and roles” sections:

Principles we follow

=== Consent decision ===

Are there any objections :gift: / concerns :thinking: to the above? (Let’s take 7 days for this.)


Just editorial concerns :thinking:

I would capitalize the first two and spell out S3. I could think of other editorial ideas, but I basically think this is a positive proposal that should go ahead.

I’ve broken the rules and edited the proposal, I hope @Salt (who already consented) is OK with this as well.

1 Like

@team giving some extra time for any reaction (no pinging of team happened yet), proposal is simple in this case: Adopt S3 seven principles?


Just tossing in my gut reaction: Reading up on those principles can be problematic in some ways for new members.

  1. Stuff is all over the place
    I’m concerned about linking to external resources (S3 website). If there are principles we follow, we should be able to present them ourselves. Also our own stuff should not be distributed among wiki, forum and homepage. It is hard to relate what role which resource generally has if it its so distributed.

  2. All those documents are too deep of a rabbit hole
    I think we should try to contain ideological or otherwise guiding principles so that they don’t read like a Wikipedia article with tons of links that one “could” follow. This should either be about pinning stuff down, or to learn and point to relevant resources – both at the same time does not work well. Maybe we even need redundant versions for that? Reading up about what one needs to know about us in order to participate takes way too long. We need to clearly mark what we consider to be binding, and what we generally think is a good idea.

  3. Framing could be less direct
    I’m feeling a bit overwhelmed about the amount of stuff I have to agree to and that I promise to always or never do, like " I will participate … , I will honor…, I will respect…, ", can we not make this sound like joining a cult? I think better framing would sound like "We at Snowdrift … " instead of “I will…”.


It is weird to decide “In file X at governance repo, add the following text” – this mixes up the decision being made with the way it is documented.

Objection :gift:: In this case, what is the decision even about? Did we already follow these principles and simply document it now, or do we want to start following these principles? What does it mean for us to “follow” these principles? The proposal is empty.

Aside: It would still be good to improve the way stuff is presented at the governance repo, but that should simply convey what agreements we have. As a result, it probably doesn’t need explicit consent – a “logkeeper” role or sth would be a good fit, but we can also all “keep” it, like a wiki, falling back to merge requests if you don’t have the permission or want others to see the change first.

(Edit: Note that none of this is in reply to mray’s post.)


I agree with @mray’s objections. I think we can go ahead with collecting useful resources we generally support without making them formal principles.

So, we do not need to accept the S3 principles so strongly. It’s not like we want to agree that we will work to block any violations of those principles (nor do we want to insist that everyone to study them with that much depth specifically).

I think we can have a general informational document about how we’ve developed our governance. That could simply acknowledge S3 as one primary resource we’ve used. Anyone who cares to look into that will see the principles. And any of us can individually choose to defer/refer to the principles as we do our work.

Perhaps we want to put the S3 principles as a link (not a topic itself) somewhere in the Honor Code for Projects? But that’s not a priority.

On a side note: we haven’t had full consensus about the Honor Code for Projects, it has just been mostly there from the earliest framing of the vision for the platform. I would like to see it get a full design treatment — not so much the document itself but a vision I have for how projects report on how they are doing on the items. But that’s a post-beta someday ideal, not something for attention now.

1 Like

I still think a decision about how much we want to use the S3 principles would be useful. I support improving documentation etc on the other fronts, but that would belong in a different thread :slight_smile:

Makes sense. Can we somehow find a compromise where the following use-cases are possible?

  • Raising an objection because a proposal lacks a review date, because of the principle of Continuous Improvement (“Change incrementally to accommodate steady empirical learning.”)
  • Raising an objection because a proposal is designed to work for the next 10 years, making lots of assumptions about what the future needs are, because of the principle of Empiricism (“Test all assumptions you rely on, through experiments and continuous revision.”)

Since I don’t have good examples for the other principles, maybe what I want is not really the principles, but only these two use-cases. We could forget about the S3 principles here and make a more specific decision if this is the case. Can we find any other use-cases for ratifying the principles?

1 Like

I suspect there’s a way to reference the principles (which I do think are overall good) as a resource without officially “adopting” them. And I’d support the idea that it’s fine for any objection to mention them (or other principles, even ones we haven’t heard of or agreed on) when explaining the objection.

So, I imagine some way to make it easy for people to do example the use-cases you bring up.

What about mentioning (perhaps just in a footnote) the principles within our internal docs about proposals (or in the objections section maybe)? So, we could say something like, “the S3 principles are a good set of ideas to consider for what makes a good proposal”, or something in that direction.

Less of a high-level “we follow these” and more like a helpful tool. I’m all for selecting the best resources to have on hand whenever we need. That’s not in conflict with mray’s points about wanting to avoid the impression that reviewing all the ideas is a prerequisite to participation.

1 Like