User:Sunrise/Guide to community social expectations

A number of high-profile events on Wikipedia have led many editors to conclude that a large proportion of the Wikimedia Foundation’s staff members (often including community liaisons) don’t actually understand the Wikipedia community. The good-faith statements and actions of staff members interacting with the community have frequently served to worsen this issue, alienating editors and eroding trust in the WMF. This page is an attempt to provide guidance on the culture of the English Wikipedia community, focusing on the issues likely to be most important for WMF staff when acting in an official capacity. (Optimistically, it will do so in a way that isn’t too blunt, although tact and clarity are often mutually exclusive.)

The community is governed by hundreds of pages of advice and directions. Some of the most important are linked in this guide, and are highly recommended reading. Other aspects of the culture are unwritten, and there is no substitute for experience, but this guide tries to describe them as well. Some of the concepts also translate to the Wikipedia versions in other languages, although the cultures may differ; if a proposal fails on one wiki, it may still be accepted elsewhere, and vice versa.

This page is written as a series of general principles. To some degree, it describes idealizations. However, those in positions of responsibility (such as WMF staff) are often held to a higher standard than most editors.

Consensus

• With a few exceptions such as legal/BLP issues, the consensus of the community is the ultimate arbiter of decisions. An existing consensus can only be overruled by a new consensus. If a change has not achieved consensus once a discussion has concluded, the status quo is maintained (or restored if the change was implemented prematurely).
• It is expected that editors will not introduce changes that contradict prior consensus. This includes understanding and following the existing policies and guidelines, since these are reflections of consensus. While nobody is expected to know them all, everyone is expected to learn them when they are relevant and (if necessary) to accept corrections based on them. Continuing to make or argue for changes that are against consensus is likely to be viewed as disruptive.
• Consensus can change. Any change which is supported today could still be rejected in the future, and vice versa.
• The community recognises that certain technical decisions are the domain of the WMF, and in themselves are outside the scope of community consensus. Therefore, it should be understood that formal consensus discussions about major "reserved issues" (such as software features), and actions taken based on these discussions, are serious and not undertaken lightly.

Proposing major changes

• In accordance with the WP:BRD editing philosophy, any change that is not already backed by consensus can be undone by anyone else. Reverts are part of the normal editing process and should not generally be taken personally.
• Major changes (including e.g. anything that will require a substantive change to policy) are expected to be discussed beforehand. Making those changes is expected to wait on the conclusion of the discussion. Making any major changes that do not have a clear consensus in favor of them, especially if done repeatedly, is likely to be considered disruptive.
• Major changes on enwiki are proposed by request for comment (RfC), and are usually advertised at WP:CENT. The conclusion can only be determined by someone who does not have a stake in the outcome. In general, RfC conclusions are unambiguous statements of consensus, and may only be overturned by appeal at WP:AN.
• Implementation of major changes is often more effective if broken into smaller pieces, each of which will require its own discussion (typically a month-long RfC). Procedural issues can add additional time, although well-written RfC questions can help to minimize this. All deadlines are informal, so there is no expectation that a complicated issue will be resolved within a specific time.
• Proposals are presented in the context of submitting ideas to the community for evaluation, with the outcome to be determined by consensus. By the nature of the process and the nature of the community, most major proposals will fail to achieve consensus. Successful RfCs for major changes are often planned far in advance, with multiple cycles of feedback and discussion. This is also a matter of respecting the community’s time, because every proposal uses up time that could be put to use elsewhere.

Communication

• Techniques such as speaking indirectly or deflecting questions are common in the corporate world, e.g. for legal reasons. However, the unique nature of the Wikipedia community means any statement which is other than direct and straightforward is more likely to inspire mistrust than trust. Such language may be perceived as a red flag, and raise suspicion that something is being hidden. Statements such as the Board’s announcement supporting superprotect attract significant criticism for this alone.
• Anyone may join or leave a discussion at any time and expect their views to be considered. If you leave a discussion while it is still active, you can expect that your views (as expressed in that discussion) will still be taken into account. However, if you don’t participate at all, then as long as the discussion was in an appropriate venue, you “forfeit” your ability to influence any decisions that are made as a result.
• There is an expectation that communications will be responded to promptly and that promises to respond to a matter will be kept. One prominent line of reasoning is that while volunteers can usually leave discussions at any time, this does not apply to staff because Wikipedia is their paid job. Editors typically understand that some responses require time to complete, but a lack of response may be interpreted as disrespect, "stonewalling" or a belief that the concerns raised are unimportant.
• The response to an analytic or technical comment should itself be analytic or technical. Additionally, links to policies, guidelines, and essays are often used as abbreviations for complicated concepts. Others will usually expect that the linked pages will be read and understood before a reply is written, and (if relevant) that the response will take them into account.
• Everyone is expected to engage civilly even when others are not (although harsh criticism is not, in itself, incivility). This includes assuming good faith (AGF) for any editor in good standing, with limited exceptions. This means that all of an editor’s statements and actions must be interpreted in the context of assuming they honestly believe that what they’re saying is both true and in the best interests of Wikipedia. Do not ascribe motivations to editors other than the motivation to improve Wikipedia.
• At the time of writing in March 2016, WMF staff communicating with the community are in the unenviable position where many editors have concluded that the WMF’s past history has reached the point that putting AGF aside is justified. Since this is a one-way conclusion, it does not remove the requirement for AGF on the part of staff.

Reasoning

• Opinions must be supported by clear and specific reasoning. Comments without this are likely to be interpreted as worth little. Additionally, if the reasoning is rejected by the community, taking actions based on it is likely to be viewed as disruptive.
• Where relevant, avoid claims that aren’t backed up by data. This is especially important for claims of benefit to the encyclopedia. When you do cite data, expect that it will be analyzed for rigor – for instance, surveys with leading questions or missing important options (and actions based on such surveys) will not usually be accepted. The best way to avoid this issue is to involve the community ahead of time. Once the data has been collected, avoid presenting it in a way that "spins" the results, or other actions that may be interpreted as attempts to justify a predetermined conclusion.
• Responding to a direct question by using a metaphor, asking what the questioner thinks, objecting to the questioner’s tone, and so forth is likely to be interpreted as deflection. One theme has been the redirection of arguments against the general idea or implementation of a tool by requesting suggestions on how to improve that tool instead. Also, if something is undecided or if you’re unsure, it’s best to simply say so.
• Don’t omit context or leave analyses incomplete. One theme has been the comparison of a new proposal’s advantages to the status quo’s disadvantages, without also fully considering the new proposal’s disadvantages and the status quo’s advantages. This also applies to the creation of information pages about new projects. If the specific issues are unclear, editors are often willing to explain.
• Don’t use reasoning that isn’t directly relevant to the question at hand. Appeals to Wikipedia’s popularity or status are usually in this category, as well as any other general arguments that haven’t been clearly connected to the specific circumstances under discussion. Appeals to Wikipedia’s mission statements or foundational principles, without fully understanding both how they will be interpreted and how they apply to the situation in question, should also be avoided. The same applies to actions that may suggest a lack of such understanding, such as replying to technical concerns with vague reassurances.
• There are other arguments and approaches to avoid as well; for example, in addition to the points listed in other sections, most common rhetorical techniques should be avoided entirely. The points listed here are primarily based on what has been observed in the past. A more comprehensive list, although focused on content discussions, can be found at Arguments to avoid on discussion pages. In addition, the tone of communications should be reasonably professional, in keeping with the tone of the venue where the discussion is being held. For example, responding to a serious discussion with chirpy, cheery language or emoticons is likely to be seen as patronising or dismissive.

Transparency

• In the absence of compelling reasons such as BLP, all discussion about potential changes is expected to occur in public. The venue must be a place where interested editors are likely to find out (the village pump is often appropriate), or announcements must be made at such locations. Even for speculative ideas, getting feedback is strongly recommended. Anyone can choose to work in private or in an obscure location, as long as they accept that the work may be rejected once it becomes more widely known.
• If information cannot be released, there should be a clear and convincing explanation as to why, e.g. by describing the precise case-by-case consequences. In the past, in situations where this was insufficient, some editors have verified sensitive information by releasing it to one or more trusted community members (usually checkusers) who can confirm or deny their statements.

Accountability

• It should always be possible to determine (from public information) who proposed a change, who supported it and why, who opposed it and why, who carried it out, and the precise timeline of those events. If this is not feasible, at minimum the information should be easy to obtain immediately by request.
• All editors, when making changes, take personal responsibility for the decision to have made that change and any consequences it may entail. It implies a personal belief that Wikipedia is better off for the change, and that if an RfC were called then consensus would likely be found in favor of the change.
• While occasional mistakes are forgiveable, and people can change their minds, actions should reflect expressed opinions. This includes following up on promises, not misleading by omission about plans for the future, etc. Similarly, all editors take personal responsibility for the opinions expressed in their talk page comments, including following up with appropriate actions. If opinions change, it should be easy to clearly express concrete reasons.
• The level of expected accountability increases with the importance of an action. For instance, the expectations for actions requiring administrative privileges (such as deletion and undeletion of pages, editing a fully protected page, etc) are described at WP:ADMIN. Not all actions that are technically possible are always acceptable.
• While imperfections or incomplete changes are sometimes inevitable, editors should never be expected to fix something or do things on someone else’s behalf. (For instance, the Gather extension assumed that editors would be willing to accept an increased moderation workload.) This includes framing bug reports or suggestions for the improvement of a new system as things the community is expected to provide – which may also be interpreted as deflection when used as a response to objections. Since this principle is based in the project’s volunteer nature, it does not apply to expectations directed towards paid staff members.
• When mistakes or problems (with respect to policies, guidelines, community norms, etc) are pointed out by others, everyone is expected to learn about and understand the issue, and change their behavior or actions accordingly.

Misc

• The Wikipedia community is not analogous to any social media community in most of the important ways. Experienced editors are closer to volunteer programmers than to the users of a service, although even that analogy is incomplete. Likewise, the methods of communication are often closer to technical writing than to the social interactions you’ll find on most of the Internet.
• Wikipedia is decentralized. For most purposes, no central authority is recognized or accepted, and there is only "soft power" from the ability to influence consensus. Those who have codified power, such as ArbCom, are restricted by consensus in how they can use it. One significant view among editors is that the WMF exists to serve the community, and therefore may only act in the interests and at the direction of the community. (Although legally this is not the case, of course; moreover, there is a significant proportion of editors who actively oppose this view.)
• Some WMF projects have aimed or attempted to expand Wikipedia beyond its established role as a (specific kind of) free online encyclopedia. While the community could plausibly be convinced of many things, it is worthwhile to review the existing community consensus on what Wikipedia is not. For example, any change which could be interpreted as making Wikipedia more like Facebook (or similar social media) will incur significant opposition.
• Wikipedia has no firm rules, but it’s easy to misunderstand what that means. For example, see What “ignore all rules” does not mean.
• Caustic or argumentative interactions are expected. Don’t take them personally. Instead, pay attention to the content of their arguments, and (if there are others in the conversation) how many editors are listening to them relative to those who disagree.
• Don’t be afraid to engage the community, ask questions, or ask for advice. In all circumstances, the earlier you do any of those, the better.
• If there is dispute about an issue which is above your level of knowledge, you will earn respect by gracefully withdrawing from the situation in favour of somebody who has the authority and knowledge to make decisions about the issue. There is an expectation from the community that all staff should be available to engage in discussions.

Advice

• Use your volunteer account to learn, and to try new things. Since your official capacity is held to a higher standard, there will be a greater tolerance for mistakes as you become familiar with the community.
• Nobody fully understands everything about the encyclopedia, and everyone has their own specializations. Likewise, every specialty has a number of editors who understand it in great detail. For any subject you’re unfamiliar with, the best approach to new discussions is to treat them as learning experiences where experienced editors will explain the issues to you.
• Spend time editing articles and engaging others in article improvement. Experiment with finding sources, adding content to an article, and finding out what stays in. Discuss proposed changes with other editors on the talk page. Over the long term, have at least one or two articles that you edit on a regular basis.
• Spend a few days studying topic areas that are highly active and/or controversial, including dispute resolution processes and article histories. Pay attention to which editors understand policy and which don’t – this often isn’t immediately obvious, but checking what the final result is can be a good rule of thumb. However, civility is not a good indication in this regard, and neither is how vocal someone is. (Some editors will be advocates for particular points of view, some will be single-purpose accounts, some will actually be sockpuppets, etc.) The same principles can be applied elsewhere on Wikipedia.
• All this being said, most users will understand that you have a life outside Wikipedia and will not expect you to be an active volunteer contributor. What is required is to have a basic understanding of important Wikipedia processes.
• If you need to communicate with the media, keep it separate from communication with Wikipedians. However, make sure that statements are consistent with each other, and expect that editors will read both.
• The more important and/or controversial something is, the more carefully you should adhere to process. This includes planning RfCs carefully, allowing sufficient time for discussion, etc. There will always be community members willing to offer help.