Re: [Wiki-research-l] FW: What works for increasing editor engagement?
On Fri, Sep 26, 2014 at 1:46 PM, WereSpielChequers < werespielchequ...@gmail.com> wrote: > Attn Luca and Scott > > There are some things best avoided as going against community > expectations. I would be happy to see flagged revisions deployed on the > English Wikipedia but I'm well aware that there is a significant lobby > against that of people who believe that it is important that your edit goes > live immediately. And with the community somewhat burned by bad experiences > with recent software changes now would be a bad time to suggest such a > controversial change. > > Yes. Completely agree, and that was the exact point of my first email: On Fri, Sep 26, 2014 at 9:15 AM, Scott Hale wrote: > And that is the fundamental flaw with this whole email thread. The > question needing to be answered isn't "what increases new user retention". > The real question is "what increases new user retention and is acceptable > to the most active/helpful existing users". The second question is much > harder than the first. > ___ Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
Re: [Wiki-research-l] FW: What works for increasing editor engagement?
FWIW there were sessions at Wikimania about concurrent editing. I think there is community support for the concept. If it helps us retain good faith new editors then that is another good reason to press foward on this subject. Perhaps James Forrester can provide an update on the outlook for concurrent editing capability. Pine On Sep 25, 2014 10:17 PM, "Luca de Alfaro" wrote: This last message of yours Jonathan is very insightful and true. I wonder how it would be possible to set up some kind of controlled study on how different edit capabilities lead to different engagements. One could always set up controlled mirrors of the Wikipedia for a small set of pages on a coherent topic, and perhaps measure the difference in engagement? Do you think that there is a way to do this? There are also pages that are very different. The rapidly evolving page on a current event requires rapid communication of edits. Instead, a novice that edits a page on a topic with little traffic is best left alone (no tweaking that causes edit conflicts) until she/he is done. Luca On Thu, Sep 25, 2014 at 10:13 PM, WereSpielChequers < werespielchequ...@gmail.com> wrote: > We have had endless discussions about this in the new page patrol > community. Basically there is a divide between those who think it important > to communicate with people as quickly as possible so they have a chance to > fix things before they log off and people such as myself who think that > this drives people away. So before we try to make people more aware that > they are dealing with a newbie it would help if we had some neutral > independent research that indicated which position is more grounded in > reality. Simply making it clearer to patrollers that they are dealing with > newbies is solving a non problem, we know the difference between newbies > and regulars, we just disagree as to the best way to handle newbies. > Investing in software to tell patrollers when they are dealing with newbies > is unlikely to help, in fact I would be willing to bet that one of the > criticisms will be from patrollers saying that it isn't doing that job as > well as they can because it doesn't spot which editors are obviously > experienced even if their latest account is not yet auto confirmed. > > There is also the issue that some patrollers may not realise how many edit > conflicts they cause by templating and categorising articles. Afterall it > isn't going to be the templater or categoriser who loses the edit conflict, > that is almost guaranteed to be the newbie. Of course this could be > resolved by changing the software so that adding a category or template is > not treated as conflicting with changing the text. > > Regards > > Jonathan Cardy > > > On 25 Sep 2014, at 23:23, Luca de Alfaro wrote: > > Re. the edit conflicts happening when a new user is editing: > > Can't one add some AJAX to the editor that notifies that one still has the > editing window open? Maybe editors could wait to modify work in progress, > if they had that indication, and if the content does not seem vandalism? > > Luca > > On Thu, Sep 25, 2014 at 12:17 PM, James Salsman > wrote: > >> Aaron, would you please post the script you used to create >> >> https://commons.wikimedia.org/wiki/File:Desirable_newcomer_survival_over_time.png >> ? >> >> I would be happy to modify it to also collect the number of extant >> non-redirect articles each desirable user created. >> >> > Aaron wrote: >> > >... You'll find the hand-coded set of users here >> > > http://datasets.wikimedia.org/public-datasets/enwiki/rise-and-decline >> > >... >> > > Categories: >> > > >> > > 1. Vandals - Purposefully malicious, out to cause harm >> > > 2. Bad-faith - Trying to be funny, not here to help or harm >> > > 3. Good-faith - Trying to be productive, but failing >> > > 4. Golden - Successfully contributing productively >> >> ___ >> Wiki-research-l mailing list >> Wiki-research-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wiki-research-l >> > > ___ > Wiki-research-l mailing list > Wiki-research-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wiki-research-l > > ___ Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l ___ Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
Re: [Wiki-research-l] FW: What works for increasing editor engagement?
This last message of yours Jonathan is very insightful and true. I wonder how it would be possible to set up some kind of controlled study on how different edit capabilities lead to different engagements. One could always set up controlled mirrors of the Wikipedia for a small set of pages on a coherent topic, and perhaps measure the difference in engagement? Do you think that there is a way to do this? There are also pages that are very different. The rapidly evolving page on a current event requires rapid communication of edits. Instead, a novice that edits a page on a topic with little traffic is best left alone (no tweaking that causes edit conflicts) until she/he is done. Luca On Thu, Sep 25, 2014 at 10:13 PM, WereSpielChequers < werespielchequ...@gmail.com> wrote: > We have had endless discussions about this in the new page patrol > community. Basically there is a divide between those who think it important > to communicate with people as quickly as possible so they have a chance to > fix things before they log off and people such as myself who think that > this drives people away. So before we try to make people more aware that > they are dealing with a newbie it would help if we had some neutral > independent research that indicated which position is more grounded in > reality. Simply making it clearer to patrollers that they are dealing with > newbies is solving a non problem, we know the difference between newbies > and regulars, we just disagree as to the best way to handle newbies. > Investing in software to tell patrollers when they are dealing with newbies > is unlikely to help, in fact I would be willing to bet that one of the > criticisms will be from patrollers saying that it isn't doing that job as > well as they can because it doesn't spot which editors are obviously > experienced even if their latest account is not yet auto confirmed. > > There is also the issue that some patrollers may not realise how many edit > conflicts they cause by templating and categorising articles. Afterall it > isn't going to be the templater or categoriser who loses the edit conflict, > that is almost guaranteed to be the newbie. Of course this could be > resolved by changing the software so that adding a category or template is > not treated as conflicting with changing the text. > > Regards > > Jonathan Cardy > > > On 25 Sep 2014, at 23:23, Luca de Alfaro wrote: > > Re. the edit conflicts happening when a new user is editing: > > Can't one add some AJAX to the editor that notifies that one still has the > editing window open? Maybe editors could wait to modify work in progress, > if they had that indication, and if the content does not seem vandalism? > > Luca > > On Thu, Sep 25, 2014 at 12:17 PM, James Salsman > wrote: > >> Aaron, would you please post the script you used to create >> >> https://commons.wikimedia.org/wiki/File:Desirable_newcomer_survival_over_time.png >> ? >> >> I would be happy to modify it to also collect the number of extant >> non-redirect articles each desirable user created. >> >> > Aaron wrote: >> > >... You'll find the hand-coded set of users here >> > > http://datasets.wikimedia.org/public-datasets/enwiki/rise-and-decline >> > >... >> > > Categories: >> > > >> > > 1. Vandals - Purposefully malicious, out to cause harm >> > > 2. Bad-faith - Trying to be funny, not here to help or harm >> > > 3. Good-faith - Trying to be productive, but failing >> > > 4. Golden - Successfully contributing productively >> >> ___ >> Wiki-research-l mailing list >> Wiki-research-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wiki-research-l >> > > ___ > Wiki-research-l mailing list > Wiki-research-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wiki-research-l > > ___ Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
Re: [Wiki-research-l] FW: What works for increasing editor engagement?
Jonathan, I think you are right. My impression, as someone who now is a bit of an "outsider" in the sense that it's long time I have not done an edit, is that Wikipedia - that is, Mediawiki - is in need of a usability overhaul. Other sites where people write just feel smoother, from Blogger to Google Docs to WordPress. Other sites just feel more welcoming, such as openstreetmap, where I can fix the map without anyone immediately coming to bite me or to create edit conflicts (a big part of the reason why I put my time there nowadays when I feel like contributing to the common good). Wikipedia has a concomitance of factors -- no saving of drafts, editors immediately jumping in as soon as one saves, no delay in making information live, obscure set of rules that are simply not known to novices, ... it just doesn't feel like a place where a normal user is welcome. It also feels "old" in the clumsy way it can be edited. As it is losing its novelty factor, this is a problem. Luca On Thu, Sep 25, 2014 at 9:46 PM, WereSpielChequers < werespielchequ...@gmail.com> wrote: > Attn Luca and Scott > > There are some things best avoided as going against community > expectations. I would be happy to see flagged revisions deployed on the > English Wikipedia but I'm well aware that there is a significant lobby > against that of people who believe that it is important that your edit goes > live immediately. And with the community somewhat burned by bad experiences > with recent software changes now would be a bad time to suggest such a > controversial change. > > Saving drafts is potentially more doable. My preference for new articles > is to start them in sandboxes, that way you are highly unlikely to get > uninvited editors unless you are creating an attack page or committing > copyright violation. For existing articles you can simply copy and paste > your draft of a paragraph into your own sandbox, but this is not exactly > intuitive for new editors. Leaving a tab open on your PC is not viable if > you are at an editathon, especially if you are on a borrowed PC, but it > works at home. My recommendation is to encourage people to save little and > often, however that still leaves situations where people need to simply > save a paragraph or two somewhere privately. One option would be to write a > gadget that gave people the option to save work to sandbox. They could then > highlight the bit they are working on, or even let mediawiki suggest the > bit they are working on, and have the paragraph appended as a new section > on their sandbox with an auto generated edit summary giving attribution. > That would require development but would I think be uncontentious. > > Better merging would also be uncontentious with the editing community, but > has historically been opposed by the developers. There several suggestions > on Bugzilla marooned as "won't fix" it may be that this is a communication > problem and the developers have a good reason such as not having the source > code, but at present it looks like they as programmers don't understand how > difficult it is for non programmers to resolve an edit conflict. > > I would love to see some sort of private draft space created for editors > where only they can see stuff. This would require a software change and a > cultural change. Space is now so cheap that we can afford to have tens of > thousands of editors each have a few megabytes of private space that only > they can see and which no one need check because no one has access. But the > idea of unchecked space and free hosting is controversial to some, I > suspect it would require the foundation to say what the cost of a gigabyte > of extra userspace was and for WMF legal to green light the idea of not > checking the contents of things that only the person who wrote them can see. > > There is an element of tension between better merging and private drafts. > Basically the more differences emerge between the draft and the main space > copy the more difficult to merge them back, this is one of the reasons why > some people don't think that flagged revisions or pending changes is > suitable for rapidly changing articles. That's why my preference is to save > little and often and privately store the sentence you want to add not your > version of an article. > > Regards > > Jonathan Cardy > > > On 26 Sep 2014, at 04:58, Scott Hale wrote: > > Yes, drafts visible only to the user are different. I was thinking of > flagged revisions in reference to your idea that edits would first go live > only after a set period of time. This is basically flagged revisions with a > trivial extension that the flagged revision always be the latest revision > that is at least X minutes old. > > We could also allow a time window (even 30 minutes) before edits went live >> after one is done editing (using above Ajax mechanism to track when editor >> open), experienced editors would not need to swoop in quite so fast on the >> work of new users,
Re: [Wiki-research-l] FW: What works for increasing editor engagement?
We have had endless discussions about this in the new page patrol community. Basically there is a divide between those who think it important to communicate with people as quickly as possible so they have a chance to fix things before they log off and people such as myself who think that this drives people away. So before we try to make people more aware that they are dealing with a newbie it would help if we had some neutral independent research that indicated which position is more grounded in reality. Simply making it clearer to patrollers that they are dealing with newbies is solving a non problem, we know the difference between newbies and regulars, we just disagree as to the best way to handle newbies. Investing in software to tell patrollers when they are dealing with newbies is unlikely to help, in fact I would be willing to bet that one of the criticisms will be from patrollers saying that it isn't doing that job as well as they can because it doesn't spot which editors are obviously experienced even if their latest account is not yet auto confirmed. There is also the issue that some patrollers may not realise how many edit conflicts they cause by templating and categorising articles. Afterall it isn't going to be the templater or categoriser who loses the edit conflict, that is almost guaranteed to be the newbie. Of course this could be resolved by changing the software so that adding a category or template is not treated as conflicting with changing the text. Regards Jonathan Cardy > On 25 Sep 2014, at 23:23, Luca de Alfaro wrote: > > Re. the edit conflicts happening when a new user is editing: > > Can't one add some AJAX to the editor that notifies that one still has the > editing window open? Maybe editors could wait to modify work in progress, if > they had that indication, and if the content does not seem vandalism? > > Luca > >> On Thu, Sep 25, 2014 at 12:17 PM, James Salsman wrote: >> Aaron, would you please post the script you used to create >> https://commons.wikimedia.org/wiki/File:Desirable_newcomer_survival_over_time.png >> ? >> >> I would be happy to modify it to also collect the number of extant >> non-redirect articles each desirable user created. >> >> > Aaron wrote: >> > >... You'll find the hand-coded set of users here >> > > http://datasets.wikimedia.org/public-datasets/enwiki/rise-and-decline >> > >... >> > > Categories: >> > > >> > > 1. Vandals - Purposefully malicious, out to cause harm >> > > 2. Bad-faith - Trying to be funny, not here to help or harm >> > > 3. Good-faith - Trying to be productive, but failing >> > > 4. Golden - Successfully contributing productively >> >> ___ >> Wiki-research-l mailing list >> Wiki-research-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wiki-research-l > > ___ > Wiki-research-l mailing list > Wiki-research-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wiki-research-l ___ Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
Re: [Wiki-research-l] FW: What works for increasing editor engagement?
Attn Luca and Scott There are some things best avoided as going against community expectations. I would be happy to see flagged revisions deployed on the English Wikipedia but I'm well aware that there is a significant lobby against that of people who believe that it is important that your edit goes live immediately. And with the community somewhat burned by bad experiences with recent software changes now would be a bad time to suggest such a controversial change. Saving drafts is potentially more doable. My preference for new articles is to start them in sandboxes, that way you are highly unlikely to get uninvited editors unless you are creating an attack page or committing copyright violation. For existing articles you can simply copy and paste your draft of a paragraph into your own sandbox, but this is not exactly intuitive for new editors. Leaving a tab open on your PC is not viable if you are at an editathon, especially if you are on a borrowed PC, but it works at home. My recommendation is to encourage people to save little and often, however that still leaves situations where people need to simply save a paragraph or two somewhere privately. One option would be to write a gadget that gave people the option to save work to sandbox. They could then highlight the bit they are working on, or even let mediawiki suggest the bit they are working on, and have the paragraph appended as a new section on their sandbox with an auto generated edit summary giving attribution. That would require development but would I think be uncontentious. Better merging would also be uncontentious with the editing community, but has historically been opposed by the developers. There several suggestions on Bugzilla marooned as "won't fix" it may be that this is a communication problem and the developers have a good reason such as not having the source code, but at present it looks like they as programmers don't understand how difficult it is for non programmers to resolve an edit conflict. I would love to see some sort of private draft space created for editors where only they can see stuff. This would require a software change and a cultural change. Space is now so cheap that we can afford to have tens of thousands of editors each have a few megabytes of private space that only they can see and which no one need check because no one has access. But the idea of unchecked space and free hosting is controversial to some, I suspect it would require the foundation to say what the cost of a gigabyte of extra userspace was and for WMF legal to green light the idea of not checking the contents of things that only the person who wrote them can see. There is an element of tension between better merging and private drafts. Basically the more differences emerge between the draft and the main space copy the more difficult to merge them back, this is one of the reasons why some people don't think that flagged revisions or pending changes is suitable for rapidly changing articles. That's why my preference is to save little and often and privately store the sentence you want to add not your version of an article. Regards Jonathan Cardy > On 26 Sep 2014, at 04:58, Scott Hale wrote: > > Yes, drafts visible only to the user are different. I was thinking of flagged > revisions in reference to your idea that edits would first go live only after > a set period of time. This is basically flagged revisions with a trivial > extension that the flagged revision always be the latest revision that is at > least X minutes old. > >> We could also allow a time window (even 30 minutes) before edits went live >> after one is done editing (using above Ajax mechanism to track when editor >> open), experienced editors would not need to swoop in quite so fast on the >> work of new users, and the whole editing atmosphere would be more relaxed >> and welcoming. > > I think the challenge with drafts visible only to the user is that they are > very likely to have a conflict and have to merge changes if they wait too > long between starting the draft and later committing it. > > > >> On Fri, Sep 26, 2014 at 9:20 AM, Luca de Alfaro wrote: >> Flagged revisions is different though, as it requires "trusted" editors to >> flag things as approved. I am simply advocating the ability to save drafts >> visible only to oneself before "publishing" a change. WordPress, Blogger, >> etc have it. And so newcomers could edit to their heart content, without >> triggering the interest of editors and the consequent conflicts, then save >> their changes. >> >> Luca >> >> >> >>> On Thu, Sep 25, 2014 at 5:15 PM, Scott Hale >>> wrote: On Fri, Sep 26, 2014 at 5:14 AM, Luca de Alfaro wrote: Better merging would be welcome. But also less aggressive editing/policing. When I edit openstreetmap I have a better overall experience: the edits may or may not go live immediately, but I d
Re: [Wiki-research-l] FW: What works for increasing editorengagement?
I don't doubt that Australian newbies editing existing well developed articles are going to find they are editing things on existing Australian editors watch lists. My experience of editathons is mostly about creating new articles or improving very neglected ones, usually by expanding stubs, or working from lists of articles without images. Such articles are unlikely to be on anyone's watchlist, or if they are they aren't likely to object to good faith expansion. But I would still expect that existing editors would be looking at edits as fast as they come in, not because of watchlists but because they are at recent changes or new page patrol watching new edits as they come in. Though if an Editathon is focussed on particular articles, we have one coming up at the Royal Opera house which will focus on some of the people historically associated with them, then inviting the relevant wiki project is one way to alert the existing editors. Thinking about this I will drop an invitation to the ROH editathon on the talk page of established articles we are going to focus on. I think this would be an interesting topic for someone to do research, whether the problem is with watchlisters or patrollers should be easy to spot. When existing editors come into conflict with newbies at editathons, looking at the established editors editing are they past contributors to that article, and before their intervention were their edits to random new pages/random pages edited in the past few moments or were they to other articles they had also previously edited. If we can identify the types of conflicts going on we can be clearer about the types of changes that we need people to make. My editathons rarely hit problems of conflict with existing editors, and when they do it is usually that people insist on writing an article on a subject where they can't find the two independent reliable sources that I suggested they need before creating an article. Partly I avoid this by starting people off with easy steps, signing the event page may get them an edit conflict but also shows them how to resolve a simple one. Creating new articles in sandboxes, and warning them that others will probably edit them within minutes of their moving to main space; Encouraging people to save frequently means they don't have complex edit conflicts over multiple paragraphs and telling them always to leave an edit summary, "edit summaries are optional, so vandals rarely bother with them and even a one word edit summary if expand, pic or typo is code for I am not a vandal." Regards Jonathan Cardy > On 26 Sep 2014, at 00:31, Kerry Raymond wrote: > > Australian outreach events generally edit Australian content. Other > Australian editors are likely to be on the watch list and are likely to be in > the timezone. And plenty of non-Australian editors are sitting in their > pyjamas at all hours of the day and night waiting to pounce. Believe me, new > editors encounter other editors very quickly (although sometimes they don’t > realise it). They often think it “rude” that other people are editing the > article “while I am in the middle of working on it”. Their mental model of > collaborative editing is like a shared lawn mower. You have sole use for a > while; then it is passed on to the next person. > > Not sure I can help you with London editathons. But I do have a couple of > edit training days coming up in Oakey, Queensland in a few weeks: > > https://en.wikipedia.org/wiki/Oakey,_Queensland > > Kerry > > > From: WereSpielChequers [mailto:werespielchequ...@gmail.com] > Sent: Thursday, 25 September 2014 9:38 PM > To: kerry.raym...@gmail.com; Research into Wikimedia content and communities > Subject: Re: [Wiki-research-l] FW: What works for increasing editorengagement? > > Yes, training newbies is a great way to learn and to see the flaws that we > mentally blank out. I also found that I need to keep a vanilla account for > demonstrating things to newbies, if I use my WereSpielChequers account the > various extra buttons confuse people. > > I wouldn't worry too much about watchlisters making edits and causing edit > conflicts, most of the time you aren't going to be in the same time zone, > watchlisters even the most active ones are unlikely to check their watch list > more than a few times a day. So as long as you don't start newbies on highly > watched articles like Sarah Palin you should be OK with them. But edit > conflicts are a real problem for newbies and especially those creating new > articles. The new page patrol people need to look at articles as they are > created in order to pick up attack pages etc, and when they find OK articles > they tend to at least categorise them. Some of this could be fixed by > improving the software for handling edit conflicts, for example it would be > nice if adding a category and changing some text were not treated as a > conflict. However this i
Re: [Wiki-research-l] FW: What works for increasing editor engagement?
I put a couple of interventions specifically targeting improving the new contributor experience here: https://meta.wikimedia.org/wiki/Research_talk:New_editor_engagement_strategies Which might have been a mistake as the conversation is happening via email. Sent from my iPad > On 26 Sep 2014, at 11:02 am, Luca de Alfaro wrote: > > You are right about conflicts with fast-updated pages. Not sure it would be > worse than the current situation though. > For many low traffic articles, drafts only visible to the user would not have > many conflicts -- basically, for all pages with fewer than a couple of edits > per day this would be true, and there are many such pages. > I think a more annoying issue would be how to clean up these drafts; a policy > would be required (one week?), cron jobs, etc, otherwise these drafts could > grow uncontrollably in size due to abandoned edits. But this should be > solvable, if with some pain. > > I tend to think that with a bit of UI tweaking, Wikipedia could be made more > friendly > > > >> On Thu, Sep 25, 2014 at 5:58 PM, Scott Hale >> wrote: >> Yes, drafts visible only to the user are different. I was thinking of >> flagged revisions in reference to your idea that edits would first go live >> only after a set period of time. This is basically flagged revisions with a >> trivial extension that the flagged revision always be the latest revision >> that is at least X minutes old. >> >>> We could also allow a time window (even 30 minutes) before edits went live >>> after one is done editing (using above Ajax mechanism to track when editor >>> open), experienced editors would not need to swoop in quite so fast on the >>> work of new users, and the whole editing atmosphere would be more relaxed >>> and welcoming. >> >> I think the challenge with drafts visible only to the user is that they are >> very likely to have a conflict and have to merge changes if they wait too >> long between starting the draft and later committing it. >> >> >> >>> On Fri, Sep 26, 2014 at 9:20 AM, Luca de Alfaro wrote: >>> Flagged revisions is different though, as it requires "trusted" editors to >>> flag things as approved. I am simply advocating the ability to save drafts >>> visible only to oneself before "publishing" a change. WordPress, Blogger, >>> etc have it. And so newcomers could edit to their heart content, without >>> triggering the interest of editors and the consequent conflicts, then save >>> their changes. >>> >>> Luca >>> >>> >>> On Thu, Sep 25, 2014 at 5:15 PM, Scott Hale wrote: > On Fri, Sep 26, 2014 at 5:14 AM, Luca de Alfaro wrote: > Better merging would be welcome. But also less aggressive > editing/policing. > > When I edit openstreetmap I have a better overall experience: the edits > may or may not go live immediately, but I don't have the impression that > there is someone aggressively vetting/refining my edits while I am still > doing them. I feel welcome there. > > To make Wikipedia more welcoming, we could do a few things. > > We could allow users to save drafts. In this way, people could work for > a while at their own pace, and then publish the changes. Currently, > saving is the only way to avoid risking losing changes, but it has the > very undesired effect of inviting editors/vetters to the page before one > is really done. > > We could also allow a time window (even 30 minutes) before edits went > live after one is done editing (using above Ajax mechanism to track when > editor open), experienced editors would not need to swoop in quite so > fast on the work of new users, and the whole editing atmosphere would be > more relaxed and welcoming. > > The fact is that the Wikipedia editor, with its lack of ability to save > drafts, poor merging, and swooping editors, feels incredibly outdated and > unwelcoming - downright aggressive - to anyone used to WordPress / Google > Docs / Blogger / ... > > Luca The technology exists to do this---[[:en:Wikipedia:Flagged_revisions]]. The challenge is that many existing users don't want flagged revisions on by default. And that is the fundamental flaw with this whole email thread. The question needing to be answered isn't "what increases new user retention". The real question is "what increases new user retention and is acceptable to the most active/helpful existing users". The second question is much harder than the first. >> >> >> >> -- >> Scott Hale >> Oxford Internet Institute >> University of Oxford >> http://www.scotthale.net/ >> scott.h...@oii.ox.ac.uk > > ___ > Wiki-research-l mailing list > Wiki-research-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wiki-research-l ___
Re: [Wiki-research-l] FW: What works for increasing editor engagement?
You are right about conflicts with fast-updated pages. Not sure it would be worse than the current situation though. For many low traffic articles, drafts only visible to the user would not have many conflicts -- basically, for all pages with fewer than a couple of edits per day this would be true, and there are many such pages. I think a more annoying issue would be how to clean up these drafts; a policy would be required (one week?), cron jobs, etc, otherwise these drafts could grow uncontrollably in size due to abandoned edits. But this should be solvable, if with some pain. I tend to think that with a bit of UI tweaking, Wikipedia could be made more friendly On Thu, Sep 25, 2014 at 5:58 PM, Scott Hale wrote: > Yes, drafts visible only to the user are different. I was thinking of > flagged revisions in reference to your idea that edits would first go live > only after a set period of time. This is basically flagged revisions with a > trivial extension that the flagged revision always be the latest revision > that is at least X minutes old. > > We could also allow a time window (even 30 minutes) before edits went live >> after one is done editing (using above Ajax mechanism to track when editor >> open), experienced editors would not need to swoop in quite so fast on the >> work of new users, and the whole editing atmosphere would be more relaxed >> and welcoming. >> > > I think the challenge with drafts visible only to the user is that they > are very likely to have a conflict and have to merge changes if they wait > too long between starting the draft and later committing it. > > > > On Fri, Sep 26, 2014 at 9:20 AM, Luca de Alfaro wrote: > >> Flagged revisions is different though, as it requires "trusted" editors >> to flag things as approved. I am simply advocating the ability to save >> drafts visible only to oneself before "publishing" a change. WordPress, >> Blogger, etc have it. And so newcomers could edit to their heart content, >> without triggering the interest of editors and the consequent conflicts, >> then save their changes. >> >> Luca >> >> >> >> On Thu, Sep 25, 2014 at 5:15 PM, Scott Hale >> wrote: >> >>> On Fri, Sep 26, 2014 at 5:14 AM, Luca de Alfaro >>> wrote: >>> Better merging would be welcome. But also less aggressive editing/policing. When I edit openstreetmap I have a better overall experience: the edits may or may not go live immediately, but I don't have the impression that there is someone aggressively vetting/refining my edits while I am still doing them. I feel welcome there. To make Wikipedia more welcoming, we could do a few things. We could allow users to save drafts. In this way, people could work for a while at their own pace, and then publish the changes. Currently, saving is the only way to avoid risking losing changes, but it has the very undesired effect of inviting editors/vetters to the page before one is really done. We could also allow a time window (even 30 minutes) before edits went live after one is done editing (using above Ajax mechanism to track when editor open), experienced editors would not need to swoop in quite so fast on the work of new users, and the whole editing atmosphere would be more relaxed and welcoming. The fact is that the Wikipedia editor, with its lack of ability to save drafts, poor merging, and swooping editors, feels incredibly outdated and unwelcoming - downright aggressive - to anyone used to WordPress / Google Docs / Blogger / ... Luca >>> >>> The technology exists to do this---[[:en:Wikipedia:Flagged_revisions]]. >>> The challenge is that many existing users don't want flagged revisions on >>> by default. >>> >>> And that is the fundamental flaw with this whole email thread. The >>> question needing to be answered isn't "what increases new user retention". >>> The real question is "what increases new user retention and is acceptable >>> to the most active/helpful existing users". The second question is much >>> harder than the first. >>> >>> >>> >>> >>> >> > > > -- > Scott Hale > Oxford Internet Institute > University of Oxford > http://www.scotthale.net/ > scott.h...@oii.ox.ac.uk > ___ Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
Re: [Wiki-research-l] FW: What works for increasing editor engagement?
Yes, drafts visible only to the user are different. I was thinking of flagged revisions in reference to your idea that edits would first go live only after a set period of time. This is basically flagged revisions with a trivial extension that the flagged revision always be the latest revision that is at least X minutes old. We could also allow a time window (even 30 minutes) before edits went live > after one is done editing (using above Ajax mechanism to track when editor > open), experienced editors would not need to swoop in quite so fast on the > work of new users, and the whole editing atmosphere would be more relaxed > and welcoming. > I think the challenge with drafts visible only to the user is that they are very likely to have a conflict and have to merge changes if they wait too long between starting the draft and later committing it. On Fri, Sep 26, 2014 at 9:20 AM, Luca de Alfaro wrote: > Flagged revisions is different though, as it requires "trusted" editors to > flag things as approved. I am simply advocating the ability to save drafts > visible only to oneself before "publishing" a change. WordPress, Blogger, > etc have it. And so newcomers could edit to their heart content, without > triggering the interest of editors and the consequent conflicts, then save > their changes. > > Luca > > > > On Thu, Sep 25, 2014 at 5:15 PM, Scott Hale > wrote: > >> On Fri, Sep 26, 2014 at 5:14 AM, Luca de Alfaro >> wrote: >> >>> Better merging would be welcome. But also less aggressive >>> editing/policing. >>> >>> When I edit openstreetmap I have a better overall experience: the edits >>> may or may not go live immediately, but I don't have the impression that >>> there is someone aggressively vetting/refining my edits while I am still >>> doing them. I feel welcome there. >>> >>> To make Wikipedia more welcoming, we could do a few things. >>> >>> We could allow users to save drafts. In this way, people could work for >>> a while at their own pace, and then publish the changes. Currently, saving >>> is the only way to avoid risking losing changes, but it has the very >>> undesired effect of inviting editors/vetters to the page before one is >>> really done. >>> >>> We could also allow a time window (even 30 minutes) before edits went >>> live after one is done editing (using above Ajax mechanism to track when >>> editor open), experienced editors would not need to swoop in quite so fast >>> on the work of new users, and the whole editing atmosphere would be more >>> relaxed and welcoming. >>> >>> The fact is that the Wikipedia editor, with its lack of ability to save >>> drafts, poor merging, and swooping editors, feels incredibly outdated and >>> unwelcoming - downright aggressive - to anyone used to WordPress / Google >>> Docs / Blogger / ... >>> >>> Luca >>> >>> >> >> The technology exists to do this---[[:en:Wikipedia:Flagged_revisions]]. >> The challenge is that many existing users don't want flagged revisions on >> by default. >> >> And that is the fundamental flaw with this whole email thread. The >> question needing to be answered isn't "what increases new user retention". >> The real question is "what increases new user retention and is acceptable >> to the most active/helpful existing users". The second question is much >> harder than the first. >> >> >> >> >> > -- Scott Hale Oxford Internet Institute University of Oxford http://www.scotthale.net/ scott.h...@oii.ox.ac.uk ___ Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
Re: [Wiki-research-l] FW: What works for increasing editor engagement?
Flagged revisions is different though, as it requires "trusted" editors to flag things as approved. I am simply advocating the ability to save drafts visible only to oneself before "publishing" a change. WordPress, Blogger, etc have it. And so newcomers could edit to their heart content, without triggering the interest of editors and the consequent conflicts, then save their changes. Luca On Thu, Sep 25, 2014 at 5:15 PM, Scott Hale wrote: > On Fri, Sep 26, 2014 at 5:14 AM, Luca de Alfaro wrote: > >> Better merging would be welcome. But also less aggressive >> editing/policing. >> >> When I edit openstreetmap I have a better overall experience: the edits >> may or may not go live immediately, but I don't have the impression that >> there is someone aggressively vetting/refining my edits while I am still >> doing them. I feel welcome there. >> >> To make Wikipedia more welcoming, we could do a few things. >> >> We could allow users to save drafts. In this way, people could work for >> a while at their own pace, and then publish the changes. Currently, saving >> is the only way to avoid risking losing changes, but it has the very >> undesired effect of inviting editors/vetters to the page before one is >> really done. >> >> We could also allow a time window (even 30 minutes) before edits went >> live after one is done editing (using above Ajax mechanism to track when >> editor open), experienced editors would not need to swoop in quite so fast >> on the work of new users, and the whole editing atmosphere would be more >> relaxed and welcoming. >> >> The fact is that the Wikipedia editor, with its lack of ability to save >> drafts, poor merging, and swooping editors, feels incredibly outdated and >> unwelcoming - downright aggressive - to anyone used to WordPress / Google >> Docs / Blogger / ... >> >> Luca >> >> > > The technology exists to do this---[[:en:Wikipedia:Flagged_revisions]]. > The challenge is that many existing users don't want flagged revisions on > by default. > > And that is the fundamental flaw with this whole email thread. The > question needing to be answered isn't "what increases new user retention". > The real question is "what increases new user retention and is acceptable > to the most active/helpful existing users". The second question is much > harder than the first. > > > > > ___ Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
Re: [Wiki-research-l] FW: What works for increasing editor engagement?
On Fri, Sep 26, 2014 at 5:14 AM, Luca de Alfaro wrote: > Better merging would be welcome. But also less aggressive > editing/policing. > > When I edit openstreetmap I have a better overall experience: the edits > may or may not go live immediately, but I don't have the impression that > there is someone aggressively vetting/refining my edits while I am still > doing them. I feel welcome there. > > To make Wikipedia more welcoming, we could do a few things. > > We could allow users to save drafts. In this way, people could work for a > while at their own pace, and then publish the changes. Currently, saving > is the only way to avoid risking losing changes, but it has the very > undesired effect of inviting editors/vetters to the page before one is > really done. > > We could also allow a time window (even 30 minutes) before edits went live > after one is done editing (using above Ajax mechanism to track when editor > open), experienced editors would not need to swoop in quite so fast on the > work of new users, and the whole editing atmosphere would be more relaxed > and welcoming. > > The fact is that the Wikipedia editor, with its lack of ability to save > drafts, poor merging, and swooping editors, feels incredibly outdated and > unwelcoming - downright aggressive - to anyone used to WordPress / Google > Docs / Blogger / ... > > Luca > > The technology exists to do this---[[:en:Wikipedia:Flagged_revisions]]. The challenge is that many existing users don't want flagged revisions on by default. And that is the fundamental flaw with this whole email thread. The question needing to be answered isn't "what increases new user retention". The real question is "what increases new user retention and is acceptable to the most active/helpful existing users". The second question is much harder than the first. ___ Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
Re: [Wiki-research-l] FW: What works for increasing editorengagement?
Australian outreach events generally edit Australian content. Other Australian editors are likely to be on the watch list and are likely to be in the timezone. And plenty of non-Australian editors are sitting in their pyjamas at all hours of the day and night waiting to pounce. Believe me, new editors encounter other editors very quickly (although sometimes they don't realise it). They often think it "rude" that other people are editing the article "while I am in the middle of working on it". Their mental model of collaborative editing is like a shared lawn mower. You have sole use for a while; then it is passed on to the next person. Not sure I can help you with London editathons. But I do have a couple of edit training days coming up in Oakey, Queensland in a few weeks: https://en.wikipedia.org/wiki/Oakey,_Queensland Kerry _ From: WereSpielChequers [mailto:werespielchequ...@gmail.com] Sent: Thursday, 25 September 2014 9:38 PM To: kerry.raym...@gmail.com; Research into Wikimedia content and communities Subject: Re: [Wiki-research-l] FW: What works for increasing editorengagement? Yes, training newbies is a great way to learn and to see the flaws that we mentally blank out. I also found that I need to keep a vanilla account for demonstrating things to newbies, if I use my WereSpielChequers account the various extra buttons confuse people. I wouldn't worry too much about watchlisters making edits and causing edit conflicts, most of the time you aren't going to be in the same time zone, watchlisters even the most active ones are unlikely to check their watch list more than a few times a day. So as long as you don't start newbies on highly watched articles like Sarah Palin you should be OK with them. But edit conflicts are a real problem for newbies and especially those creating new articles. The new page patrol people need to look at articles as they are created in order to pick up attack pages etc, and when they find OK articles they tend to at least categorise them. Some of this could be fixed by improving the software for handling edit conflicts, for example it would be nice if adding a category and changing some text were not treated as a conflict. However this is the sort of Bugzilla request that gets closed as won't fix because of the implicit assumption that any editor should be able to handle an edit conflict in their stride. My preferred solution is to teach newbies to always start new articles in sandboxes and move them to main space when they are ready, alternatively creating a references section means that categories can be added without causing an edit conflict. Re Pine's comment. When it comes to research topics It would be great to know how many editors are driven away by edit conflicts. But I don't know if that info is actually logged, and if you ask people why they gave up they don't necessarily know whether their edit conflict was with a machine or another editor. I once had to convince an angry editor that they hadn't been reverted by another editor, both edits had the same time stamp and theirs had been lost by the system without the other editor knowing. So if you ask former editors why they went and they blame other editors it may partly be that they don't know the difference between a conflict with the system and with another editor deliberately reverting them. By the way, if anyone is around in London drop me a line and I will tell you if we have any editathons going on. Editathons have many roles in the community, one being as a focus group on the user interface. Regards Jonathan Cardy On 25 Sep 2014, at 10:09, Kerry Raymond wrote: This pretty much matches my own observations. I think it's not uncommon for new editors to first write about something they know well, which often means some level of conflict of interest. But that doesn't necessarily mean the person is writing lies or being completely over-the-top with lavish praise; they can write quite reasonable content too. And generally new editors don't know that CoI editing isn't welcome. Similarly a lot get blocked for 3 reverts and get accused of edit warring, but I suspect it is often not the case. I suspect often they look back at the article and can't see the edit they did, so they just do it again because it didn't "stick". I am not convinced they do know that other people are reverting their edits because I don't think they know about the article history and the edit summaries and the user talk pages. We make some awfully big assumptions that new editors know what we do; it's amazing how much stuff in a UI you mentally filter out. I did a talk about Wikipedia about a year ago for a group of librarians. They asked for some "tips and tricks" to be included, so for the first time I systematically scanned the article UI and found cute little features I never knew were there (even on menus I often used). And of course the UI changes over time and probably
Re: [Wiki-research-l] FW: What works for increasing editor engagement?
Better merging would be welcome. But also less aggressive editing/policing. When I edit openstreetmap I have a better overall experience: the edits may or may not go live immediately, but I don't have the impression that there is someone aggressively vetting/refining my edits while I am still doing them. I feel welcome there. To make Wikipedia more welcoming, we could do a few things. We could allow users to save drafts. In this way, people could work for a while at their own pace, and then publish the changes. Currently, saving is the only way to avoid risking losing changes, but it has the very undesired effect of inviting editors/vetters to the page before one is really done. We could also allow a time window (even 30 minutes) before edits went live after one is done editing (using above Ajax mechanism to track when editor open), experienced editors would not need to swoop in quite so fast on the work of new users, and the whole editing atmosphere would be more relaxed and welcoming. The fact is that the Wikipedia editor, with its lack of ability to save drafts, poor merging, and swooping editors, feels incredibly outdated and unwelcoming - downright aggressive - to anyone used to WordPress / Google Docs / Blogger / ... Luca On Thu, Sep 25, 2014 at 12:35 PM, James Salsman wrote: > Luca wrote: > > > > Re. the edit conflicts happening when a new user is editing: > > > > Can't one add some AJAX to the editor that notifies that one > > still has the editing window open? Maybe editors could wait to > > modify work in progress, if they had that indication, and if the > > content does not seem vandalism? > > Instead of asking editors to wait, we could improve the merge > algorithm to avoid conflicts: > > https://en.wikipedia.org/wiki/Merge_(revision_control) > > ___ > Wiki-research-l mailing list > Wiki-research-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wiki-research-l > ___ Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
Re: [Wiki-research-l] FW: What works for increasing editor engagement?
Luca wrote: > > Re. the edit conflicts happening when a new user is editing: > > Can't one add some AJAX to the editor that notifies that one > still has the editing window open? Maybe editors could wait to > modify work in progress, if they had that indication, and if the > content does not seem vandalism? Instead of asking editors to wait, we could improve the merge algorithm to avoid conflicts: https://en.wikipedia.org/wiki/Merge_(revision_control) ___ Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
Re: [Wiki-research-l] FW: What works for increasing editor engagement?
Aaron, would you please post the script you used to create https://commons.wikimedia.org/wiki/File:Desirable_newcomer_survival_over_time.png ? I would be happy to modify it to also collect the number of extant non-redirect articles each desirable user created. > Aaron wrote: > >... You'll find the hand-coded set of users here > > http://datasets.wikimedia.org/public-datasets/enwiki/rise-and-decline > >... > > Categories: > > > > 1. Vandals - Purposefully malicious, out to cause harm > > 2. Bad-faith - Trying to be funny, not here to help or harm > > 3. Good-faith - Trying to be productive, but failing > > 4. Golden - Successfully contributing productively ___ Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
Re: [Wiki-research-l] FW: What works for increasing editor engagement?
Re. the edit conflicts happening when a new user is editing: Can't one add some AJAX to the editor that notifies that one still has the editing window open? Maybe editors could wait to modify work in progress, if they had that indication, and if the content does not seem vandalism? Luca On Thu, Sep 25, 2014 at 12:17 PM, James Salsman wrote: > Aaron, would you please post the script you used to create > > https://commons.wikimedia.org/wiki/File:Desirable_newcomer_survival_over_time.png > ? > > I would be happy to modify it to also collect the number of extant > non-redirect articles each desirable user created. > > > Aaron wrote: > > >... You'll find the hand-coded set of users here > > > http://datasets.wikimedia.org/public-datasets/enwiki/rise-and-decline > > >... > > > Categories: > > > > > > 1. Vandals - Purposefully malicious, out to cause harm > > > 2. Bad-faith - Trying to be funny, not here to help or harm > > > 3. Good-faith - Trying to be productive, but failing > > > 4. Golden - Successfully contributing productively > > ___ > Wiki-research-l mailing list > Wiki-research-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wiki-research-l > ___ Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
Re: [Wiki-research-l] FW: What works for increasing editorengagement?
Yes, training newbies is a great way to learn and to see the flaws that we mentally blank out. I also found that I need to keep a vanilla account for demonstrating things to newbies, if I use my WereSpielChequers account the various extra buttons confuse people. I wouldn't worry too much about watchlisters making edits and causing edit conflicts, most of the time you aren't going to be in the same time zone, watchlisters even the most active ones are unlikely to check their watch list more than a few times a day. So as long as you don't start newbies on highly watched articles like Sarah Palin you should be OK with them. But edit conflicts are a real problem for newbies and especially those creating new articles. The new page patrol people need to look at articles as they are created in order to pick up attack pages etc, and when they find OK articles they tend to at least categorise them. Some of this could be fixed by improving the software for handling edit conflicts, for example it would be nice if adding a category and changing some text were not treated as a conflict. However this is the sort of Bugzilla request that gets closed as won't fix because of the implicit assumption that any editor should be able to handle an edit conflict in their stride. My preferred solution is to teach newbies to always start new articles in sandboxes and move them to main space when they are ready, alternatively creating a references section means that categories can be added without causing an edit conflict. Re Pine's comment. When it comes to research topics It would be great to know how many editors are driven away by edit conflicts. But I don't know if that info is actually logged, and if you ask people why they gave up they don't necessarily know whether their edit conflict was with a machine or another editor. I once had to convince an angry editor that they hadn't been reverted by another editor, both edits had the same time stamp and theirs had been lost by the system without the other editor knowing. So if you ask former editors why they went and they blame other editors it may partly be that they don't know the difference between a conflict with the system and with another editor deliberately reverting them. By the way, if anyone is around in London drop me a line and I will tell you if we have any editathons going on. Editathons have many roles in the community, one being as a focus group on the user interface. Regards Jonathan Cardy > On 25 Sep 2014, at 10:09, Kerry Raymond wrote: > > This pretty much matches my own observations. > > I think it’s not uncommon for new editors to first write about something they > know well, which often means some level of conflict of interest. But that > doesn’t necessarily mean the person is writing lies or being completely > over-the-top with lavish praise; they can write quite reasonable content too. > And generally new editors don’t know that CoI editing isn’t welcome. > Similarly a lot get blocked for 3 reverts and get accused of edit warring, > but I suspect it is often not the case. I suspect often they look back at the > article and can’t see the edit they did, so they just do it again because it > didn’t “stick”. I am not convinced they do know that other people are > reverting their edits because I don’t think they know about the article > history and the edit summaries and the user talk pages. > > We make some awfully big assumptions that new editors know what we do; it’s > amazing how much stuff in a UI you mentally filter out. I did a talk about > Wikipedia about a year ago for a group of librarians. They asked for some > “tips and tricks” to be included, so for the first time I systematically > scanned the article UI and found cute little features I never knew were there > (even on menus I often used). And of course the UI changes over time and > probably I didn’t notice new things appear. But not noticing is consistent > with “mission focus”, which has been studied in retail settings. A customer > “on a mission” (a specific transaction that must be dealt with, as opposed to > a customer “just browsing”) is oblivious to promotions until the “mission” is > complete and then becomes aware of their surroundings as they turn to leave > the store (which tells you where to put promotional signs relative to your > “mission” products). I think Wikipedia editing is very mission-focussed (I > must fix that error) so we see nothing but what we want to see on the way in > and then have no “exit screen” to talk to the editor as they leave (unlike a > bricks-and-mortar retailer). It’s hard to communicate with new editors > on-wiki. > > I actually think doing a user experience experiment (ideally with eye > tracking) with new users would be very informative. Given them a “mission” > and watch what they look at, what they do and if they succeed in their task, > and whether their edits survives over t
Re: [Wiki-research-l] FW: What works for increasing editorengagement?
This is a great discussion. Kerry, I believe that Steven Walling and what was called the E3 team, now known as the Growth team, use eye tracking experiments. It would be interesting to hear about what they're learning, and tie those observations together with yours and WSC's. Also, I am happy to discuss the idea of teaming up with one or more people in this discussion to create an Individual Engagement Grant proposal that would help us to explore some of the material that we're discussing here. Aaron and I are already putting together a proposal related to how editors interact with each other, and I'd be happy to work on concurrent projects related to research on new editors if I can make the scheduling and financing work. Pine ___ Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
