Sat 28 Apr 2018 4:52PM

Creation of Admin Ops Teams

RB Robert Benjamin Public Seen by 331

During the April 16th membership-onboarding call there was discussion about the need for a more formalized administration structure to help insure adequate day to day coverage of a few areas critical to platform functionality and usability. These duties have historically been covered by a small group of volunteers comprised of early/founding members. The following pre-proposal was contributed to by Matt Noyes, Matthew Cropp, and Robert Benjamin prior to presentation for group feedback.

Operations-Critical Admin Teams Resolution

In order to provide for seamless and continuous platform operations coverage while still maintaining fluidity of member volunteer engagement (especially as social.coop scales), it could be beneficial to create “Admin Ops Teams” in the three following Operations-Critical Areas: Tech, Community, and Finance. For example a Tech Team would cover all things hosting, site maintenance, and development, a Community Team anything membership based, and a Finance Team would perform budgeting duties or those usually assigned to a Treasurer.

Each Operations Team would execute work within the parameters and scope of the policies provided by their corresponding Governance Working Group. The teams would self-manage to ensure coverage and participation by a diverse group with needed skill sets or desire to learn. The team members would be given greater administration access than would be afforded general membership.


There has been a good amount of discussion around the need for some kind of remuneration for performance of Operations-Critical Admin duties. Though it may be necessary at a future date to create paid staff/contractor roles, in the meantime, a somewhat simple way to incentivize volunteer coverage would be to create a working budget that allocates monthly funds for each Operations Critical Admin area. With volunteer hours managed transparently through Open Collective, the allocation could be split (per month pro rata) between corresponding Operations Team members.

Remuneration would be for OPERATIONS CRITICAL duties (however that is defined), and not for general governance duties like Working Group participation for which there is an expectation that all members participate in some way at their own chosen level. The expectation is that while the platform is small the amounts paid to any given team member would not be substantial enough to be considered “compensation” for the work performed but could provide partial offset for the expense of committing time keeping the platform up and smoothly running. For context on a funding methodology that cold support Operations Teams approach see larger budget allocation discussion.


As power may accrue to both Governance Working group members and Operations Team members by way of their already having specialized knowledge, or through the development of specialized knowledge, it would be highly advisable to require rotation of Operations Team members, not as a strict rule, but as a general principle, and adopt a mutual education approach in which people who have the skills needed for the operations train their replacements.

Additionally, as there is a risk of inequity in the formation of the Operations Teams, proposals dedicated to driving platform diversity and equity will be forthcoming.


Matthew Cropp Sun 29 Apr 2018 3:00PM

At our Tech WG call last week, @victormatekole @mayel and I discussed this, and one thing that came up was that, from their perspective, getting from here to there is going to require focused organizational/coordinating work that neither of them have the capacity to take on, so, the #1 need identified in the meeting is to develop a (at least symbolically compensated) coordinator role to do such things as build a database of member skills, schedule regular check-in calls, etc. Their next step is to start building a document outlining the role's scope, which will then be shared with the Tech WG for additional input.

As I've ruminated on this more, my sense is that it might make sense to design a similar role for each of the three working groups with a set end-point (say, 6 months), at which point the group governance and compensation transitions to the Ops Team model that you've described.


Robert Benjamin Sun 29 Apr 2018 4:22PM

The need you described seems like it still fits within the Ops Team model. The Tech working group is setting the policy, which it sounds like the result might be the Tech Ops team to start would be comprised of a minimum of 2 Developers (@mayel @victormatekole ) and 1 tech coordinator. If more developers or coordinators are needed even from a training perspective they could be added at any time the Tech Working group deems necessary.

From a budgeting perspective there would be a set amount put into the Tech Ops team pool. For the 1st six months if the developers don't want to claim their split of the pool then it would all go to the coordinator. Either way the hours contributed by each Op team members would be tracked so real costs of running and up keeping the platform could be properly captured and budgeted for in the future.

The risk to just creating 1 "compensated" short term Coordinator position inside of each of the 3 working groups and not setting up the Ops team structure is that the volunteer pool with the necessary knowledge and inclination to cover needed operations critical areas will not increase.


Matt Noyes Wed 2 May 2018 4:22PM

I like Robert's approach of allocating funds to teams. Tracking/documenting time spent and spending seems tricky to me as a practical matter, I like the way OpenCollective does this.


Matthew Cropp Wed 2 May 2018 4:35PM

After some further thought I think I agree with Robert's take here with one caveat:

It will be tricky to figure out in advance how much we should budget to each team for the labor piece, so I'm wondering if it makes more sense to create an overall monthly labor budget for all three teams that is then divided up pro-rated by time contributions? Perhaps one month there is a big time-intensive technical issue that requires more than usual Tech WG hours, while another month there could be a moderation fracas that requires greater than usual Community WG Ops Team time?

As such, having a single labor compensation pool (say, 50% of the previous month's OC take, or a set amount per month that is adjusted quarterly) would seem to be more flexible than dividing the funds into three separate pools.


Robert Benjamin Wed 2 May 2018 4:40PM

I couldn't find a tracking tool on Open Collective? Are you referring to someone just submitting an invoice? Tacking is pretty important if we are to budget long term as well as for transparency where payments made to members is concerned. There are probably some pretty simple solution for logging hours.


Matthew Cropp Wed 2 May 2018 4:42PM

Yeah, we would likely need a separate time-tracking tool, with people invoicing OC for their pro-rata share on a monthly or quarterly basis.


Matt Noyes Wed 2 May 2018 4:43PM

I was thinking of submitting an invoice - and having a record of submissions. Maybe we need something like Taiga.io?


Mayel de Borniol Wed 2 May 2018 4:45PM

I'm also involved with FairCoop which has been using custom task manegement and time tracking tools for some time and the Open Cooperative Ecosystem team is currently working on improving the UX and turning them into agent-based microservices to make them more easy to use for different things rather than going all-in with a monolithic app.


Robert Benjamin Wed 2 May 2018 6:20PM

Yes dividing between the pools is tricky to start. In the process of creating a sample budget to see how best to do that. The starting premise is that there really won't be enough money to properly fund the pools to begin with and whatever split we start off with can be adjusted later as an imbalance in allocation becomes evident. Though there will be more detail of this in the Finance discussion an overall budget allocation might look something like this.

Total Anticipated Monthly Revenue

Anticipated Hard Costs (keeping the lights on, anticipated Storage Cost Per User)

Contingency Reserve (10% to start)

Available Operation Critical Admin Renumeration Pool
Initial Weighted % Split (60/30/10) for Tech/Community/Finance.

If you run some quick numbers you see a $4000 annual budget ($333 monthly) disappear pretty quickly. Lets say there ends up being $180/month in that Renumeration pool. That's like $108/month split between the entire tech team.

Of course these numbers get better with more members which is why achieving some attainable scale is important.


Matthew Cropp Wed 2 May 2018 6:26PM

It feels at this point/scale any attempt to ballpark a working group split would be a bit arbitrary, and could result in outcomes where rates of compensation vary wildly depending on if there's a lot or a little work to be done in a group in a particular month. So I think it makes sense to treat it as a single pool to start, and then potentially move to splitting it once we have some time under our belts to gauge a sense of how time requirements are shaking out.


Robert Benjamin Wed 2 May 2018 7:11PM

Sure. That works. There could be a central remuneration allocation in the budget to start allowing for Op team segmentation later at the discretion of Finance Working Group. All admin work would be valued the same. As long as the scope of Operations Critical work is clearly laid out it shouldn't be an issue. For tech maintenance and finance its pretty cut and dry though later on it may not make sense to value all volunteer work exactly the same when looking at things like community moderation which is less critical than say platform maintenance but still important to overall functionality. usability, and happiness of the platform.


Nathan Schneider Sun 29 Apr 2018 9:33PM

I love the chart!


Robert Benjamin Mon 30 Apr 2018 10:32PM

Hah. @mattnoyes with the direction on that one. Any thoughts on the Admin Ops Team approach?


[deactivated account] Sun 6 May 2018 5:43PM

I think this plan, of having Ops teams in these areas, makes a lot of sense. I also agree with @matthewcropp 's point about allocating a pool at first because it's too hard to tell how much each Ops group is going to need to begin with. I can't think of anything else to add at this point, but if you want feedback on something else please let me know!


emi do Mon 7 May 2018 8:15AM

Love this simple and clear articulation as well. Thank you for your work in putting this together! Love the visual.


Robert Benjamin Tue 8 May 2018 3:43PM

Seems like we have enough feedback and general support for a proposal for the creation of volunteer Admin Ops Teams. Remuneration would still need to be addressed in the ongoing budgeting discussion and Equity in another discussion that will be taking place shortly in the new Community working group.


Poll Created Tue 8 May 2018 4:40PM

Creation of Volunteer Admin Ops Teams Closed Mon 14 May 2018 3:03PM

To provide for more seamless and continuous platform operations coverage, while still maintaining fluidity of member volunteer engagement (especially as social.coop scales), it is proposed that Social.Coop create "Admin Ops Teams” in the three following Operations-Critical Areas: Tech, Community, and Finance.

For example the Tech Team would cover all things hosting, site maintenance, and development. Community Team would handle anything concerning Members and platform Users. Finance Team would perform budgeting duties and those usually assigned to a Treasurer.

Each Admin Ops Team would execute work within the parameters and scope of the policies provided by their corresponding Governance Working Group. The teams would be volunteer staffed and would self-manage to ensure coverage and participation by a diverse group with needed skill sets or desire to learn. The team members would be given greater administration access than would be afforded general membership.

To mitigate either burnout, or power accruing through the development of specialized knowledge, the rotation of Team Members (not as a strict rule, but as a general principle) is sought along with a mutual education approach in which people who have the skills needed for the operations train their replacements.

Remuneration and Equity, though part of the broader Admin Ops Teams discussion, shall be addressed in separate forthcoming proposals.


Results Option % of points Voters
Agree 80.0% 8 MC MN D LS MK ED NS JC
Abstain 10.0% 1 ST
Disagree 10.0% 1 NS
Block 0.0% 0  
Undecided 0% 12 G TB RB MB MDB ES TD NP DU CB G HJS

10 of 22 people have voted (45%)


Matt Noyes
Tue 8 May 2018 7:16PM

This is really urgent -- our chat about future hosting and sysadmin opions really brought home to me how this whole thing is sitting on a precarious foundation - as a coop we need to value work first and foremost.


Tue 8 May 2018 11:01PM

In some ways I think more of a blurry line between governance and action could be nice, however some people feeling committed to action is probably a good thing. I'm thinking Ops Team membership shouldn't block Govenance Working Group membership


Liaizon Wakest
Thu 10 May 2018 9:06PM

this is great. figuring out how to get some non male non white folks to the front too could use some proposals.


Nathan Schneider
Mon 14 May 2018 3:59AM

I admire the basic structure and gist of this proposal, but I think it's time to start including monetary compensation, first of all to ensure time-privilege isn't a prerequisite for contribution.


Sam Toland
Mon 14 May 2018 9:07AM

Support the principle of this proposal & all the practical elements that I have had a chance to get to grips with. However, I haven't had the time to adequate evaluate this, so I am abstaining (in the positive way :) ). Great work moving this forward


Nick S
Mon 14 May 2018 11:30AM

Just to be clear, concerning Nathan's point, I saw the question mainly in terms of "creating teams" (as per the thread) rather than specifically "creating volunteer teams". Perhaps the distinction should be clearer.


Darren Tue 8 May 2018 11:12PM

To slightly expand on the comment attached to my vote for creating volunteer Admin Ops teams. I think Admin Op team members should probably all be members of their respective governance working group so that they can effectively share information about what they are doing and how its progressing.


Robert Benjamin Wed 9 May 2018 12:00AM



Nick S Wed 9 May 2018 11:15PM

Bank holiday weekend means I've not been keeping up on loomio very well lately, however, here's a sketch of an idea.

  • Existing admins compile a fairly exhaustive list of all the jobs that need doing.

This may take a while to unpack if the work is currently ad-hoc, but it can be a working document. For example: monitoring backups, documentation, moderating, domain renewals, disaster recovery. Recruitment, scheduling, allocation (as per below) may also need to be recognised jobs.

  • Rate the jobs by a) frequency, and b) role.

"Frequency" indicates roughly how often a job needs to be done, and might be: daily, weekly, monthly, annually, and possibly "never/unpredictably" (disaster recovery and that sort of thing)

"Role" tries to indicate who can do the job, and may have more than one variable (tech vs non-tech, accessible to newbies or otherwise), but otherwise tries to keep to a small number of understandable roles/grades of skill.

  • Order them into your "Maslow's Hierarchy of Maintenance." (Strictly there'd be two of them, since there are two variables, but we are trying to keep it simple)

  • Recruit a roster of people, categorise them by the roles they can perform and time availability.

  • Does the pyramid balance match the roster? Typically it might be too top-heavy, i.e. inaccessible to newbies and junior technicians. If so, maybe some work can be done to make balance it out by automating or simplifying the jobs.

  • Assign people to jobs somehow. Each person/group should get a list of jobs, their frequency, some documentation, and a buddy to go to for help when then need it.

  • Review this periodically to allow for rotation and improvement of skills/processes, and to guide recruitment.

Perhaps the above process might be minimally adapted for finance and community groups. The general aim is to match the jobs to people such that responsibilities are clear and there are enough hands to do the work.

A ticket system, which can also remind people when they're due to do some job, seems a good thing to have.

Some comments:
- Remuneration doesn't yet figure into this, because it was conceived for a volunteer-run organisation.
- There may be problems to solve: like a mismatch between jobs and volunteers. But knowing this means knowing where recruitment is needed.
- Recognition might need to be considered too. How can the more lowly or brain-f*cking jobs be made more fun, social, or generally more thankful?

The inspiration for this was when I was running the website/IT for a volunteer-run charity. I was also a volunteer. I found it really hard to get any help at all, since almost everyone else who was prepared to volunteer found most of the IT too technical.

I imagined a kind of Maslow's Hierarchy of Needs for admin - I wanted move as much work down to non-technical base of the pyramid, and leave a bearable tip of techie stuff for someone like me. So, WYSIWYG content editing, automated spam account deletion, mail admin via web UI, generally automate/wrap the technical stuff whenever possible. This sort of helped... except even I struggled getting Drupal to do the things I needed, and they mostly use Facebook now I've moved on :/ Of course, I'm confident we won't have that problem!


Robert Benjamin Sat 12 May 2018 8:48PM

Sounds amazing. There was talk of an immediate need for a Tech coordinator. Maybe as soon as this passes you could do a formal proposal in the Tech Working Group to adopt something like this initially for the Tech Admin Ops team. Then join @mayel and @victormatekole (current tech admins) on the initial Teach Ops Admin team and help develop this out. Would be good to include the training "pairing" that @darren4 mentioned with a 6 month rotation horizon. You could draw the additional volunteers from the deep pool of volunteer canidates from Mayels poll. So basically the initial team would include 2 admins and 1 coordinator each with a "trainee pair" (a total of 6 people).


Darren Thu 10 May 2018 3:58AM

Sounds like a pretty good plan to me.
"How can the more lowly or brain-f*cking jobs be made more fun, social, or generally more thankful?"
Made me think of the interesting open source social food gardeners web platform project growstuff.org I was watching the early development of a few years back.
The main dev is big into making it a community project and in educating people to code.
To make things more fun/social, to share knowledge, and hopefully get better quality results, they encourage development to be done via 'pairing'- people working together in pairs (or small groups)via a live link - video, audio or text chat + screen sharing or some kind of collaborative txt editor (something a bit like etherpad or google doc) all depended on the task or participants.
I wonder if we should encourage pairing for social coop Ops Teams tasks?
Obiously doing stuff via pairing is likely to take longer, possibly much longer, than someone with the skills just bashing it out, but the benefit is that its social, thus hopefully more fun and creating stronger social bonds, also it would be skilling up coop members, making more able to take on tasks and improving social coops sustainability & resilience.
In a few different projects I've paired with people editing website/flyer texts via etherpad, sometimes its helped improve motivation to get it done, and I've always found it enjoyable.
I guess implementing something like this would require some work setting up and coordinating, and probably initially more time from the people already running things, but, particularly if the pairing is promiscuous, could quickly could lead to having more people in the coop with the necessary skills and knowledge to share the load and keep things running smoothly.


Matt Noyes Thu 10 May 2018 5:04AM

In workers collectives in Japan, they pair people to share skills -- calling it tomoiku, or mutual learning.


Nathan Schneider Sun 13 May 2018 9:12PM

My creeping concern is that starting from a volunteer basis could get in the way of ensuring we have a diverse set of leaders from the start...


Matt Noyes Sun 13 May 2018 9:15PM

I agree, I feel like it is time for social.coop to put the platform on a firm foundation, as a cooperative.


Robert Benjamin Mon 14 May 2018 12:34AM

Even more reasons to clean up the membership subscription process and set some member goals so a proper allocations based budget can be put together. Really need more people to weigh in on that discussion happening (slowly) in the Finance working group.


Matthew Cropp Mon 14 May 2018 4:29AM

@ntnsndr I think I agree that remuneration is important, and would like to see it integrated into this proposal, but am also fine with this passing if @robertbenjamin will be pushing out the remuneration proposal shortly therafter...


Robert Benjamin Mon 14 May 2018 3:20PM

Unfortunately under current budget conditions there really isn’t funding to adequately compensate contributions beyond incentive levels in any areas the platform requires to function . If you paid just 1 person $15/hr for 10 hours a work a week it would come to $7200 per year. The current total projected budget is just $4,400 per year.with an account balance of only $2,749.

In lieu of the platform growing to scale to fully fund Admin Remuneration the best way to address time privilege at the admin level is through the documentation of the admin processes, mutual training, and opening up admin access to greater number of people which would lower the time requirements from any given member.

Some ways to address diversity and time privilege at the leadership levels (which really happens at the Working Group level) is to increase the diversity of the overall membership, push for more governance engagement from all members, and to make the governance process more formalized/organized and therefore less onerous to sift through the various threads.

Governance drag is poised to become an even greater issue as as the process to create proposals is pretty loose with some being created inside working groups and some outside of them with no standardized way to share takeaways/consensus from deeper conversations with members that join the process later. A conversation for another time though. :thinking:


Nathan Schneider Mon 14 May 2018 3:51PM

Okay, thanks for addressing this concern. I'll change my vote back. But let's be sure we don't rely too much on volunteerism. And the longer we wait to prioritize diverse leadership, the harder it will be to do it.


Nathan Schneider Mon 14 May 2018 3:52PM

Oops, the proposal is over. But it looks like it has passed with healthy approval! Let's take it to the main group! Seems like something that should pass there as well.


Robert Benjamin Mon 14 May 2018 6:01PM

Haven't done a proposal to the full group yet but I assume I repost outside the working group with any needed context from the working group conversation?