Wikipedia:Wikipedia Signpost/2017-02-06/Op-ed
How to make editing workshops useful, even if participants don't stick around
- Amir E. Aharoni (Amire80) has been a Wikimedian since 2004, writing in Wikipedia and Wikisource in Hebrew, English, Russian, and occasionally other languages. He has been a member of Wikimedia Israel since 2009 (and a board member for some time), and a MediaWiki developer and a Wikimedia Foundation staff member since 2011. Amir's special interest is making Wikimedia projects accessible to people from all backgrounds, especially when it comes to different languages and cultures.
.jpg)
In December 2016 Peter Gallert wrote an op-ed (Operation successful, patient dead) about the Wikipedia workshops he ran in Namibia. He asserted that while the workshops are fun as events, and may even produce a bunch of good edits, they are not effective tools for recruiting new people who will keep editing after the workshop ends.
I have run dozens of workshops for new editors myself since 2009, and sadly, I have to agree with Mr Gallert: Though there are pleasant exceptions, I rarely see people sticking around as editors after the workshop. Research from 2013 arrived at a similar conclusion. I know some workshop organizers who will beg to differ and say that applying certain techniques will make workshops more predictable and measurably effective; but I think everyone will agree that there is no known recipe for running a workshop that is truly efficient at creating new long-term editors.
There is, however, one way in which new editor workshops and other similar real-life events, such as edit-a-thons, are consistently highly effective: Observing new users of Wikipedia and other projects and learning about the technical and social challenges they face, challenges that are too easy for experienced editors to forget. It is very sobering to watch…
- … people trying to create an account and struggling with CAPTCHAs and other oddities.
- … people searching in Spanish in the English Wikipedia's search box.
- … people clicking on footnotes in Visual Editor to try to edit them.
- … people trying to publish an edit and trying to decipher warnings from AbuseFilter.
- … people creating a pretty OK article, seeing it deleted after a few minutes, and then trying to decipher the notices from administrators.
- … people not seeing notifications about talk page messages at all (and yes, it happened in the days of the big orange bar, too)
- … people trying to copy text by right-clicking and failing (you may be wondering why would people do it by right-clicking instead of using a keyboard shortcut, but it's just unbelievable how often I see this).
- … people having no clue what to write in edit summaries.
- … people clicking the "History" tab expecting to learn stuff about the Napoleonic Wars.
- … people staring blankly at the instructor talking four-tilde signatures and templates.
This is just the tip of the iceberg. Over the years I saw many, many more issues of this kind. Whenever relevant, I reported them as software bugs or started discussions in appropriate talk pages or mailing lists. Some of the bugs were fixed, and it's great; this is, very clearly, a thing for which workshops are useful.
But it does raise a few issues to consider and to remember.
First, it must be thoroughly remembered that it's not these people's fault, and there isn't something they were "supposed" to know. In the vast majority of those instances, they were trying to do rather sensible things, and to do them in good faith. Lack of computer expertise must also not be blamed—people who contribute to wikis are supposed to be good at the subject about which they are writing, more than they are supposed to be IT professionals. Besides, Wikipedia is different in many ways from a lot of other modern websites, and even people who are IT professionals often find it surprising. These problems are caused by mistakes in software design, by software bugs, by sysops fighting perceived vandalism too eagerly, and by other things inside the project. You organized the workshop for these people, so complaining about them is not productive. Neither is saying that learning all these features is a filter that good Wikimedians will be able to come through—this filter is artificial to say the least.
Furthermore, if not watched, such people will probably remain silent and go away. Thanks to my being there, I was able to address their problems immediately, by explaining what to do, or at least by working around them. The point is not to create a chance that they will remain good editors; most likely, as Mr Gallert says, they won't anyway. But at least they saw a human face that explained them the problem, rather than something totally robotic. And in some cases there is a chance that this problem will be fixed, so that it won't happen to other people at all.
And this brings me to the last point, which sums up all of the above: During the workshop, do make quick notes about the problems people report, and pass them on. Don't ever think that when a user complains or is confused by something, your job is done when you explain why the user is wrong. The user isn't wrong. Neither is your job done when you help the user overcome the problem on the spot. The user might complete the edit, and that is nice, but if the user is unlikely to stick around as an editor anyway, no significant impact will be made. If it confused this user, it may confuse thousands of others. Unless, that is, you report it. Reporting will create a chance that it will be fixed, and this will be an actual, undeniable positive outcome from your workshop.
How should you report it? For posting software bug reports, suggestions for changes and new features, and ideas for better design or workflow, Phabricator is usually the best place. When in doubt whether to report a bug or not to report it, do report it. For issues that are more about community, culture or local templates on your wiki, the appropriate talk pages and mailing lists are the right forum.
Should you treat your editing workshops as just user testing in disguise? No, you absolutely shouldn't. I don't. You should keep treating them as editing workshops, and it won't hurt to keep thinking of ways to make them better recruiting tools. But you should start thinking about them not just as opportunities to change people into being Wikimedians, but also as an opportunity to change your own project into one that is easier for good people to join—and this is in your hands.
Discuss this story
Excellent post, and you touch on many of the issues I have with "edit-a-thons" which typically have a 1% yield rate for converting "editors." We should also think about rebranding them so that making "editors" or even editing is not the goal. A lot can be done at these meetups relating to media literacy, becoming better readers of Wikipedia, or using it as a research tool. I think the emphasis on "editing" at meetups is too great, and it may start with ditching the "edit-a-thon" label, which we know folks in non-English language already do. -- Fuzheado | Talk 13:28, 6 February 2017 (UTC)[reply]
YES to all of this! And one more important point: Editing events can have a positive public relations effect. Some people come to them with an open mind, thinking the Wikipedia thing might be crazy or might be great, but they don't have a feel for it. If we calmly communicate that the system works, it's open, we are sensible good-hearted people, and they are free to participate again from home or to abandon the project . . . then they will bring this understanding to their future interactions. That helps determine whether they support it and use it and recommend it in the future. To be successful our platform needs to be buffered by a large class of the public who thinks it is sensible and should not be undermined and attacked. Furthermore it gives them an educated view on fake news elsewhere or errors on our site.
Therefore when managing such an event I do not aim for unrealistic vision of creating permanent editors. Instead I think we want THIS event, right now, to be clear, sensible, and convincing. We want to put a few good bytes up. It should be in a comfortable place with some refreshments if possible. If there is a presentation or a handout it should be coherent. We want them to go away thinking they were welcomed into the system and it made sense and they succeeded at contributing something they can remember and recheck later. The goal is to do something good today, not to carry around a sack of homework and do it tomorrow. When the event is done hopefully they feel good about the site and the event. If that is accomplished, that is a pretty good success. -- econterms (talk) 15:14, 6 February 2017 (UTC)[reply]
Wikimania session on reforming the edit-a-thon model?
I suggest we propose a session on reforming the edit-a-thon model - rebranding, effective ways of running meetups beyond "editing," etc. We've done some sessions in the past on how to reformat meetups, such as at Wikiconference 2015 [1] but we should make it a workshop or design thinking exercise for Wikimania. Anyone interested? @Econterms, Amire80, Ziko, Mike Peel, Wittylama, Rhododendrites, Guettarda, and Ragesoss: -- Fuzheado | Talk 16:36, 6 February 2017 (UTC)[reply]
@Fuzheado, Smallbones, Ziko, and Econterms: To get the ball rolling, I created a submission page on the Wikimania2017 site. Please bear in mind this is just to get the collaborative process in motion for those interested to participate in the session (I only pinged those who explicitly expressed interest in a session, but others are, of course, welcome). Please add/change/remove/comment. — Rhododendrites talk \\ 23:27, 16 February 2017 (UTC)[reply]
"The user isn't wrong!"
This is a mantra of every business. (No wonder customer is the prime enemy of Customer Service. :-)
Corollary 1: There is nothing wrong when a newbie wikipedian writes the whole article in plain text. By "plain" I mean non-wikified, without categories, even section headers.
"Edit-a-thons" should focus on our core content policies on how to identify and deliver encyclopedic verifiable information, rather on how to fill in {{cite book}} or {{infobox person}}. A wikipedian must start feeling fun of contributing to common knowledge. Once one becomes a "wikigraphomaniac", technical hurdles are shallow.
Corollary 2: It is not the allegedly arcane syntax of wikipedia, it is the seasoned wikipedians who shame newbies with "four tildas".
Corollary 3: Knowledge-friendliness not user-friendliness is the key to the success of wikipedia. There are no "wikipedia syntax users", there are "knowledge contributors", even if their knowledge is about pokemon.
Staszek Lem (talk) 19:41, 6 February 2017 (UTC)[reply]
Use the Visual Editor
Firstly, there is a difference in the primary goals of edit training (to create new contributors) and edit-a-thons (to create new content generally about some theme). Edit-a-thons are like "Clean up your city" weekends and "fun runs for charity"; the participants are giving a day to what they perceive as a "good cause" and not a lifetime. Edit training is where we hope to create new contributors. I've done a number of edit training sessions over the past few years and would make these observations.
The participants are in the majority female and generally middle-aged or older, which is a very different profile to what we know of existing editors. Perhaps because the edit training is held at and advertised by libraries, participants are almost always either librarians or active library users with interest in some kind of non-fiction topics, often history. So they seem like the right kind of people to attract as contributors and are a missing demographic of Wikipedia contributors.
However, they struggled with the syntax of wiki text, and the conversion rate to active editors was pretty much 0%. But for the past year or so, I have been teaching the Visual Editor and what a difference it makes. I am now seeing participants continue to edit after the training session. An edit training session I did with a group of librarians about a month ago for 1Lib1Ref went on to produce over 1000 edits with one "newbie" individually adding over 100 citations. Some of these librarians had previously done wiki text edit training and marvelled at the difference using the Visual Editor. So, edit training can create new contributors if you teach the Visual Editor.
But right now, users of the Visual Editors are treated as second class citizens. Talk pages are not enabled for the Visual Editor which is a problem for them. Documentation on just about everything is written almost entirely with wiki text examples and no advice for the Visual Editor user, so they cannot "self-help". Even the TeaHouse isn't enabled for the Visual Editor nor the Visual Editor's own Feedback page.
My experience shows that there are willing and able contributors out there if we can deliver more user-friendly tools and advice. Maybe these folk won't become administrators or maintainers of templates, but they can certainly write content with reliable citations which is the meat of an encyclopaedia. Enable the Visual Editor for IPs and enable as many pages as we possibly can for the VE user and I believe we will attract new contributors (with and without edit training). PS having taught myself the VE so I could teach it, I find I now use it for most of my content editing. Kerry (talk) 17:08, 13 February 2017 (UTC)[reply]
You couldn't be more correct
I certainly can't compare my experience to yours, by any means. But all the roadblocks you've mentioned really do exist. Here are some 'helpful' hints at what I've done while giving instruction to new editors at edit-it-thons:
Interestingly enough, those editors that become more active begin editing or creating content on topics that interest them, rather than fulfilling an assignment from someone else. If I can, I suggest that the encyclopedia can become an expansion of one of their hobbies and that many will benefit from their knowledge.
I follow with thank yous, barnstars and offers of assistance. I will remove their undercontruction template, add some categories and create the talk page. Again, your experience far outweighs mine, but I've been pleasantly surprised at some of the newer editors who have become active. Best Regards,
Great article
This is an excellent article - while I haven’t attended any editathons, I have done a lot of NPP, so I know how often people make these kinds of mistakes.
I think that there’s a real need to have a great culture of behaviour on NPP, something that hasn’t always been true. Doing NPP, I see my role as being often to “finish off” articles - to get things in place like citations, categories, WikiProject tags and a reflist, maybe to do a trim and then to clearly explain what I’ve done and why. Having worked in education, this is very instinctive to me, but I do think that not enough people have this attitude. (It’s often worth clicking over to a new user’s contribution history to see if they’re on an editathon - if so a message like “Hi, I see you’re at this editathon and I hope it’s going well. Just a few things I’ve added to your article…” can work wonders for morale.) For this reason, I really encourage admins to do NPP and remote editing of editathons - it works wonders for showing what misconceptions people have about Wikipedia and why. One sees very strange mistakes. As you say, while new contributors often write interesting content on unexpected choices of topic, far too few stick around.
As a personal comment, I think a lot of editathons are far too ambitious - they chuck people off the deep end in the hope that they’ll swim. Yes, I know we don’t have enough articles on women and ethnic minorities, but creating new articles is difficult, and often I have to face the fact that the subject isn’t notable and the article isn’t very good or even not on an appropriate subject. (In this case breaking it to the user gently is most important.) What they tend to teach - that creating articles is difficult - is all too true. At the heart of Wikipedia is citation to sources, and way too many editathon articles don’t cite a single source. I find the 1lib1ref project much more realistic in that they start with a preexisting article and focus on adding citations to improve it.
If we must have editathons that create new articles (and I think given evidence of systemic bias we must accept this as a need), I’d encourage a checklist approach, to get each article out the door with (say) three citations, a reflist, two categories and a WikiProject tag, and that a four-sentence article with these features is fine. I see way too many new articles that are thousands of irrelevant words too long where it’s clear that people haven’t spent the editathon getting used to things like formatting. Perhaps writing on a blackboard during the editathon what the structure of a Wikipedia article is (title in bold, reflist and categories at the bottom, sections headings marked with = signs, etc) would make understanding clearer. Blythwood (talk) 21:40, 21 February 2017 (UTC)[reply]