S3 and Community Council: a play with drivers

In my previous blogpost on the Community Council and Sociocracy 3.0 (S3) I told you that we are studying and applying S3 to our community processes. In today’s little story I will focus on two important concepts in S3: driver and domain. And we are dying to get your feedback!

First of all, let me explain one aspect of our growing appreciation of S3 for our community:

• We do amazing things as a community when we have a timeline that is not too long and a clear objective or goal.
• The working groups are an attempt to create a sort of permanent structure because that is what we were all taught: if you want to get a group to do something, you start building a structure, an organization. But that, by definition, creates hierarchy, parent/child communication patterns and all the stuff that seems to be counterproductive when applied to our do-ocracy.
• There seems to be a contradiction is those 2 points above: we are good with clear goals and short timelines yet we try to build a frozen and permanent structure?
• S3 also builds structures, but only in service of a driver, not as a goal in itself.

A driver introduces a tangible result in a relatively short timeframe.

A domain introduces a structure that exists only in direct service to the driver and is therefore temporary by definition.

So, as we all like to be hands on, we started to define a driver and want to tell you about it.

A little definition first.

Driver:

• describes the current situation
• explains the effect of the current situation within our context
• defines what we as a community need
• explains the impact
• defines an evaluation date to check if the driver is still valid
  Further reading: https://patterns.sociocracy30.org/describe-organizational-drivers.html

We applied this theory to the community and tried to define a driver that unites rather than divides. As our community is very diverse, we potentially have quite a few drivers that some of us think are important and vital and others not so. That does not feel quite comfortable for our first play so we picked one which we think everyone can relate to.

Our suggested driver:

• Current Situation
  • The CiviCRM community currently relies on a limited number of volunteers and a tiny core team to do most of its work.
  • Although there is a basic organization of working groups, there seems to be little, or at least not enough, action or dynamic within most of those groups.
  • There are many things in the community that need attention and energy to move us forward. The one we want to focus on is on-boarding new volunteers and providing enough information to guide them, help them and keep them.
• Effect:
  • Important information is not created or updated (who is who, what are the policies, how do things get decided and done, user guide, developer guide) making it hard to find information and become a productive community member.
  • Lack of new energy drains existing volunteers and keeps us running around the same circles.
  • We scare away potential newbies because information is absent or out of date.
• Need and Impact
  • We want to (and probably need to) attract more newbies as we need the numbers and the new energy
  • We need folks with knowledge of and experience with new and sexy technology that can find a way to bring that into our project

• Based on this driver, we also started thinking about some subdrivers that derive from the driver above:
• Develop accessible and central information on who is who, policies, procedures, code of conduct.
• Develop and/or structure central “how to” information on topics like how to raise an issue, how to request functionality, how to organize an event, how to do a PR etc,
• Bring the Developer Guide up to date.
• Bring User Guide up to date.
• Bring Sys Admin Guide up to date.
• Develop proposal for onboarding/mentorships.

This is where we stand, it would be wonderful to hear your thoughts, ideas, reactions and questions!