This page in a nutshell: Discussion of challenges and possible approaches to build community capacity regarding community governance, roles, and policies
Scope
Community Research into community capacity needs identified two capacities related to community governance:
Policy creation and re-evaluation
Governance roles.
Given the close tie between governance roles and policies, the challenges and approaches to addressing these two capacities have been summarized together. However, challenges and approaches specific to only policy or only roles are summarized separately.
Scope of "Policy" capacity
The Policy creation and re-evaluation capacity includes all activities involving the definition, evaluation, and revision of new or existing community-based policies on the wiki. This includes the on-wiki spaces for policy discussion, and rules / norms for discussion and decision-making; it does not include conflict management, which is considered a separate capacity (although conflict management and resolution certainly also involve wiki policies).
Challenges and approaches to address this capacity will focus on the process-of and ability-to create and revise policies in the best interest of the editing community and the general readership. It will not focus on any particular policy, or on the substance of particular policies.
The Wikimedia Foundation asserts that whether and how well policies get created and revised as need be is one measure of community health.
Scope of "Governance roles" capacity
The Governance roles capacity focuses on the formal or informal roles community members may have, to establish or enforce community policies and wiki norms.
Challenges
Governance roles
Removal of functionary (e.g. admins, bureaucrats, checkusers) permissions: While a number of situations may prompt the need for removing permissions – inactivity, abuse, decision of an Arbitration Committee – the frequency and causes for removing permissions vary between communities. For some communities, removing permissions may be very difficult due to various reasons, e.g. lack of explicit or effective policies, time intensive processes. The absence of robust policies or processes to remove permissions impacts a community’s ability to deal with inappropriate behavior by admins when such behavior takes place, e.g. harassment; burnout-induced ill temper or newbie-biting; territoriality and authoritarianism ("founder’s syndrome").
Limited use or effectiveness of Arbitration Committees: Many language projects do not have an Arbitration Committee. While an Arbitration Committee may not be necessary or effective for all language projects, some communities that do currently have one or have experimented with one, have reported the committees have been ineffective or not sufficiently active.
Missing policy
Some projects are lacking some core project policies, for example a clear notability policy, or a clear functionary (e.g. admins, bureaucrats, checkusers) appointment policy. Some disadvantages of missing policies are:
Oversight in the absence of explicit policy, where personal judgement governs decision-making. This can create frustration among editors, discrimination-based criticism, and the perception of “clique” or cabal behavior.
Implicit rules are invisible until one violates them, e.g. rules expressed post factum based on a veteran editors' personal judgment. Given many new editors are uncomfortable risking censure, missing policies remove the ability for new editors’ to check their work or conduct against explicit, articulated policy.
Addressing missing policy can thus make editing or community relations substantially easier or less conflictual.
However, a prerequisite for addressing missing policy is recognizing the policy gap.
Unsuitable policy
Sometimes existing policies are unsuitable (or no longer suitable) for the state of the project or the community working on it. While there are several distinct types of unsuitable policies, these policies generally decreases efficiency, increases frustration and potential conflict, and in the long run may erode motivation and increases frequency of burnout.
It is sometimes difficult to identify if a given policy is unsuitable, or pinpoint that policy as the source of project-wide frustration or malaise. Even when identified, it is sometimes quite difficult to effect policy change, even when the policy's unsuitability is broadly acknowledged.
Here are four distinct ways policies may be unsuitable:
Dead-letter policy
A policy that is generally ignored; although it has not been revoked, it is effectively obsolete, inapplicable, or no longer enforced.
For example, a wiki may have policy requiring that contributors who translate articles from other languages need to personally read and verify each of the source article's references, before including the same references in the translated version of the article. However the majority of article translators to this wiki may silently fail to follow this policy.
Some of the specific disadvantages of dead-letter policy are:
When the existing policy is not being followed, a governing policy is essentially missing. And the need for a more useful policy is obscured by the existence of the dead-letter policy.
Unenforced policy or policy that is routinely violated by good-faith contributors casts a shadow on other policies. This can open the community to claims of selective enforcement.
Controversial policy
A policy that is not broadly accepted by a wide-enough majority of active contributors. This can involve active disputes but also a passive but split community with occasional flare-ups of disagreement over the substance or interpretation of a particular policy. Some specific disadvantages of controversial policy are:
Frequent conflict due to transgressions against the policy (or in response to its enforcement), which takes time away from content contribution or more useful discussions.
Difficulty integrating new contributors, including confusion due to contradictory advice or opinions on the policy or it’s enforcement
Ambiguous or Complicated policy
A policy that is too difficult to understand or follow, because it either lacks specificity, or on the other hand, is highly specialized and overly detailed or technical. Some specific disadvantages of ambiguous or arcane policy are:
Difficulty in integrating new contributors. Ambiguous policies are hard to adhere to without some “wiki instincts”; complicated policies are hard to comprehend all at once, and are often overwhelming as they are introduced as monolithic policies.
"Rules-lawyering": This is a term for certain kinds of misbehavior by a minority of contributors who spend the time to master the rules in ways most contributors would not, and who then act in ways likely to demotivate and frustrate non-"wikilawyers". Some examples are: following the letter of the rules while violating their intent, needlessly using legalistic terminology or overly formal procedures for discussion, justifying inappropriate behavior through "loopholes" or technicalities.[1]
Extensive time needed to interpret ambiguous policies or determine the precise application of complicated policies. This can sometimes lead to disagreements being resolved by exhaustion rather than by agreement.
Other types of unsuitable policies
Policy can be broadly supported, reasonably clear, and generally adhered to, and still be the cause of frustration, conflict, or waste of time in a project, because it may be unsuitable to the state of the project.
To take an extreme example, for clarity of illustration: if a very small community (with a handful of editors and fewer than 1000 articles) were to adopt the Featured Article process from the English Wikipedia, those few contributors would quickly be overwhelmed and demoralized by the high bar set by the process, and they would either give up and stop contributing, or the policy would become dead-letter.
While less extreme cases are less obvious, they still burden a project with policies that it is either not yet ready for, or has already outgrown. Such policies can hold back a project from achieving growth, improving quality, appointing functionaries, and generally achieving good governance.
Possible approaches for policy creation and review
Analysis and Evaluation
Policy survey: To begin with, a community needs to identify one or more policies that need attention. This is sometimes readily apparent and widely-acknowledged among active contributors, but if it isn't, a preliminary stage would be a survey of existing policies (as well as policies that may be missing, looking at policies in comparable projects) to assess whether each policy is clear, uncontroversial, enforced, and suitable to the project.
Comparative Policy Review: Where a missing or unsuitable policy is identified, a comparative policy review from comparable projects can surface potential solutions. This comparative review should summarize not just the substance of the policy, but ideally also perceived pros and cons of that policy in the eyes of some active editors from that community.
Policy metrics: It is possible to assess some policies with metrics and data collection. For example, statistics about deletion decisions (e.g. How many votes were cast? What was the proportion between 'keep' and 'delete'? What was the average size of the deletion discussion page?) following deletion discussions can shed light on notability policies.
Group review of sample cases: Convening a broad group of experienced contributors to review a sample of recent cases with a view to desired/ideal results/decisions, compared to what current policy would determine. For example, reviewing a sample of recently deleted/kept articles to assess how well the current notability policy is reflecting active contributors' expectations; reviewing a sample of recent Featured Article candidates to assess whether the criteria are resulting in decisions that match community expectations.
Off-wiki brainstorming: Decisions about policy should always happen on the wiki. But at times, particularly if past attempts to revise policy or reach consensus have failed, it may be beneficial to gather as many active contributors as possible for a face-to-face meeting to brainstorm and seek group agreement on one or more proposals, to then bring back to the wiki for consideration by the entire community.
Design an experiment: Experiment with potential solutions for a proposed policy creation/change, including a transition plan, measures of success, a fallback procedure, etc.
Achieving policy change: a potential process
Communities change policy in any number of ways. But aggregate experience with community conversations suggests the following steps work well:
Frame the need for change: To create or revise policy, it is essential to have a clear and concise description of the current policy gap or the way current policy is not well-suited to current project needs. It should be easy to see how proposed changes (at least potentially) address the needs.
Present data, alternatives, or a specific proposal: It's always easier to respond to concrete data, alternatives, or a detailed proposal, rather than to open-ended questions such as "what should our paid editing policy be?".
Facilitate community discussion: Let the community discuss the needs, the alternatives, the proposal. Afford enough time for different contributors to provide input (e.g. include both weekdays and weekends). Encourage input from: people who were not involved with the analysis or earlier discussion stages, editors with different interests, roles, and tenure on the projects. Ideally, provide some "nutshelling" (i.e. brief summaries) of longer contributions, to assist everyone in keeping track of what can often be a long and complex conversation.
Arrive at significant agreement for deliberate action or inaction: Discussion should eventually arrive at either significant agreement on changing (or introducing) policy, or significant agreement to not take action and prefer the “status quo”. The latter is sometimes the right decision, if no compelling alternatives have been found, or if persuasive objections have been raised to what seemed a good proposal earlier.
Document the decision: Whether or not change is agreed upon, it is important to end the process by documenting the decision arrived at (particularly when the decision is to not change policy). If policy is introduced or revised, it is important to achieve clarity, in writing, about what changes and what remains the same, about timelines and effective dates, and about any transitional or interim steps.
Sketch of a possible capacity-building project
Challenge
difficulty revising outdated notability policy
Goal
Arrive at a broadly-supported community decision on whether to change or keep the notability policy. If change is agreed upon, draft and implement a new policy.
Key steps
Articulate the problems with the existing policy
Secure broad support for a conversation about possible policy change
Conduct facilitated community conversation on policy change, assisted/informed by:
Comparative study of notability policies from comparable projects
In-person meeting (with travel funding) of active editors to attempt to draft a proposal for more community discussion
Conclude community conversation with a decision and documentation.
Timeline
6 months
Means and resources
WMF assistance in creating comparative policy study; WMF funding for travel for in-person meeting
Evaluation
Community survey before and after project, to assess usefulness of the notability policy, and level and frequency of conflicts associated with notability disputes
Measurement (by tool?) of the frequency of formal notability or deletion discussions before and after policy change (if any).
Resources
Below is a list of resources that is not comprehensive. Please add any resources you have found useful or help curate this list!
The Wikimedia Foundation is interested in assisting interested communities in considering and achieving policy change, for instance through research, external conversation facilitation, and funding for face-to-face meetings.
Sign up below if you are interested in implementing this in your local community:
