The Signpost


Op-ed

How to make editing workshops useful, even if participants don't stick around

Workshop participants in Portland, Oregon learn about Wikipedia in 2013.

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…

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.

S
In this issue
+ Add a comment

Discuss this story

These comments are automatically transcluded from this article's talk page. To follow comments, add the page to your watchlist. If your comment has not appeared here, you can try purging the cache.

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]

Dear Amir, thank you for this essay - I could not agree more! Actually I am even angry about people who 'sell' a workshop as an instrument to recruit new editors, after all the experiences we made in the last years. Ziko (talk) 13:42, 6 February 2017 (UTC)[reply]
@Fuzheado: Editathons were never meant to recruit new editors - they were aimed at the existing community. Same as marathons are not meant to introduce people to running... But because the idea of an introductory workshop to editing wasn't really around at the time, people morphed editathons to try to do editor recruitment at same time! Thanks. Mike Peel (talk) 16:16, 6 February 2017 (UTC)[reply]
@Mike Peel and Wittylama: - Good point, it may be the right time to make that explicit separation. -- Fuzheado | Talk 16:30, 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]

Thanks for this article, Amir! I'm happy if this dialogue becomes a starting point on what to improve. Pinging DGG (talk · contribs) who says he has run events that actually did produce editors. I have to agree that the usability issues are real, and there is more to add:
  • The Main Page, where most of our readers land, is one of the few without an edit button
  • If an IT-savvy person comes around that knows what 'view source' is, the main page is one of the most cryptic.
  • Ideas on what to improve on Wikipedia appear only after the user has created an account
  • Clicking "anyone can edit" leads to a manual, not to a list of simple things to improve
  • Previewing an edit does not detect edit conflicts. Preview fine, page still doesn't save :(
  • Totally unimportant things result in a barrage of complaints. E.g. not signing on a talk page is no issue at all, a bot does that. However, the bot makes it sound like a problem ("previously unsigned...") instead of neutrally adding "This comment was made by...", and some user will certainly issue a warning on top of that.
I'm sure there is a lot more... someone willing to package this and drop it at the appropriate places? -Pgallert (talk) 06:50, 7 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]

Count me in! It would be great to have some results helping to the organizers of these kind of meetings. Ziko (talk) 16:39, 6 February 2017 (UTC)[reply]
Me too Smallbones(smalltalk) 19:15, 6 February 2017 (UTC)[reply]
I'm interested. Maybe a joint call? Or, you mean a real conference session? -- econterms (talk) 19:31, 6 February 2017 (UTC)[reply]
@Fuzheado: Thanks for the ping. Certainly something I'd be interested to talk more about.
At the risk of reiterating what we already know... A big challenge, as touched upon in this piece (thanks, btw, for writing it Amire80) and in the comments, is the question of what the goal of a given workshop is. Is it to transform new users into active editors? Is it a public relations event (a general celebration of the project? demonstrating a broadly positive ethos? generating warm and fuzzies -- and possibly, indirectly, donations)? Is it to foster community among existing enthusiasts? Is it to make a direct impact on the quality/coverage of articles (by coordinated targeting of particular subject areas or content gaps? by fostering contributions from groups other than the typical wikidemographics)?
Obviously it's rare a workshop will be solely about one of these, but if we're talking about reform and/or experimentation, focusing may make assessment more feasible. There are a lot of these events going on, and with the availability of tools like the Programs & Events Dashboard, certain kinds of outcomes are easier to track now than they have been in the past.
Of course, it may be that the typical edit-a-thon model of public engagement is so entrenched that what we really need is just some experimentation with other models -- to document those models and allow them to be replicated before we start thinking about things like assessment.
Maybe a good project for Wikimania would be not just a session discussing why this is important, but actually planning a few atypical types of workshops for conference participants. Obviously a different audience than is typical, but maybe the most straightforward way to get feedback... — Rhododendrites talk \\ 20:21, 6 February 2017 (UTC)[reply]
@Rhododendrites: - I like the idea of not just talking about alternative methods, but actually performing/demonstrating them with Wikimedians, or at Wikimania, one could also have public-facing sessions to show some of these models. For example, we did this in a very crude manner at Wikiconference North America San Diego, where we had two training sessions a day for the public, which was a very traditional "learn how to edit" class. Maybe we can talk to Coren about doing this at Wikimania in some way. I'll also add some other ideas/resources to the next section that Pete started. -- Fuzheado | Talk 20:44, 6 February 2017 (UTC)[reply]
I feel like a huge piece that is overlooked in the planning and hosting is gauging the audience. I admit, I'm more tech-comfortable than some, and it is easy to forget the level we have reached, and can be hard to remember to cover the little details, when presenting to people. Different audiences will have different goals. For example, I met librarians in the Midwestern US who have the assumption Wikipedia is unreliable. They are not unwilling to learn about Wikipedia, but I can guarantee with their current mindset, they have no interest in spending time editing. They just have not had that belief challenged before through education or in a conversation to encourage learning. Maybe developing structures for people to use in different settings for different audiences would be great. Including information about gauging learning needs of the audience would be equally as important as the content. If you're hosting a session with great information, but no one is learning, it will frustrate attendees and make them not want to come back. Thanks for writing this Amire80 - great information and discussion starters! Jackiekoerner (talk) 16:10, 7 February 2017 (UTC)[reply]
Exactly. At Wikipedia:Meetup/NYC/NYBG January2017 we had librarians and scientists. Hghly literate, ready to learn our details of policy and technique. At public libraries it's diverse. Some are as ready as journalism students, but some don't quite understand how to use the mouse. So, we must pitch to the audience, and alas, sometimes to the lowest skill level because we're not big enough to split the audience. Jim.henderson (talk) 20:12, 7 February 2017 (UTC)[reply]
@Fuzheado: Sounds like a good idea. I'm not planning on being at this Wikimania, but let me know if there's anything online I can do to help. Thanks. Mike Peel (talk) 16:18, 11 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]

+1. Ijon (talk) 05:45, 7 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]

+1 to this. I was at an editathon with new editors the other week and I was so surprised at how new users, who were generally not very technically literate, were able to immediately understand how the visual editor worked. I would get half way through an explanation on what buttons did the thing they needed and they'd already done it. Absolutely endorse using VE with new editors. Sam Walton (talk) 20:06, 15 February 2017 (UTC)[reply]
re "I would get half way through an explanation" - OF course people are generally smart and when hinted into right direction, they will figure out the rest themselves. But what about new editors with no guidance whatsoevr? Did anybody run this kind of experiment? Staszek Lem (talk) 21:31, 15 February 2017 (UTC)[reply]
Sure but my point is that I've done training with both VE and markup and it's been my experience that the users using VE found it immediately easier and more intuitive to use. Sam Walton (talk) 09:57, 17 February 2017 (UTC)[reply]
The research you aks about has been done, see here. Kerry (talk) 14:44, 17 February 2017 (UTC)[reply]
It says basically no difference. Anyway, out of interest I turned it on and got mixed feelings. Some functions did appear handy. However I became frequently frustrated by various glitches during various mundane "non-advanced" operations. To be fair, it is better-behaved compared to over a year ago I tried it last time, when I even could not enter [[]] by plain typing. Staszek Lem (talk) 01:37, 18 February 2017 (UTC)[reply]
Kerry saves a lot of time in workshops. Talking about the VE buttons that insert links and footnotes takes five minutes. Talking about doing the same things using wiki syntax can take half an hour or more. I just mention wiki syntax briefly and move on to talking about VE. If I talk about wiki syntax at all, it's only about indentation and signatures in talk pages (and then I quietly pray for the faster adoption of Flow). --Amir E. Aharoni (talk) 12:15, 6 March 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,

  Bfpage  let's talk...  20:56, 21 February 2017 (UTC)[reply]

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]



       

The Signpost · written by many · served by Sinepost V0.9 · 🄯 CC-BY-SA 4.0