Loomio
Mon 26 Feb 2018 9:08PM

Sudo Protocol for the Collective

JS Joachim Stroh Public Seen by 362

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"

xkcd:Sandwich

LJ

Laura James Tue 27 Feb 2018 8:42PM

I think Graham is highlighting a critical gap in this proposal - that the mechanism for revocation etc is important to understand, especially who controls this. Could you flesh this out?

JS

Joachim Stroh Tue 27 Feb 2018 8:53PM

I intentionally kept the revocation process simple (fallback to a more senior sudo). Does this work? We don't know until it happens. Do we need to refine this further? Sure we can, but to me this is an exception handling thing with some flexibility ("if it does not work, we have others"). As long as we keep the processes transparent and open, we should be good to go.

RV

Rui Vale Tue 27 Feb 2018 3:41PM

I think it's a good idea. What could be used to log such granting, revoking, and actions? the Social Ledger?

JS

Joachim Stroh Tue 27 Feb 2018 3:51PM

Yes, good idea and I will add a link to a logfile once we get this started so you can invoke it via a /dig command

SG

Simon Grant Tue 27 Feb 2018 9:16PM

Joachim, you come across to me as a very clever guy, technically and probably in other ways too. So what's the "but"? Some of us will understand the "sudo" analogy, and some won't. Those of us who do are tempted, with a nice feeling of familiarity, to go along with your clever suggestion. I suspect those of us who don't will be rather confused, and prefer that the proposal was put in terms that avoided all the techno (or at least Unix) language.

The issue for me personally is that I don't think that the invocation of the "sudo" analogy actually makes anything any clearer at all.

I get your motive for all of this -- as you say, to "grant ... 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". But in practice, I think that there are different kinds of decision making, as well as the different fields of action that you suggest (marketing | legal | operations | tech | practice) and to me, different kinds of decision actually deserve different kinds of decision-making practice.

One of the key things that I have slowly come to recognise is that, to work together, people need a degree of psychological safety. Part of that is understanding the decision-making processes and being able to play their part in them. The technical analogy will perhaps make some technically competent people feel safer, but not the less technically experienced.

Sudo is rather binary: either you have the power or you don't. And I think it is that hard edge that raises my concerns as well.

I'd like to write more but need to go. You would be very welcome to talk this over at a time of mutual convenience.

Best wishes!

JS

Joachim Stroh Tue 27 Feb 2018 9:33PM

Hi Simon, thanks for stopping by and glad you jumped into this discussion (head on). And yes, this is written a bit more confrontational than my usual pieces, and may stem from the various attempts we've had here at the Collective around decision making (there's a channel for that) and trusted spaces (do a /dig search some of these terms). Is it binary? Absolutely! Does it work in the UNIX world? Absolutely! Does is work in a Collective? Don't know! But.. I want to find out! We can talk more at one of the next Zoom sessions maybe?

JG

John Grant Wed 28 Feb 2018 9:26AM

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.

SG

Simon Grant Wed 28 Feb 2018 11:25AM

Thanks for the clarification John @johngrant1
How about this: instead of a general "fix" like the "sudo" proposal, how about defining more closely just which kinds of decisions merit this kind of approach, and why, along with a clearer, more bespoke proposal for dealing with just these kinds of decision?

There are two kinds of simplicity in my mind: one is the simplicity of "small parts loosely joined", which I appreciate; the other is the simple grand scheme that tries to make one size to fit all. Enough said.

JS

Joachim Stroh Wed 28 Feb 2018 2:59PM

Thanks, John, let me add this to the proposal. @asimong This is good thinking but we've spent quite a few cycles on this topic (see the chart in the Annual Report). This is more the time for action, methinks.

G

Graham Wed 28 Feb 2018 10:26AM

I'm not actually clear what the current arrangement is, if any. From what I can see, and that may well be an incomplete picture because a) I wasn't here from day one, and b) much of the information is buried deep in the labyrinthine pile of Gdocs and Mattermost sub-threads (the very intricacy of the pseudo structures that have been built create an implicit hierarchy regardless of the intent of their creators), there is a governance and decision making body. It is the board of directors of the Limited Company. There is evidence that this board may have delegated some or all of it's powers to the "Interim Management Circle". What seems clear is that neither of these bodies has taken responsibility for ensuring effective governance, and instead we appear to have what I call "a mess". It is my belief that regardless of the decision-making methodologies that may or may not be used or considered at the level of projects or sub-projects that may deem themselves to be within the wider collective, clarity on the key questions of the strategy and governance of the organisation must be delivered before any substantive progress can be made.

It was in large part in pursuit of this clarity that I did the work to create a very simple business plan, thinking that if that could be implemented, even in part, it would enable us to progress, have some agreed metrics by which that progress could be assessed and there would be some bones of a strategic approach that other parts of the organisation could be built around. And yet, it seems that as a group we are even incapable of reaching a decision on that.

I'm afraid I don't see this proposal as tackling that core issue in any meaningful way. If we had effective governance, a clear strategy, and an overview that made sense to the members and the outside world about what we were actually doing, then I can of course see a role for delegation of powers to designated individuals and teams to get on with the job in hand and - guided by an appropriate policy framework - enabled to represent the Collective to external organisations.

What I've seen is a lot - and I mean a lot - of discussion about governance and decision-making. All sorts of proposals and ideas have been put forward and debated, and in some cases there appears to be tacit support for those approaches - e.g. sociocracy. But what we haven't seen is any leadership from any of the proponents of these approaches to say "I think this is the way we should do it and I'm willing to take responsibility, with your support, to make this happen." Are we all waiting for someone else to take that step?

I'm in agreement with @joachimstroh in that the process needs to be bootstrapped. We have a board of directors and a clear set of rules that define how the cooperative, that is at the heart of this wider collective (I'm not even clear yet as to whether my membership of the Collective equates to membership of the cooperative?), should be governed. These rules have enabled thousands of successful cooperatives to operate and be governed over nearly two centuries - they work. I therefore call on the directors of the cooperative to take responsibility and provide leadership within the rules that govern them, to make firm proposals to the membership about how responsibility will be delegated, how decisions will be made, about the strategy of the organisation over at least the coming twelve months, and how programmes of activity will be managed and reviewed. These proposals should be set out here in Loomio and a time limited discussion allowed, prior to a binding vote.

Load More