Governance Model

I consolidated what we discussed so far, and from yesterdayā€™s meeting, into this that I hope to receive feedback on Thursday. If we can get this sorted, we can move on to drafting what our Circles are and decision-making and voting in the next Governance meeting.

Proposed one pager

Meet.coop, The Online Meeting Co-operative, is a meeting and conferencing platform powered by BigBlueButton, stewarded by co-operatives across the world.

We have two types of membershipsā€“Operational Members and Beneficiary Members. One may apply to one or both membership types as an organization or as an individual.

Operational Members steward all operational aspects of Meet.coop.

  • To apply, you must commit a minimum of 500 in Euros, equivalent resources, or 40 hours of voluntary labour in work areas defined by the Co-operative.
  • In turn, you may participate in the Co-operativeā€™s working Circles and are eligible to apply for waged positions defined by the Co-operative. An Operational Member may also self-elect to become a Beneficiary Member as well, without an application process or paying annual membership fees as long as they remain an active Operational member.
  • To maintain active membership, you must be contributor to at least one Circle and participate in at least 50% of our All Hands meetings.

Beneficiary Members use the Meet.coop platform for internal meetings or resell Greenlight accounts.

  • To apply, you must commit a minimum of 200 in Euros per year.
  • In turn, you will get a set of Greenlight containers as according to our defined Service Levels, which you can manage for reselling our BigBlueButton server capacity. You may also participate in the Co-operativeā€™s working Circles.
  • To maintain active membership, you must maintain good standing with annual membership fees and from your resale revenue, pay a percentage set by the Co-operative to Meet.coop to cover its operation costs, and provide best-effort oversight to your Greenlight accounts in compliance with the Co-operativeā€™s Fair Use Agreement.

All membership starts with an application to contact@meet.coop. Upon approval, in addition to the responsibilities and rights for the type of membership, the new member may also participate in the Assembly, Forum, and other member spaces. All memberships carry voting rights with voting strengths as according to membership type and level of participation.


Current membership as according to above

Currently, the following organizations and individuals meet the application criteria above based on Contributions page:

Operational Members

  • Autonomic Cooperative (40h from Luke)
  • Collective.tools (50-100ā‚¬/month for renting servers + hours from Petter)
  • Digital Life Collective (2x E5440 @ 2.83GHz (8 core) 16GiB ram 2TB machine at 198.204.235.226/29)
  • femProcomuns (40h from Wouter, David)
  • FOSSHOST.org (VPS dev.meet.coop + TURN/STUN turn.fosshost.coop)
  • Hypha (40h from Ben, Yurko, Elon)
  • Webarchitects (40h from Chris)
  • Mike Hales (individual) (ā‚¬120 + hours)

Beneficiary Members

  • Animorph Co-op (ā‚¬500)
  • Free Knowledge Institute (ā‚¬500)
  • May First Movement Technology (Ā£225)

The following organizations and individuals are unclear:

  • Agile collective
  • Koumbit (our main server is with Koumbit and SĆ©bastien has spent time on Meet.coop)
  • Melissa (individual)
  • Remix the Commons
  • Yasu (individual)

SĆ©bastien, Melissa, and Yasu are all involved, itā€™s just unclear from the Contributions page whether they intend to commit to the threshold of being an Operational Member.

2 Likes

really liking this :slight_smile:
not sure if u missed The Open Co-op or left it out for some reason?
Think we need to define what a All Hands meeting isā€¦?
Not sure about the ā‚¬ levels or where these came from / what they are based onā€¦?
I was not assuming that an individual Beneficiary member got anything other than a room to make video callsā€¦ i.e. they might just pay ā‚¬10/month as per What services can we offer from 1st July 2020? (not needing to commit to ā‚¬200 / year - this is too much it will put individuals off ) - plus they donā€™t need reseller abilitiesā€¦ etc

I am basing most data on Contributions page on wiki. Thatā€™s why The Open Co-op isnā€™t in there, we can easily clear that up. The orgs are for example, as I imagine contributors like Melissa would also qualify, just not evident based on the wiki pageā€™s info.

The All Hands is meet.coop - The Online Meeting Cooperative but we can change the cadence later.

Operations Member ā‚¬500 also from the wiki, and for Beneficiary Members I feel the barrier to entry can be low as involves a rev share. This also allows us to honour our commitment to May First.

Then they are not a member. Instead, they should register an account resold by a Beneficiary Member. Meet.coop doesnā€™t want to manage all these little accounts (@chrisā€™ point all along).

This is looking really good to me @benhylau - more heroic labour :clap: Hope youā€™re logging hours on these key contributions?

This goes a long way to resolving what above I called front office issues - service levels remain the key thing to be defined there? So yes, we then can focus in on back office (circle work organisation and priorities) and assembly protocols (all-hands weekly, discourse forum, annual confluence, etc).

When we have a one-pager in each area, we can then expect to seriously recruit membership, and have proper discussions with organisations that have already become Beneficiary members (eg MayFirst) to clarify our relationship. With these early adopters, it will be important to recruit them to our medium-to long term development purposes (an economic capability project) and not just to ad-hoc room use. They will be our prime source of outcome-oriented back office volunteer workers, and medium-term steering at circle and assembly levels.

In this draft I feel only one area needs critical focus and that is reselling. I think we should not leave any door open to profit making on the back of our precious server infrastructure and back-office labour. I feel it should be dedicated for the use of movement and coop organisations in enabling federated coworking, as part of a distinctive economic project, and not seep into the gig economy or private enterprise.

I also believe reselling should be under the meet.coop brand and meet.coop governance - so reselling would be on an ā€˜agency basisā€™, I guess, as a federated arm of the meet.coop project rather than some other kind of project. Discussion with ppl like MayFirst would be important in getting this right? They would have a very firm stance on roots community support, private profit and federation, for example.

Great groundwork ben :slightly_smiling_face:

1 Like

Yep. Cascade this down to a beneficiary member.

1 Like

Hypha members are tracking time here Time tracking with Kimai - #7 by benhylau someday I may have to import into the Meet.coop thing :slight_smile:

Yup! I agree. I think we can even encode this into the Fair Use Policy. e.g. never sell service to Amazon and fascists. Until we have this codified, I think we should trust Beneficiary Members, by approving only value-aligned membership applicants. Later, we can be more specific.

By yea, I agree one key discussion point is service levels and restrictions around reselling so it doesnā€™t become a price competition (at the moment we fix the service levels everyone must adopt, but clearly they are too restrictive) or private enterprise (how do we share the clients).

1 Like

Looking forward to cancelling my Zoom account this week, on the basis of member status now being clear. Actually, Iā€™m an organisation/beneficiary in this context (Living Economy college network) rather than an individual worker member. Waiving a complimentary account as an operational member (committed 40 hours) with a ā‚¬120 annual crowdfunding contribution to the project. (my organisational Zoom subscription).

[Edit] Were going to need some clear book keeping, straight away. The contribution accounting circle needs to kick in asap?

1 Like

On Matrix chat I asked @hng:

I wonder if this thinking around membership could work for you Governance Model - #53 by benhylau obv thereā€™s a line between ā€œcollocall businessā€ vs. ā€œmeet.coop businessā€ as you have own well developed pipeline alrdy

His response was:

Yes Iā€™ve just read it and I think this would work for us :slight_smile:

1 Like

@mikemh do you want to take a stab at drafting out the circles here before the meeting? Like names + one sentence to describe scope of responsibilities. I feel like you have some ideas on what they would be. Maybe having this in the meeting notes will help us concretize what ā€œCirclesā€ are and how together they will serve all of Meet.coop operations.

Hey @benhylau, great work for drafting this text! I think things are getting much clearer now. Although I also would like to point out some aspects that Iā€™m not confident with:

  1. ā€œbeneficiary memberā€ was proposed by @mike last Tuesday IIRC as a substitution of ā€œconsumer memberā€. @osb wasnā€™t happy with that term, so old skool, right? And I think most agreed with that, so we had the option of ā€œUser Membersā€ reflecting the USAGE. After a night sleep or two I must say the term ā€œbeneficiaryā€ can refer to many things that are now user related. Parties in a grant proposal are also considered ā€œbeneficiariesā€ and that has to do with their paid work in the contract. Rather different from ā€œusersā€ or those who benefit from a service.

  2. Now I read your proposal of what Beneficiary membership entails and I got more confused:

In my understanding, but maybe wrongly understood, those organisational members contributing work actively, be it in DevOps or in attracting and onboarding new members, should be in the same class, what we now call ā€œOperational membersā€ and previously ā€œproduction membersā€.

The User Members, or maybe Beneficiary members (but Iā€™m not convinced about that term) is for organisations and people willing to enjoy the services and maybe participate a little but donā€™t take responsibility for real work to produce whatever it takes to make this project sustainable in the long run.

Iā€™d suggest we define it like this:
User Members use the services of the Meet.coop platform

  • To apply, you must commit a minimum contribution as specified for the selected service level
  • Members have one vote per member and a voting strength as defined in the governance model
  • Members agree to the Terms of Use and in particular to the Fair Use Policy

The aspects you describe about reselling I think should go to Operational Members willing to be resellers.
How do you feel about this? I know Iā€™m a stubborn Dutch engineer :wink: But with good arguments I can adjust as well, hehe.

1 Like

I have worked on the One-Pager in the pad, adding an Intro on our sustainability model:
https://pad.femprocomuns.cat/meetcoop-model

There is still a lot to refine/reach consensus on, and especially the Reselling & Room provisioning isnā€™t described all too well, if anyone can contribute there, thatā€™d be wonderful.

1 Like

First stab, seven circles . .

  • 0 Stewards - supports the work of the meet.coop assembly (meet.thing?) and acts as proxy between full assemblies. Comprises a member from each of the other six circles.
  • 1 Economy - addresses the ways in which meet.coop services facilitate transition to a commons cooperative economy. In due course, probably a number of sector-oriented circles (see eg Open2020 ā€™Tools of collaboration - Day 1 -Sectorsā€™). Calls for strong contribution from Beneficiary members, including global North-South orientation. Modelled on pro-bono commons-transition work, in the DisCO Governance Model.
  • 2 Rooms - The job is to accumulate expertise in how our federated Beneficiary organisations really need to use BBB rooms, what tools they need to have available in the browser or on the desktop in conjunction with rooms, and what the implications are for . .
    • a) medium term server/cluster/Greenlight development,
    • b) BBB user-education, support, and
    • c) service-level/fair-use practice.
      Calls for strong contribution from Beneficiary members.
  • 3 Contribution accounting - handles matters related to payments to the coop and to individual coop members, accounting for hours, calculation of care-work credits, accumulations of credits, and conversions of credits into payments. Also, the rules under which these things are done, and the transparency with which these rules are applied. A significant part of this transparency is achieved through computational means - a family of digital contribution accounting tools.
  • 4 Front office - includes systems operations members, reception members and account admins from service-user organisations. It addresses operational matters of digital infrastructure, administration of service-level bundles and public-facing documentation/FAQs . Calls for strong contribution from Beneficiary members.
  • 5 Work organisation - organisational care work . . work redesign (eg evolving circle practices), review of organisational routines and structures (including governance), internal digital tools.
  • 6 Community - community care work . . organisational culture, cycles & rhythms, habits & traditions, onboarding and ongoing learning of circle workers, meet.coop membersā€™ handbook, wellbeing and compassionate relief of workers, rotations between circles, celebrations of peer culture and peer regard, participation of women, BIPOC (black, indigenous, people of colour), generational cohorts (young, middle, old-age) and language communities. Modelled on ā€˜personal care workā€™ in the DisCO Governance Model.

[Edit] Maybe also

  • 7 Events - Custom prices, service bundles, support for large scale events.

I would also suggest to limit reselling (of individual accounts?) to operational members.

Oh and I should also add that this all looks so much clearer now than a few weeks ago, congrats and thank you all for your work :slight_smile:

2 Likes

Thanks for these comments. As we discussed in the meeting, where everyone is onboard with @wouterā€™s revision, and along with a couple small things others mentioned, I will adjust the text and move this into a new voting thread.

1 Like

Which Circles do the following work, just so I am clear :slight_smile:

  • stewarding existing servers and writing ansibles
  • building features into the forked greenlight frontend or plan a new software project
  • meeting with different groups interested in Meet.coop (aka. sales / community relations)
  • existing tuesday ā€œgovernance callā€ kinda work

I propose this as a topic for next weekā€™s discussion.

1 Like

Consensus: Membership

I have integrated all the feedback and setup a vote. Since we have not decided on formal voting mechanisms yet, or even membership, I am just allowing everyone on this forum to vote.

If you are not familiar with this type of voting, Agree means you like the plan, Abstain means whatever yā€™all decide Iā€™m fine with, and Block means I am unhappy with it and we need to discuss more. This is consensus-based language and is not a majority-win vote, so if you are Blocking please write a message underneath as to why and how we can make you happy with it. Thanks!

1 Like

My hunches are . .

  • meeting with different groups interested in Meet.coop (aka. sales / community relations) . . ā€˜salesā€™ = part of the 4 Front office circle (stuff to do with accounts, recruitment of new accounts, explaining service levels and fair-use, etc). But ongoing relations with established user orgs who are becoming active contributors in the back office would be part of the activity of either 2 Rooms (where the focus is on roomsā€™ functionality, UI, etc) or 1 Economy (where focus is on evolving expertise of how-to do distributed organising in the real world using the capabilities of the meet.coop platform)
  • plan a new software project would be 2 Rooms if related to useability and functionality in the BBB UI (or other tools running on the usersā€™ device) eg enhanced presentation tools, or 4 Front office if related to account administration, Greenlight containers, etc.
  • I donā€™t think building features (ie hacking code) is a job of any of the circles, as outlined. I kinda see it as a function that continues to be carried out within preexisting operational sysadmin/devops networks (relationships around git repos, the Riot/IRC chat collaboration, etc) in P2P collaborations between Hypha/Webarch/etc, as organisarional members that provide day-to-day operational capability. But maybe it should be a circle? In which case, itā€™s circle 8 Code and protocols. While coding is geeky, protocols is less so. Thus, while most user members would have little to contribute to decisions about coding (as distinct from defining outomes and interactions for software development projects, as above) they would have a legitimate contribution to make regarding protocols that might determine the future trajectory of the user front end, UI/UX/devices and general operability and characteristics of the server/device infrastructure in a world of webapps, web3/Dweb, linked data, hashchains, ā€˜platformlessā€™ fully distributed P2P networks, mesh networks, phone-based networks in the global South, etc etc. This is pretty geeky and futuristic (?) but something non-geeks need to develop a strategic awareness of, and may become real if meet.coop sticks around that long (long live meet.coop).
  • likewise, stewarding existing servers and writing ansibles is something that I see living within the tech-based operations-contributing member coops, and their pre-existing collaborative networks. This is a hard line to draw, and although I think that in principle everything should be accessible to the understanding of non-tech user members, some stuff - like hacking rails, or ansibles, or whatever - should continue to be done as it has been done pre-meet.coop, in time-honoured FLOSS manner.
  • once the other circles are operating - especially 3 Contribution accounting and 4 Front office, which I think are urgent - I think that what will be left from the existing tuesday ā€œgovernance callā€ meeting will belong in 5 Work organisation. And maybe, some will be 0 Stewards. Some of the weekly ā€œall handsā€ meeting may gravitate to 0 Stewards too?

Howā€™s that sounding? Not simple. But what weā€™re trying to do isnā€™t simple. I feel the ecology of eight (or nine) circles kinda covers the ground and differentiates responsibilities and skillsets, without being too elaborate. A circle is not a specialist functional department, but rather, a zone where different interests and perspectives and skills need to be combined in coproduction, to handle some real aspect of the world of meet.coop. Eight (nine) circles = ā€˜requisite varietyā€™?

Thinking further . . Iā€™m still uncertain that circle 8 Code and protocols is required. This circle is where the multi-discipline community of meet.coop users and workers might interface with specialist work that involves git.coop, code repositories, software solutions, script-authoring, app ecosystems, protocols, cross-protocol bridges, etc. At some point down the line, tool development is certainly going to be needed by meet.coop users - for example in Greenlight to facilitate room-bundle management (which for a room-occupant is ā€˜back endā€™ not front end) or, letā€™s say, in the presentation interface within BBB (which has some real UX shortcomings). The UI could do with some tweaking too.

However, I still feel that Circle #2 Rooms is where the latter could/should be handled, and Circle #4 Front office the former. I can imagine that somewhere down the line, friendly negotiations will be needed with one or other of the BBB committers and the BBB open-source community generally (regarding the Nextcloud bridge, for example). But Iā€™d hope that this interaction can be ā€˜translatedā€™ into English in a user-facing circle in meet.coop, rather than needing to be conducted entirely in geek-speak, in the depths of git-land, where mere mortals have no idea of the difference between a ruby on some rails and a green light :wink:

meet.coop, as a service organisation supplying tools, needs to organise in a way that enables its development and operation to be use-led as distinct from code-led?

Of course code development is specialist and complicated, and it needs specialist language and threads. But members of that community already have these in place, and maybe meet.coop doesnā€™t need to add anything to that? What meet.coop needs to create is new ā€˜spacesā€™ (the circles) where new players can engage with whatā€™s new about the service, and new challenges of operations management and the strategic steering of a distributed infrastructure?

These initial proposals are now in the wiki, where they are easier to read and a bit clearer.

Hi,

Thank you so much for the amazing work that is taking place here!!

I just wanted to let you know that my collaborator and I are contemplating on repackaging BBB so it is much easier to administer and we understand exactly how it works

I wonder which circle this kind of activity belongsā€¦