Research talk:New editor engagement strategies

From Meta, a Wikimedia project coordination wiki

Interventions - who's got the problem?[edit]

One of the traps we need to avoid is the mindset that it is the new editor who is the "problem" and who must be "fixed". Messages to new users and safe spaces are examples of "fixing the new user". Perhaps it's Wikipedia that needs the intervention. Realistically the solutions probably involve a bit of fixing the new editor and a bit of fixing of Wikipedia. And when I talk about Wikipedia, I don't just mean the software platform, I also mean the "policies" and the "community". The Visual Editor is an example of "fixing the Wikipedia " rather than fixing the new editor (that is, it accepts that the new editor may not wish to learn wiki syntax). What are our interventions for fixing the policies and fixing the community?

In particular, the term "safe spaces" always makes me nervous, as there is an implied status quo that it's dangerous out there and that this can't be changed. I presume the danger is the community and its abrasive style of interaction. While WMF and those of us reading this probably care about editor attrition, it is not clear to me that the community cares so much about it. While we have w:WP:BITE, it is:

  1. unlikely to be ever read by an newbie
  2. contains advice to the experienced editor that isn't tremendously helpful in practice (even if you want to avoid biting newcomers)

I don't think we should start with the presumption that we have to teach new editors to survive in the jungle (WP:BITE actually uses the jungle metaphor!) before we have tried to tame the jungle. As an analogy, a lot of work has been done on reducing crime through intelligent urban design. A lot of it seems obvious in retrospect, keep spaces open and well-lit, etc. Can we "design in" a safer environment into Wikipedia, one more gentle and engaging for the newbies?

Some simple community interventions. Think about our watchlists. You get told that User:SoAndSo has changed article SuchAndSuch. You get a link to show the diffs. Now I click the diff link and I think "oh no, what a terrible thing they have done" and reach for the "undo" button. At which point in this sequence did I find out it was a new user so I could apply WP:BITE? Of course, I could go and follow some links and see the user's contributions or whatever, but I'm a busy person, I've got lots more watchlist notificaitons to deal with, etc. Maybe if information that this was a new user was prominently displayed on the watchlist and on the diff page (without my having to go and look for it), I might think twice about immediately clicking UNDO.

Community Intervention No 1. Let nobody click the UNDO button without knowing it's a new editor, so there's no excuse for overlooking WP:BITE.

Community Intervention No 2. If it's a new editor, maybe the UNDO button could be taken away and replaced with three buttons:

  • UNDO BAD FAITH EDIT
  • DISCUSS EDIT WITH GOOD FAITH EDITOR button
  • SEND WELCOME MESSAGE AND THANKS

That is, try to embody WP:BITE into the user interface.

Community Invention No. 3. Make it easier to the "right thing" by the new user than the "wrong thing". Currently, we have excellent support for undo, a couple of clicks and it's gone. It's much easier to undo than to do the more constructive alternatives. Can we turn that around? For example, the DISCUSS button could whisk me away to the user's talk page and automatically start the message "Hi, SoAndSo! About your edit to SuchAndSuch [insert diffs here], I wanted to ask you a question about it". Make it as easy (or easier) to ask the question as to undo. If might be achieved by making UNDO a little bit harder, e.g. require tick the box to say "it's vandalism", "it's patent nonsense" etc that are true justifications for reverting a new user.

Let's think about how we intervene with our community to improve new editor engagement. The whole community has to take responsibility for this, not just those who want to volunteer to be mentors or whatever. For new editor engagement to work, it must be scalable and ideally done through the platform. Kerry Raymond (talk) 01:58, 25 September 2014 (UTC)[reply]

I like your idea of interventions - I really like the idea of changing the "undo" option: it could become a gadget for any editor, where you could set up a new section on the user talk page and discuss the diff with the subheading "I reverted your edit on <article> name on <date stamp>" and then a box for you to fill in explanatory text. Alternatively, maybe the gadget would work for any diff, that way you could undo it later after you use the gadget? In any case, I really think we should leave the "Thanks" alone. It really seems to work well, and it probably works well because it is so easy, uncomplicated, and language independent. Jane023 (talk) 09:56, 26 September 2014 (UTC)[reply]

Ghost edits on mobile[edit]

On the mailing list I discussed my ghost edits on my iPad, where I mentioned that edits I would normally do in response to something on my watchlist never get done because I can't do them on my iPad and by the time I'm on my laptop, my watch list has changed again and priorities get reshuffled, causing those "tablet-unfriendly" tasks to get buried where they become eventually "ghost edits", which means they never get done at all. Kerry responded with an explanation of a method of keeping emails regarding her watchlist. I would prefer a button onwiki where I could quickly type in something to my own user subpage (User:Jane023:Ghost-edits?) with a stamp of the time, article name and place to write something cryptic as a reminder to myself. If this gadget could be structured well (offering some selection options indicating what you attempted to edit, such as updating categories, adding or modifying a picture, editting an infobox, etc), then it may even be harvested for data about ghost edits. Jane023 (talk) 10:05, 26 September 2014 (UTC)[reply]

I think an easy to manage To-do list would be useful for both watchlists and all those other "things I mean to do when I have time". As Jane suggests, it should be simple: a click from the article leading to a text box for a short note-to-self would be all you need to create an entry, plus a means to view it by date or by search for keyword etc and to modify/delete entries. Kerry Raymond (talk) 00:13, 27 September 2014 (UTC)[reply]

Controlled new page creation[edit]

One of the things I would like to see is an easy way for editors in an edit-a-thon to create new articles that are likely to stick around. We have various hot lists of wanted articles, but it is always helpful to have specific lists for a group to work on. In my experience however, very few people will create an article just because they can. Generally people want to create an article because they honestly feel it makes a specific contribution along some interest that they have, from ant species to Simpson's episodes. Theoretically, an edit-a-thon attracts people interested in contributing to the subject at hand. It would be nice for organizers to have more tools to offer candidate Wikipedians the chance to create articles in a controlled environment. A lot of aspects of a Wikipedia article are obvious "must haves" to the experienced editor, but seem unnecessary cruft to the newbie. I wrote a bit about the difficulties of the process of translating Wikipedia articles in my evaluation notes on an edit-a-thon in The Hague on 12 October 2013. Now, with Wikidata, we have a way for the basic structure of a Wikipedia article to be deconstructed so that it can be rebuilt as a fully fleshed-out stub in some other language. Using the query mechanism, we can find articles in desired categories that have no English equivalent, so that generating lists to work on is easier, and generating stub information for newbies becomes possible. An example of a stub creator is Magnus' tool for biography preparation. I have asked him to prefill the fields from Wikidata if the user knows the Q number, and he will take a look when he gets back from vacation. That way, you could create lists for newbies that with one click can create a notepad-ready Wiki-stub that after some group-discussion and checks or tweaking, can be pasted into a redlink article creation window in draft or mainspace. Such a set of tools would be valuable for edit-a-thon attendees to use, but also for anybody interested in a Wikiproject that has such pages enabled in their wikiproject space. Jane023 (talk) 11:24, 26 September 2014 (UTC)[reply]