Power Cards (aka Sudo Protocol) for the Collective

What this is

Sudo is a UNIX command that hands over [1] authority to a person or group ("run programs with the security privileges of another user"), similar but not the same as Power of Attorney, Lazy Consensus or Subsidiarity. The thinking here is that the Collective can give [1] sudo powers to individuals (or groups), allowing them to act in the name of/represent the Collective without asking for permission or going through any kind of decision making process. Sudos can be revoked if power is misused or misapplied. In a nutshell, the purpose is to unlock the power of the Collective, to remove critical decision making bottlenecks, to lower the overall risk in a given domain/context and to think about the consequences later (kidding).

WATCH OUR SPECIAL ZOOM SESSION ON THE SUDO COMMAND

Why we do this

The Sudo proposal has been put forward in part because the current arrangement is blocking maintenance, incremental improvements and potentially disaster recovery. This situation not only puts the Collective's infrastructure at risk but could be acting as a disincentive to those willing to contribute their time and expertise to help out. The Sudo proposal may not be the ideal solution but while alternative procedures are being debated and established, the Sudo proposal is at least fit for purpose.

How to do this

• Establish a trusted environment (agents are known, activities outline identity, and social cognition is present);
• Give [marketing | legal | operations | tech | practice & projects ] sudo power to a member or a circle of the Collective;
  • Assuming the member is part of a workgroup/circle/project/practice s/he can use all resources available to work with an external party;
  • This can range from using letterhead/collateral to signing documents/agreements as a representative of the Collective (with some role/function other than a finance/legal role concerning the entire Collective);
  • note: we do not discriminate services within each domain at this point, it's all or nothing
• If the partnership/sponsorship/exchange turned out well, the person or group maintains sudo powers, otherwise not
  
• Sudo powers can be issued by anyone who has [marketing | legal | operations | tech | practice & projects ] sudo powers, but not others
• To activate the Sudo Protocol, we make a one-time Loomio decision in the Collective

Example 1

• Member A has worked on several Operations protocols and Technology initiatives for the Collective
• Member B, who joined later, has shown a high degree of competency in certain operational or technology aspects of the Collective
• Member A gives Member B full Operational and Technology Sudo Powers, and Member B can now change the toolsets or protocols unless Member A raises a concern and revokes the sudo powers

Example 2

• Mozilla Org is posting a survey on Open Leadership
• Several members from the IMC, the Governance Working Grp and Decision Making have Sudo powers to participate in public surveys on leadership principles inside coops
• Member A notifies his sudo peers about this survey and goes ahead and submits an entry on behalf of the Collective

Definition of Terms

• ** Sudo power ** - ability to execute actions within a given context/domain
• ** Sudo peer ** - members in the same context/domain, all assuming the same power
• ** Sudo revocation ** - withdrawal of sudo powers by any member with sudo powers that are older than the person who is being revoked of sudo powers
• ** Sudo challenge ** - blocking of sudo powers by any member with sudo powers that are older than the person who is being revoked of sudo powers
• ** Sudo allocation ** - assigment of new sudo powers by any member of the same context/domain with sudo powers
• ** Sudo log** - recording action of person executing sudo powers
• ** Sudo protocol** - description of sudo actions and/or a way to pass on knowledge for person executing sudo powers
• ** Sudo branch** - allow parent to split Sudo Powers into mutually exclusive sub-domains

Future of sudo

The sudo proposal is a first step in mitigating risk in the context of our current operational and technical infrastructure components that are both safe and fit for purpose. Trust and commitment are key to the proposal but then this would apply to any important responsibility within a volunteer organisation. Looking ahead, this proposal can be expanded as to include more granular definitions, roles and responsibilities as we see fit. However, this expansion would continue to evolve from the "bottom up", i.e. changes happen at the (fractal) edges of the org. Another extension (ht Christina Bowen) is to set an "expiration date" on sudo powers (continuously refresh your powers/skills or loose them).

[1] note that we avoid traditional top-down (command and control) language in this context, such as "to delegate" or "to appoint"