I agree with this, but it's not just about policy.

Correct, which is why half of it is not about policy. Additionally - the stuff you mention will change with time, so it's not appropriate to list out in a document which are supposed to not constantly edit. Ocuin's examples are of things that we can build the rest of our structure about.

The current charter, and the proposed thought of your components doesn't answer these questions.

Because the majority of these questions are subjective and time-relevant. The answer to "Where are inter-staff interactions causing problems?" was different a year ago during Harmony's mess, half a year ago during the town hall, two years ago during magnus's thread, right now with recap… This is a question our charter should not answer, it's something policy should.

To be clear - you seem to be conflating "charter" with "the entirety of our policy," which is where a lot of the problem in this post is coming from. Our organizational tree is all of the policy on O5command, and the charter is merely one section of it.

An inflexible, hard to change document is exceedingly bad.

Not necessarily. It is only bad if it is an excruciatingly detailed list of rules that govern everything we do. If it's just a list of general guidelines, and the occassional rule that we can't go without, it's good and even great to have that as something difficult to change. Again - you're conflating "charter" with "our policy backbone," which is why me and ocuin say we need to discuss what "charter" even means.

It loads the page with information, creates massive, overwrought, dense walls of text, and lumps everything together in a poorly organized manner.

Same as above. It's only loaded with information if it's your idea of what the charter is. You came into this post with a preconcieved notion of what the charter should be, and are interacting with ocuin's points using that framework. This is what is resulting in a lot of the clashing.

We don't have all our policies and guides stacked into one page on the main site? […] 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…

..I'm gonna stop pointing these out since this is redundant. Bleep, the reason why this all seems like nonsense is because you replaced part of Ocuin's argument with what you assumed they were going to say. It's not. Please reread his post while considering his version of the charter's function, rather than the current one (or the one you have envisioned).

---

Moving on to the second section,

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.

Not in the first wave, absolutely not. Doing so right out the gate will limit the way we see the charter, conceptually, and limit us to the shadow of the current one.

I like this in theory, but we cannot examine the charter alone…

points at the first section. Bleep please.

This will result in disjointed, dysfunctional, policy that is not easily tied together.

…

…Yeah, this problem is still here. You're way too attached to your envisioning of what a charter should be, and are looking at the rest of the suggestions through that lens rather than going into each suggestion with an open mind. I'll stop repeating myself.

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.

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?

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. 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. In an organisation of our scale and type, these aren't *hugely* important benefits, but having them is better than not having them. It should be a functional document that we can let sit for years without changes or modifications.

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.

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

The solution to this is to start our rewrite at the point of 1) deciding on our basic structures and functions (it is my opinion that this is the perfect time to make radical changes to these should we feel them necessary) and 2) writing agreed upon definitions for and descriptions of these structures and functions. The policy that governs these is secondary to our understanding of them. I have my own answers to these questions, but I'll save them for when those specific topics come up.

This rewrite is too large to be dedicated to a small number of individuals, and too complicated to be dedicated to the whole of staff all at once. The following is my proposal for how we should structure this rewrite:

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.
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.
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).
4) The working groups will independently write their section, using the discussions mentioned above as their reference point, as well as other material they feel is pertinent.
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.

I believe this is a strong outline for the rewrite structure as it ensures voices from all areas of staff are heard, whilst avoiding the overcrowding of always having everyone able to comment on every section at every moment. Having everyone yell at once is something we've had a problem with in the past, and this ensures we won't have that. Additionally, this structure allows for a generally speedy write-up of each section, without sacrificing the ability for all members of staff to make comment on them nor the time necessary to ensure that this part of the rewrite is done appropriately. Lastly, this structure is largely non-hierarchical and is not managed by any specific individual. Where extra power is vested, it does not have influence over the text of the rewrite and as such its influence does not extend beyond the boundaries of the project. Charter rewrite is an immensely important thing with a lot of power behind it, and we need to ensure that those with extra power vested in the project do not have the ability to extend that power beyond the project.

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.

Charter rewrite has failed in the past, every time, because it's either been given to too small a group, walled off from most of staff, or formed from extant hierarchies. This rewrite structure avoids those issues by ensuring transparency throughout the process, and actively combating the extant hierarchies within staff for the duration of this project; higher ranked staff should not by default have more power during this project and this structure ensures they will not. This process needs to begin and end with all of staff, and I believe this is the best way to go about it.

• Guides/instructions for specific staff positions in case of a sudden absence of critical staff members (e.g. Conwell is stuck in a well, here's how to run deletions).
• Staff/Team structure set up so that teams don't end up with one member who is absolutely indispensable and overworked (LadyKatie does incredible work with INT relations, but needs help as discussed in staffchat).
• Serious discussion/consideration of public staffcord, or some other means of making Recap team's job easier
• A clause in the charter/equivalent text that says it should be reviewed/amended once the move from wikidot is done and we are no longer bound by this site's limitations
• For the sake of both accountability and our own ease of use, create a system of some kind that makes navigating the site charter/constitution/text or whatever painless enough that both staff and non-staff users can easily use it
• As Bleep and Cassandra mentioned, any policy history we have access to should be included in some way. Perhaps all policy texts in the new charter include a section listing the history of relevant policy prior to this rewrite?
• Create a prototype of what policy navigation might look like, both to help visualize it, but also as a means of navigating existing policy
• An exception/accommodation/something for the late releases of recaps from february through april, since this stretch of time has included: promotions (and related drama), nutfall, various policy discussions that preceded and prompted this new charter rewrite thing, and the discussions of this charter thing itself
• is recap going to have to go over all of the discussion of this charter stuff in staffcord and recap it?

I'm a JS in MAST team, and I've been helping dig though old threads to find policy which wasn't kept track of, or enacted as officially as it ought to have. And let me tell you, it is frustrating, and we cannot recover 100% of it.

As such, i am of the firm belief that we really have to think 5, 10, 15 years ahead on this, make it easy for the staff of the future to refer back to this charter we are making, and hopefully to any future policy. Bleep mentioned briefly in the MAST Discord about "ease of navigation, ease of reference, ease of reading", briefly mentioning a possible "category tree" like system used elsewhere. I 100% agree on the importance of such things, and believe this should be discussed perhaps before anything else.

Further, for the context of this charter rewriting I firmly believe we should not only record the policies we create for this charter in an easily navigable manner, but whenever possible the discussions we have that end up creating the policy should absolutely be linked in an easy to find manner from that policy. Be it in the form of commentary, discussion posts, and even linking relevant monthly recap ( though, given the current consequences of discussion/voting of policy outside of O5 spaces, I am adamant the bulk of it should happen in O5) . This very thread should absolutely be linked to in some way in the future charter.

First of all, (and we can probably do this here,) we need to agree on what the charter even is supposed to be. We all have an idea of "a document that staff will work around," but what does that actually entail? Should the charter detail concepts that we must try to follow as staffmembers, even if they're not explicitly written as rules? Should the charter include how we do policy? We currently are still using the current charter as a reference point, but if we want to do something future-proof, we can't rely on the past forever.

IMO, It should include, among other things, some core values that we should strive for as staff. I don't mean shit like "Be Truthful and Honest", that's way too pretentious even for me, but I mean like "Policy should aim to improve the life of the site users, even at cost of staffwork." Tenants like that will be able to help us decide if changes to the site are worthwhile or not since we actually have a document detailing what staffers are meant to be.

I think these are all good questions to tackle, but I don't think we should flesh out all of those questionsout the gate. A lot of stuff we decide on now may not turn out to be useful or like we thought by the point we get to that step of the rewrite. For example - we may think we want to organize everything by X method, but we slowly realize Y is better. If a future part of the rewrite process is already decided to work around X, we screw ourselves over.

Most of these questions are pretty general and helpful, for the record, but I'm referring moreso to stuff like Sub-document and Assigment Mechanism; we get to those when we get to those.

I'll just copy over what I said in the previous thread since it basically still entirely holds up:

I think that, for the most part, we should start bottom to top with only vague ideas of what the rest of the plan is. We should start each phase without a strict adherence to what the future phase should look like, because otherwise we could try to force a square peg into a round hole, since we're trying to build around this preconceived notion of what the end goal should be. We should have some plan, but nothing beyond the vaguest of directions, otherwise we'll end up with a rewrite that is kind of a mess tonally.

Step one should be talking about what we want a charter to be, while completely ignoring what it actually is. What do we want in a fundamental document detailing staffwork? What should it list? What shouldn't it list? We should wholly avoid bringing up the old charter at any point, and I am serious about this. Again - if we rely on preconceived ideas of what the charter should be, we're already starting off wrong. Let's aim for a better future than a safe present.

Step two - going over the current charter, section by section, and seeing what we want to salvage. On longer sections, we might want to split it up by sub-sections. Once we already have the mostly-free-of-preconcieved-notions version of what we want the charter to be, let's go over the actual charter to see what obvious things we may have forgotten. That way we can see what we actually want and need, without necessarily carrying over any old-fashioned ideas that we just keep around because "eh sure why not."

Step three - organize. Let's break the points we have to different sections, and possibly subsections. Now that we know what we want we should have it neatly organized.

Step four is the fun part - tackling our ideas and fleshing them out. This will take a while, possibly longer than the rest combined, but it needs to be done. How we do this is… I'm not sure honestly. We'll hit it when we hit it.

Step five - Organizing everything into one document, and editing some sections for SPaG problems and wording issues.

Bababoom bababooey, we have a new charter.

"Lucio are you insane this is so much work and will take longer than the currently alloted time"

First of all - yes, have you ever talked to me. Second - Better to burn time now than have issues in the charter we'll be eating shit over for years to come.

1) Assessment: Where is the best place for staff to start Charter Overhaul. A few important topics that must be included somewhere in the Charter rewrite process:

• Screen and identify our current starting set of policy. [Currently in process via MAST]
• Staff definition and purview list/responsibility boundaries.
• Staff Hierarchy and Level Definitions
• Pain Points: Admin (Where does the admin role create difficulty for the site/what are the difficult parts of the admin role.)
• Pain Points: General Staff (Where does general staff create difficulty for the site/what are the difficult parts of general staff roles.)
• Pain Points: Community (Where does the community create difficulty for the site/what are the difficult parts of being a community member.)

2) Breakdown: Where can the charter be broken down into smaller bites? This shouldn’t be a difficult part of the process but is very important. How should the Charter be presented, section by section, for clarity and completeness?

Steps:

• Requirements for our use, versus the requirements for the document’s structure.
• Blockers (What is going to get in the way?)
• Charter inclusion vs Sub-document - Would a segment of information work best as a direct part of the Charter, or as a connected sub-document?

3) Review: How well will this all come together, per each section? A set of guidelines for authors to consider throughout their discussions and rewriting process. Each section being broken down should be analyzed through this lens.

• Accountability? Useful Accountability?
• What possible harm can come from this section? How can it be mitigated?
• Longevity? Will the SCP Wiki Staff of 2032 be doing this exact same thing? How often should Staff be reviewing the charter for updates?
• User Friendly? Will staff actually be willing to run through these processes? Is the information presented in a manner that future staff can understand the intended use?
• Assignment Mechanism? How will this section be assigned to people? What kind of expertise or insight should be prioritized? What happens when they fail to do this work?
• How does the user base interface with this? How can they assure accountability?