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.

I love the chart!

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

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!

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

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.

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.

Agreed.

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!

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).

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.

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

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...

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

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.

@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...

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:

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.

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.

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?