The First 50 Mistakes of a Wikipedian

Jake Orlowitz

Follow

Aug 27, 2019 · 14 min read

From the first time I edited, to the ten-thousandth, it dawned on me over several years that what made a ‘Wikipedian’ was not rigid neutrality, or knowledge of markup formatting, or proper usage of citation templates. Rather, the defining characteristic was someone who had been bold enough to make 50 mistakes. Surely, it shouldn’t require such trial and error to figure out our community, but alas, such is life. I wrote this guide in the hope that to become successful in the Wikimedia community you will require, perhaps, only 13 mistakes. Your mileage may vary, but I assure you that these common pitfalls are worth understanding, at the very least so that you’ll understand why the torches are following you. Rather than terrify, may they light your path.

Sometimes you piss off Wikimedians, but these situations are surprisingly few when you engage with intelligence, clarity, and respect. Realistically anything you do will piss off somebody. The key is to understand when this is likely to happen, how to minimize it happening needlessly, and when it’s necessary or worth doing regardless. Also, how to acknowledge mistakes when you make them.

Interestingly, avoiding these behaviors won’t help that much, because the goal is to go way beyond a lack of hostility and well into the realm of creativity, trust, and impact. Still, it’s good to know what might get in the way of your sincere efforts.

Culture

1. Assume problems arise from a community’s “culture” rather than sincere differences of opinion, experience, and perspective. It’s the easiest game in town to assume that ‘the other guy’ is doing it all wrong; a better game is to ask the other person what he/she cares about and learn to see the world from his/her perspective.
2. Ignore small communities completely because there are few active editors. While it’s unwise to try and exponentially scale small communities, it’s equally disheartening to forget they exist, because one day they might be a major force for sharing knowledge.
3. Ignore the Sister projects (particularly Commons, Wikisource, Wiktionary, and Wikidata).Wikimedia really is bigger than Wikipedia, and its communities on those projects have a lot to contribute in terms of global perspective as well as massive potential for growth.
4. Treat the ‘Global South’ like a monolith rather than 100 or so unique countries with their own culture, policies, politics, religion, mores, languages, needs, and resources. Whether you call it the developing world, or emerging communities, or global south, be clear in your mind that this is not a singular thing, and that there are as many variations between those communities, as there are similarities in their historical lack of resources and attention received.
5. Assume everyone has Western language, tools, timezone, money, freedom, or perspectives. Wikimedians will find you generous and decent if you go out of your way not to pigeonhole them all in the same square hole.
6. Think all projects work like English Wikipedia. A lot of communities have developed their own process or their own cultures — ways to communicate, to decide, to collaborate — that may be very different and even surprising (also remember that these communities don’t like to be less-considered, or considered ‘less-than’ English Wikipedia, and they really are right about not liking it. Wouldn’t you?).
7. Display a lack of understanding of Creative Commons licenses (and other free licenses), such as by uploading copyrighted photos by others to Commons without permission, or not attributing authors of freely-licensed images. Free content is kind of our thing, so not understanding the legal scaffolding that holds up this edifice is tantamount to remaining ignorant of one’s history and culture, especially so if it leads you to do things prohibited by those very licenses that protect and keep us free.
8. Not make a good effort to be aware of prior and historical discussions or experiments in which issues were raised or ideas tried. There are few people who know everything that has happened, but it’s your job to search the wikis, and to find our institutional knowledge-keepers and ask them about new ideas so you discover what historical context you’ll be digging up.
9. Assume you instantly deserve trust, credibility, deference, or respect, rather than taking time to cultivate, develop, grow, and earn it. Trust is earned and no credentials will confer it until you build up a reputation as a real, reasonable, person with something of value to contribute and a basic receptiveness to the community.
10. Ignore or overrule a community consensus (bonus points if you don’t explain why either). This is probably the most inflammatory move to make, and you need to do it very rarely and very carefully with extreme equipoise and clarity if you’re going to get out unscathed; the only suitable options are to appeal to role distinctions, allow for unheard voices, explain different audiences’ needs, and/or invoke strategic or legal imperatives and consequences.
11. Demonstrate a cavalier attitude to trying new things without forethought of potential consequences, rather than a cultivating an informed and rational optimism. Wikimedians can be wary of novelty for its own sake, so don’t expect to sway people with The Next Sliced Bread unless you want to walk them through why it’s better (plus acknowledging any problems) and what you hope to achieve with it.
12. Reject efforts of assistance from community members, even on pages you created and want to ‘protect’. It’s against the Wikimedia ethos to own any page, so with rare exceptions, the best response to a volunteer’s ‘meddling’ with your beautiful creation is to politely say thanks, actually consider whether it’s worth incorporating, and kindly explain why you might be undoing part or all of it.

Communication

1. Say you’re going to do something and then never report back about it. Wikimedians appreciate when you report back, even if it’s to say you don’t have an answer yet or won’t be able to find one.
2. Not address the key point of a concern raised (if you reply at all). Wikimedians appreciate discourse that focuses on the core issue rather than trivial or tangential aspects.
3. Forget to sign your comments on talk pages. Wikimedians appreciate this simple etiquette, and it shows you have some basic skills — just type ~~~~ and you’re set.
4. Edit someone else’s comments. Wikimedians consider their comment ownership sacrosanct, so unless a comment is harassing or in violation of policy, it should be responded to below rather than changed itself.
5. Propose an idea without preparing in advance for likely objections. Wikimedians are really smart and have a really critical eye, so it pays to do your homework and be ready to respond to, say, the top 5 concerns any proposal will raise.
6. Make sweeping generalizations without any data to back it up. There is no data to back this up, but a decade of anecdotes implore you to persuade with details, facts, analysis, and evidence, rather than expecting to be believed with mere declaration.
7. Respond to every comment rather than focusing on the ones that are substantial and constructive. Wikimedians know that there is always a low signal-to-noise ratio in discussions, and they will be duly impressed when you improve that ratio by selecting which comments are worth engaging with rather than trying to rebuff them all.
8. Not notify relevant communities of discussions relating to ideas or experiments that will affect them. It’s hard for editors to keep up with everything happening on in a single Wikimedia wiki let alone dozens of others, so it’s a great courtesy, and a wise strategy, to tell people about something they would want to know about; even done liberally — but not indiscriminately — this won’t be seen as spam: if you don’t know which communities are relevant, then ask the ones you know to tell you about other groups that may be interested.
9. Notify only English Wikipedia editors. Unless something is truly language and project-specific… if you forget that 1/300 does not equal 300/300, you will not only annoy and insult a majority of our contributors, but you will miss out on their unique and valuable voices (some Wikimedians are even happy to translate your messages).
10. Drop to the lowest level of discourse rather than modeling civil and smart dialogue. Simply put, take the high road, and if you can’t take the high road, step away from the keyboard.
11. Use corporate speak, venture capital hype, management jargon, bureaucratese, or legalese (unless it’s wiki-jargon in which case it’s ok). Wikimedians have a trained ear for ‘puffery’ and all of its variations, so if you want to say something, say it simply and crisply in plain language (note that this also allows non-native speakers to understand you at all).
12. Be dismissive without explanation or consideration. It’s ok to ignore something, but it’s worse to publicly brush off an interaction without giving any reasons, or acting like reasons don’t need to be given.
13. Use “we” to represent narrow organizational concerns in a topic about the movement as a whole. We are many things — a website, a series of projects, a community, a non-profit, a movement — when you say “We”, remember that it can exclude rather than include.
14. Engage in snark or use an immature tone, unless you know exactly what and with whom you’re dealing. It’s a rare soul who can go toe-to-toe with the wit and fierce ripostes Wikimedians are capable of; unless you fancy yourself a ninja of contentious discourse, leave this one alone.
15. Allow trolls and jerks to dominate discussion without calling them on their behavior clearly and directly. It’s not necessary to respond to every comment, but it is necessary to call out conduct that harms any chance of a productive discussion; do this simply, clearly, and directly: “That language is not acceptable”. “This issue is not relevant here”. “You’ve already been given an answer — please stop”. (Remember, too, that policing bad behavior is not any single person’s responsibility and it’s often wise to wait for others to defend you, or the health of our spaces).
16. Explain decisions in terms of a binary and absolute yes/no rather than a putting them in context of a spectrum of complex considerations in which multiple needs are prioritized, and explored with an iterative and responsive process. Wikimedians are quite capable of nuance and are much more likely to accept a choice that lays out your thinking and constraints rather than merely reducing something to a one-word statement (it takes more words at first, but saves them down the road).
17. Not apologize when there’s clearly been a mistake. Nobody likes to make mistakes, but far worse is persisting as if nothing happened, so the very best thing you can do when something went wrong is to quickly and competently declare that it happened and what you’re trying to do to fix it, while apologizing for the disruption or harm it caused.
18. Not acknowledge when there’s a problem, even if you won’t be able to fix it easily/soon/ever. Giving a frank and upfront assessment that something is wrong but simply not possible to address under current conditions is far better than festering silence.
19. Not acknowledge editors’ personal stake and investment in their projects or their expertise in their area of interest or field of work. Please don’t ever forget that many editors put hundreds or thousands of hours of their free time into this project, often bringing great knowledge from ‘real life’, and for this we should give (not deference but) consideration — and appreciation.
20. Be afraid of and resistant to admitting you’re not sure of an answer; perpetuate an indignant righteousness about your omnipotence. In a project with millions of pages, it’s accepted that nobody knows everything, which means that you earn bonus points for honesty and humility by simply saying so when you don’t know something (huge bonus points if you then actually ask the community for help!).
21. Act like you’re smarter than they are. It’s unwise to underestimate the intelligence of a Wikimedian, and a quick way to make enemies instead of knowledge-sharing friends.
22. Refer to Wikimedia as “Wikipedia”. They’re different: One is a huge constellation of projects and people, and the Other is simply the most well-known website.
23. Refer to Wikipedia as “Wiki”. Wiki is a crowdsourcing technology and not all Wikis are Wikipedia (WikiLeaks, for example, is actually neither Wikipedia nor a Wiki, but you get the idea).
24. Assume gendered language in a conversation, where gender is not already a topic. Treat all Wikimedians as equal or equally deserving of inclusion, under the true fact that you don’t know who you’re talking to and don’t want to push people away with your choice of words. (At the same time, remember that many languages don’t have language-neutral pronouns or verbs, and native speakers of such languages may often default to masculine because of mental habits rather than intended gendering of the debate).
25. Raise structural discrimination or systematic bias issues in a conversation focused on something else. There are many real problems with the world, its institutions, its culture, and its traditions — still, you have to address these carefully when the discussion is focused on another specific matter, if you want people to listen rather than react defensively.
26. Always ask others to fix problems rather than ever doing it yourself. Being a crowdsourced community means many hands make light work, but that doesn’t mean people will clean up after you constantly. Most people already have extensive to-do lists or backlogs, and don’t wish for more (especially high-priority tasks).
27. State falsehoods about topics the community members know better about, or otherwise appear incompetent about what you are supposedly expert in. If you’re going to assert something in the course of your work, it is worth the time to be well-researched and up-to-date about what you’re asserting, because you never know when the little statistics discussion you’re having on Meta is actually with a Postdoctoral Inference and Combinatorics Professor, or a whiz-kid who has read the graduate-level textbook in high school.
28. Send a mass message that has broken links or unclosed <html> tags to hundreds of pages. Pretty much everyone who uses mass message has made this costly mistake once, but you can avoid it easily by sending a test message to yourself first on your Wikipedia userpage and your Meta userpage (and, to be sure you’re in the clear, after receiving the message try creating a new test section underneath it to make sure formatting is ok).
29. Fight battles 1-on-1 alone. Wikipedia is not a battleground, we say, and yet fight-or-flight responses are a regular occurrence to frequent contentious discourse: as such it’s a natural instinct to want to defend yourself, and to engage point-for-point with those who challenge or accuse you — pause before you do this, and find your allies first.

Construction

1. Invest in complex tools that no one has expressed a need for, or without a plan to promote those tools to community members. It’s not sufficient to build a product that works, unless by ‘works’ you mean reflects the expressed needs of the target community, and by ‘build’ you include building awareness and support for its release and rollout.
2. Not maintain tools that have been built and are in use. People come to depend on tools we build and host, so if you build something you should have a plan to maintain it, and if you can no longer maintain it, you should at least notify people that it’s going down.
3. Invest in new tools or platforms without evaluating the existing community-built ones. As stewards of donor dollars and volunteer expertise, it’s always nice to see if some genius coder has thrice built the thing we’re going to devote 4 full-time employees on next quarter.
4. Run a trial and not take time to pause and evaluate the results before continuing. If a trial doesn’t have a period for reflection, evaluation, and iteration then you’ll make people feel like ‘trial’ is a codeword for ‘slippery slope of the camel’s nose in the tent’.
5. Not document ongoing processes on-wiki where they are visible. For a community built upon a transparent knowledge-management technology (a wiki), it’s pretty lame not to document what you’re working on (at least a simplified public version) in a place where editors can access it.
6. Neglect to update the community on changes in approach or processes. It’s easy to forget that local, internal discussions and shifts in course are indeed completely opaque to the rest of the movement unless you have the heart and accountability to let people know when you are moving in a different direction.
7. Treat ‘the community’ as an afterthought that can just be ‘plugged in’ to a process, rather than baking them into the full longitudinal plan. Building for a community doesn’t have to always mean a movement-wide RfC or full consultation, but it should at least involve thoughtful dialogue with and feedback from key community members throughout the course of an initiative.
8. Not follow local policies when contributing; resist or at least ignore efforts to inform you of them. Each Wikimedia project has different policies, and while you can’t be expected to know them all, keep in mind that when you enter Farsi Wikisource to leave a comment you are in a different context that you might not know, yet can still seek to understand.
9. Naively assume that corporate partners do not have a financial, commercial, or promotional interest in working with us. Wikimedia’s brand carries enormous power and its traffic phenomenal reach, so don’t automatically conclude that people are working with us solely out of the goodness of their own heart.
10. Form partnerships which benefit our partners above our own community, particularly in secret, or while disrespecting and disregarding our core values, including even the appearance of impropriety where conflicts of interest are concerned. Not everyone shares our values and our rigorous commitment to neutrality and transparency, so working with partners requires imagining how a relationship would appeal to a reasonable outside editor if the details were revealed in full.
11. Get paid to edit or employ people who do. While the terms of use permit ‘disclosed paid editing’, it’s a pretty clear line that staff shouldn’t be paid to create article content, especially by third-parties, even in their time off-the-clock. (Note that this does *not* include cultural professionals and folks who work at knowledge institutions like museums and libraries and universities, when they’re being open and non-promotional).
12. Edit actual Wikipedia articles about your organization, its projects or other topics where staff may have a perceived conflict of interest. Like any individual or organization, you need to be mindful of your own bias when touching Wikipedia articles that relate to your own history and controversies; this is often best left to the uninvolved (but feel free to comment and make suggestions on talk pages).
13. Pursue grand, hand-wavy plans to magically create advanced contributors in communities where there are few to no active editors. It is regularly tempting to try and plant a community in a part of the world where few editors or even awareness of Wikipedia exists, but this often ignores the very real challenges of infrastructure, access to information, and interaction between editors — you have to nourish and fertilize the ground first.
14. Change the interface in a way that is not backwards compatible, isn’t opt-in, or has no opt-out alternative. The website has to evolve and can’t always look like Ward Cunningham’s 1996 version, but you will face much less resistance if your new interface or tool doesn’t break all past work, and does permit an editor to choose when (or when not) to use it — any system which doesn’t do those things must be exceptionally well-designed and tested in the process of a careful and gradual community rollout.
15. Design user-friendly systems that hamper the raw flexibility and power of mediawiki. Modern design prizes usability over sheer capability, and it’s sad for Wikimedians to lose that wealth of options that mediawiki provides — so if you’re going to make something look good, try to retain as much of the original power behind the system as possible.

I hope these 50+ common errors will map out your path towards engaging in the Wikimedia community! Do you have others? Contact me at jorlowitz@gmail.com or onwiki at http://enwp.org/User:Ocaasi.

-Jake Orlowitz, Founder of the Wikipedia Library.

This document is licensed CC BY-SA 4.0. Please feel free to copy/share/modify/reuse it as you wish.