Super Admin Guide v2.0 -> Instance Management Handbook

This conversation has been floating around for some time but hasn’t been flagged openly enough here.

We are looking at updating the Super Admin Guide so that it encompasses not just super administration of the platform, but also many of the other areas of instance initiation and management.

Since Super Admin Guide v1 was launched we have already added sections on things like getting your Open Food Network logo designed, setting up a wordpress ‘About’ page and other content.

Currently, as part of our work to onboard new instances, and get new instances from initiated to thriving more quickly, @NickWeir, @Rachel and I have been creating new content with the intention of adding it to this guide. This will include more information about assessing whether to start an instance and what it takes to run an instance, e.g. building a viable business model, communicating the platform to your customers, useful team members to recruit etc. There are also discussions about whether this guide could include things like how instances are delivering customer support, how do we train new support staff, etc.

I propose that we rename this the Instance Management Guide to recognise its evolving purpose, and to recognise that many instances are aiming to move away from instance managers to distributed instance management.

Are people ok with this change of content, name and purpose?

Does anyone feel like they need to review proposed restructure, or are they happy for these teams to start adding the necessary content and for live changes to be made to the guide? (I’ll presume the latter unless I hear otherwise :slight_smile: ) It will likely be a bit messy and iterative initially, but I think better to just start adding content rather than try to do a big restructure and content creation and then launch.

4 Likes

All good @jen
Thank you so much for all your work on this :slight_smile: :+1:

I’m also curious on people’s thoughts on what should go in the OFN Contributor Handbook, vs in the Instance Management Guide

This is an exciting shift I think. I like your agile approach. I imagine in general the distinction will become clearer as there are more people in OFN Global not attached to an instance?

I don’t have anything to add… just wanted to express support!!!

Thank you so much @Jen :slight_smile:

The way I see it, the contributor handbook is how we work, the instance management is “on what” :slight_smile:

For example the contributor handbook can be found on github for all community contributors on the source code. It explains our pay scale etc.

While all instance manager must see the contributor guide, I’m not sure all contributors need to come across the instance manager guide…

But maybe we are over-complicating things and having one big fat guide could be enough.

I’m curious to hear what Hector things about it as he is translating the guide in Spanish. I will ping him on Slack, I’m not sure what is his username here.

So excited to see this. I concur with Rachel’s idea that as an instance manager, I need to know about and be familiar with the contributor’s guide. Because, as an instance manager, I am often contacted by interested contributors to OFN - and I need to know where to send them.

But where I get muddled - is that we also have non-source code contributors at the global level (as distinct from volunteers at the instance level) such as: volunteers to look after the global website (we wish), volunteers looking to write articles about ofn as a global project, volunteers to help with knowledge management (imagine if a keen librarian or knowledge worker came along)… So - where would we direct them? Right now we treat these people case by case. maybe thats fine - but if we really want to nurture global contributors, it would be good to have a guide to get them oriented. Woudl this be the contributor’s guide? or would we put information like: our governance model, links to governance circles tools/content, … in the instance managers guide?

I’m kind of coming down on the side of one mega guide - but just with a link to the contributor’s guide. But we should rename the contributor’s guide something like: Code contributor’s guide so we are clear.

As part of the work @GeorgiaS and I are doing on happy team process development (see Process for Growth / Thriving / Self-Actualisation team members ) we began to talk about whether it’s a good idea to create an Australian section with the Instance Management Handbook.

This would include things like how Australia manages team member onboarding, growth plans, performance reviews, annual leave, etc. (I’ve added some headings just to give a sense of the type of content https://app.gitbook.com/@ofn-user-guide/s/ofn-super-admin-guide/australian-instance-management) The benefit for us of creating it in this way is that it still functions as a handbook for our instance, that we can share with new team members etc. The benefit for global is that by having this out in the open other instances can draw on each others’ team management processes. I think it is also a benefit of showing openly and publicly our ways of working, which we say are one of the things we create.

Obviously it doesn’t read as well as if we created content in the Instance Management Handbook under headings such as ‘Ways of onboarding team members’ that then had examples from all instances, but to me it feels like a higher chance that we will keep the document live if it is used rather than a library/index to info elsewhere.

It may also lead to confusion about where content should go - e.g. does it fit under the ‘Delivering customer support’ section for everyone, or in the ‘How Australia delivers customer support’ section? (@EmilyRogers keen to hear your take on this)

I’m aware this is a very English-langauge-centric perspective. I’m aware there will still be additional documentation outside of this for instances with more sensitive info. But to me this knowledge sharing really feels worth it.

What do others think?

This makes me very aware that OFN-CAN has not been engaging and sharing content that is OFN-CAN specific as much as we should. Its not that we don’t want to - its that we just haven’t had the time — perhaps until now.

I think there are many places in the current instance management handbook where a particular instance shares their example — like Aus shares their ‘properties’ list, who is doing what zaps for what… This illustrates to existing and new instances that this content is context-specific, and gives them examples. I think is is VERY useful and helpful. It would be even more useful and helpful, if multiple instances shared examples (like we should share a configuration of tax zones… example in a context that has a sales tax versus a VAT tax type)

So I favour a handbook that has instance examples embedded within topic areas - rather than handled as a separate instance-specific section. But I know that right now your timing in Aus, is that you are doing this now.

Is it possible to have an instance specific section that basically pulls links from content that is written in the topic-specific sections of the guide?

Long term vision might be: its a topic focused guide - and even for our more human resources focused content there are topics (ie: personal development plans in OFN, employment contracting …) with instance-specific examples. And we could have a vision of at least 2 different instance examples given in each topic. Then in addition - this content is clustered in a set of instance-specific guides (perhaps separate gitbooks? ) which the instance can use in orientation and day-to-day operations… ???

So we would have both an instance management guide (pertaining to the platform/product) AND instance-specific ‘policies and procedures’ guides.

(I’m not objecting to Aus doing what works best for your right now - I’m just saying, I don’t think OFN-CAN is far behind you in needing/doing this, and does that change how we structure this now?)