We're doing it wrong. Most major volunteer organized, informational encyclopedic wikis already have a model for sensible presentation, organization, and navigation of governing policy. I have 12 years of experience working with these systems, and they are basically perfect for what we are trying to do. It's not a single page charter. It's a multi-page, sensibly categorized and segmented policy tree. If we were a government, it would make sense to have a single page charter that it's every person's job to know every detail of. We're not. Lets set ourselves up to succeed instead of failing.
Edits begin:
The charter should set in stone everything we do not want to be changed regularly, everything we don't want to have to think about often, everything that is important for our basic functions, and for our structural organisation. That means it needs to answer the following questions:
1) What are we?
2) What do we do?
3) What is our structural organisation?
4) What are the various levels of staff?
5) What are the powers of each level of staff?
6) How are new staff added, how are old staff promoted?
7) How are staffers removed? For what reasons can they be removed?
8) How are policies made?
9) How are policies formalised?
10) Who is responsible for enacting policy?
11) How are policies edited or removed?
12) What rights do staffers have, and what rules (beyond the regular site rules), must they follow?
I agree with this, but it's not just about policy. Policy is only one angle/one proportion of staff. Governing documents need to go further than just considering about policy. It needs to consider responsibility for non-policy maintenance, who can change what, who is responsible for which aspects of policy that are enacted (I suppose that is part of what you meant, but the way it was presented seems to only focus on policy itself, when one of our biggest issues right now is staffers doing nothing but policy and not focusing on maintenance, but that's a tangent).
I'll refer back to my post on the previous thread where I outline major questions we need to answer, specifically the last four questions I asked.
7) How are staff interacting with each other? Where are inter-staff interactions causing problems? Where are inter-staff interactions excelling?
8) How does staff interact with the community? How do staff actions affect the community? Where are staff interactions causing problem for the community? Where are they causing benefits?
9) What are the current strongpoints of the extant charter? Where does it fail? Where could it be done better?
10) How do we rewrite the charter to centralize, yet break up and provide easy reference points and a sensible, and most importantly, navigable presentation for Policy, staff structure, staff accountability processes, definitions, staff resources, team hubs, etc.?
The current charter, and the proposed thought of your components doesn't answer these questions. Especially #7 and #8. We need expectations for how staff should behave and interact with the community and with each other. We have no foundational documentation on what that should be, and it's critical that we fix that. Staff should after all be held to a higher standard.
It should be our foundational document. Nothing in it should be subject to regular change or need to undergo regular review, and it should outline the groundwork for both our essential day to day functions, our broad structures, and our more rarely or hesitantly enacted fundamental policies.
I disagree here. If it's our foundational aspect of policy it should be regularly and frequently reviewed to ensure that it's working, and working in the best way to enable staff to do their job. An inflexible, hard to change document is exceedingly bad. It shouldn't be changed often, but it should often be checked on to make sure its working. Otherwise, we end up in our current situation.
The utility of having a charter is in having a single document to which we can refer for the most basic things, and which is more difficult to modify to ensure more careful consideration to any changes.
Again I strongly disagree with the notion that we need a single document here. Stacking all of this onto one page is bad. It loads the page with information, creates massive, overwrought, dense walls of text, and lumps everything together in a poorly organized manner. It doesn't work. This is evidenced by the fact that for the past 3-4 years we have either ignored or just plain forgotten that the charter should be followed. But this is a multi-pronged issue that doesn't just begin with the single page charter, but also a complete lack of followthrough by staffers to update and connect new policy to the charter in any meaningfulway. This is our opportunity to fix that.
The current charter is a mess of various ideas thrown together at the time of writing because they seemed important. It turns out a lot of them are, but it has made for a messy document that doesn't achieve what it needs to well. Contradictions are present everywhere, adjacent ideas are placed in different sections, and the structure makes future edits difficult to fit in. Most problematically for us today, it is horrendously out of date and has not been updated appropriately in line with our actual functioning in years. This has lead to a nightmarish scenario where we follow some of it, but not all of it, and where some policies must be added to it in order to be codified, but others must not, which means some of it is in date and some of it is horrendously out of date, and there's even more contradictions and nobody really knows the who what where why when or how of it. It's not good.
Strongly agree with this! You're striking at the heart of the issue here and I think Ocuin gets it, but arguing for keeping the single page document as they have confuses me. We don't have all our policies and guides stacked into one page on the main site? We actually have a somewhat functional, though not completely effective policy tree for regular users on the main site. Why are we trying to preserve this here?
I think it's because we're super ingrained in this system. A single page charter is all we know. And it can be hard to break that mentality.
The charter as it stands doesn't lay out the foundations for our organisation or our policy making. It in fact begins with describing our disciplinary processes - which is in fact an ironically funny indicator of where priorities used to lie - before describing one specific function of staff and another extremely broad one. Then it describes a very contradictory and confusing policy process, details a number of aspects of policy that affect staff, and describes our demotion process.
The problem here is that these are all secondary policies, much of which *should* be in the charter, but which should come after we have described who and what we are, what we are doing, why we are doing it, and what our basic staff structure is. The charter needs to define us as an organisation, and then also define how that organisation functions *afterwards*. We shittalk the charter a lot, but there is good stuff in there, it's just buried under a mess and organised very poorly in a document that ultimately fails to achieve what it needs to.
Within individual policy issues, this problem is replicated on a smaller scale. The charter never defines what a staff member is, nor the various positions they may occupy, and instead skips directly to discussing things like activity levels and admin fiat. The same problem exists when defining site maintenance. What maintenance is, what needs to be maintained, and why, is all skipped over in favour of going straight to describing exactly one maintenance function (deletion), and broadly saying "we make events happen".
Yes I agree with this. What should be done instead is that what we call the charter (toss that name, god I hate it even more every time I type it out) should instead become a central hub page in a policy tree, that is split into multiple sections with a table of contents. It should define, very briefly, ALL the essential and important terms/definitions for staff and staff policies. It should, in brief, give primer explanations to the following categories: Policy and Policy Formulation, Administration (this being a catchall term for staff structure, promotions, staff hierarchy and roles, disciplinary and accountability, and anti-harassment), Staff Conduct and expectations, Staff Purview and Responsibilities, team structures, and then an index of all policies. The central hub should also make it very clear up front what the expectations are for organizing and presenting policy should be.
For each of these categories the central hub will link to a second tier of pages in a policy tree, consisting of Staff Guides/Staff Lists, Detailed Policy formulation and votes, Content policies, Maintenance Policies, Detailed Administration, Detailed Staff Expectations and Behaviors, Detailed Staff Purviews and Responsibilities, and finally, all the staff team hubs.
The Third tier of policy tree pages would be linked to from the second tier pages, these would be highly specific pages outlining things like our accountability systems, detailed policy on promotions, staff structure, hierarchy and roles, disc policy, content and maintenance policies (such as wikiwalk, deletions, etc).
All of this is fairly malleable, we can tune and craft the specifics of each page based on what we feel best flows together, what is most easily categorized together, and what we feel is most important to emphasize. The ENTIRE point of this system of policy presentation is to make policy easily referenceable, categorized, navigable, and digestable, all things which are currently not true of any of our current policy.
Conceptualization of a policy tree can be very difficult if you've never worked with one. It's conceptually very similar to a category tree, or simplified visual hierarchys. I am not an expert at creating an easily digestible visualization, but I have done my best to semi-illustrate in the image below.
Blue = Everything on the central hub page.
Green = Everything in the second tier of the tree, all individual pages, most would have explanations of their purpose, and some broad overview of the policy they are covering, and then lists/links to sub-policy components.
Red= Individual policy pages.
I debated whether or not to make a mini-policy tree on a sandbox to try and help emphasize, but a better example would be to look at The Fallout Wikis Policy Tree to see how we can apply that here. You'll see exactly what I'm talking about in terms of policy segmentation if you click through any of those pages (please do! I want folks to understand where I'm coming from here with this).
But basically I think you might be able to understand the monster we're looking at by just looking at this tree (This is very rough and doesn't include the dozens of policies, guides, and other material staff resources that we use regularly. Frankly, a complete overhaul of O5 is going to be an integral part of rewriting our governing policy, because the disorganization and poor navigability is a major contributor to our current issues). VERY IMPORTANT NOTE: I am not attached to this specific level of segmentation. I'm advocating for the structural segmentation itself and us not falling back into shoving everything on one page. We can get into the nitty-gritty of discussing what goes at which tier of organization in the more narrowed conversations. For all I know this specific layout of it doesn't work, but what I do know will work is a tree itself.
1) We begin with a number of large broad discussions like this one designed to agree upon structuring and the rewrite process, followed by ones designed to answer the questions I listed above (or variations thereof). These questions should be, for all intents and purposes, the bible from which the actual writing of the charter is done. This process will be *long*, but important. These discussions don't necessarily need to reach a clear consensus, but just have a rough idea of what staff as a whole thinks of each topic.
I agree with this, but I also want to point out that I think we need to evaluate all of our current systems in the first wave of asking questions and broad discussions. We want to see what is working, what isn't, and how we can do these systems better? Looking at our extant structure and model in the wild will be instrumental.
2) These are followed up by a discussion in which staff agrees upon a set of topics the charter must cover. These topics will be things such as "Staff Structure", "Charter Purpose", "Policy Formulation" and so on, and will form the sections the charter will be broken up into.
I like this in theory, but we cannot examine the charter alone, we have to look at staff as a whole and evaluate what we need in a structured governing document. I'm advocating for a tree, but even a single page charter will need to encompass every aspect of what's important.
3) A committee formed of 3 staffers per staff level will pick from volunteers to form a working group for each section (this committee will be formed from volunteers and chosen by staff in discussion. It may also be the place to go to formally work out disputes should that be necessary). Each working group *must* have at least one member of each staff level and will ideally be 4-5 staff members in size. Staffers cannot be on more than one working group (dependent on numbers and the number of topics; overlap should be a the very least kept to an absolute bare minimum).
In theory I likes this, but in practice I don't. This will result in disjointed, dysfunctional, policy that is not easily tied together. Rewrite of our governing policy has to be a staffwide effort, with all sections screened, especially by administrators with a careful eye to make sure we are not shooting ourselves in the foot long term. That said, I generally like a no-hierarchy system for this, but I'm worried that by secluding them off, we lose the experience of administrators like me and moose who have a long career of helping write salient long term policy to offer advice on approach.
5) Once a draft is finished, it will be taken to O5 for full-staff discussion. Revisions will be made, rinse, repeat, until there are few to no objections or a clear consensus has been reached.
6) Each section will be individually voted on.
7) Once each section has been agreed by vote, the whole charter will be put up for discussion and vote. If it passes this final vote, it is considered implemented and will formally replace the current charter.
Agree with this, but again advocate for individual pages that are segmented out. And instead I would suggest that every individual second tier page is composed first, and then the central hub page.
There is the risk of this being over-complicated, which I recognise, and also taking a very long time, but I believe those are worthwhile sacrifices in the interests of levelling out the power differential within staff during this project, and ensuring all voices are heard at all points in the process. Of course, should any part of this structure be adopted, the rest is up for change as staff sees fit. It's only my suggestion.
