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:
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 jsalsman@gmail.com 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
On Fri, Sep 26, 2014 at 5:14 AM, Luca de Alfaro luca@dealfaro.com 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.
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 computermacgyver@gmail.com wrote:
On Fri, Sep 26, 2014 at 5:14 AM, Luca de Alfaro luca@dealfaro.com 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.
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 luca@dealfaro.com 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 computermacgyver@gmail.com wrote:
On Fri, Sep 26, 2014 at 5:14 AM, Luca de Alfaro luca@dealfaro.com 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.
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 computermacgyver@gmail.com 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 luca@dealfaro.com 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 computermacgyver@gmail.com wrote:
On Fri, Sep 26, 2014 at 5:14 AM, Luca de Alfaro luca@dealfaro.com 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.hale@oii.ox.ac.uk
I put a couple of interventions specifically targeting improving the new contributor experience here:
https://meta.wikimedia.org/wiki/Research_talk:New_editor_engagement_strategi...
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 luca@dealfaro.com 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 computermacgyver@gmail.com 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 luca@dealfaro.com 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 computermacgyver@gmail.com wrote:
On Fri, Sep 26, 2014 at 5:14 AM, Luca de Alfaro luca@dealfaro.com 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.hale@oii.ox.ac.uk
Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
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 computermacgyver@gmail.com 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 luca@dealfaro.com 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 computermacgyver@gmail.com wrote:
On Fri, Sep 26, 2014 at 5:14 AM, Luca de Alfaro luca@dealfaro.com 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.hale@oii.ox.ac.uk _______________________________________________ Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
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 < werespielchequers@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 computermacgyver@gmail.com 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 luca@dealfaro.com 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 computermacgyver@gmail.com wrote:
On Fri, Sep 26, 2014 at 5:14 AM, Luca de Alfaro luca@dealfaro.com 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.hale@oii.ox.ac.uk
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
On Fri, Sep 26, 2014 at 1:46 PM, WereSpielChequers < werespielchequers@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 computermacgyver@gmail.com 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.
Scott,
That's why the rest of my email focussed on things that we could that would improve editor retention and which would be uncontentious, but also there is a third question, are people's assumptions re newbie behaviour true? This is where research would be useful. Where the problem lies in mutually contradictory assumptions about user behaviour then the best way to break the logjam is with research, now I'm confident that the research will support my assumptions, but if I am wrong then I'm prepared to back solutions that I have previously opposed.
Regards
Jonathan Cardy
On 26 Sep 2014, at 09:56, Scott Hale computermacgyver@gmail.com wrote:
On Fri, Sep 26, 2014 at 1:46 PM, WereSpielChequers werespielchequers@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 computermacgyver@gmail.com 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
Hoi, Did you read this [1] the notion that bots are good for increasing the number of editors is contentious. However, numbers from the Swedish Wikipedia experience confirim exactly that bots are good. They not only increase the number of readers but also the number of editors.. <BIG GRIN> Thanks, GerardM
[1] http://ultimategerardm.blogspot.nl/2014/09/wikipedia-to-bot-or-not-to-bot-ii...
On 26 September 2014 14:31, WereSpielChequers werespielchequers@gmail.com wrote:
Scott,
That's why the rest of my email focussed on things that we could that would improve editor retention and which would be uncontentious, but also there is a third question, are people's assumptions re newbie behaviour true? This is where research would be useful. Where the problem lies in mutually contradictory assumptions about user behaviour then the best way to break the logjam is with research, now I'm confident that the research will support my assumptions, but if I am wrong then I'm prepared to back solutions that I have previously opposed.
Regards
Jonathan Cardy
On 26 Sep 2014, at 09:56, Scott Hale computermacgyver@gmail.com wrote:
On Fri, Sep 26, 2014 at 1:46 PM, WereSpielChequers < werespielchequers@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 computermacgyver@gmail.com 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
Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
I think the belief that bots cause editor attrition relates to the bots that "slap the editor in the face" by reverting, writing something critical on the user's talk page, etc. In the Swedish example, I gather the bots were creating new articles so they weren't beating up other editors but rather providing more articles for people to read and add to. I think it's the "beating up" that causes attrition. We have plenty of editors who are happy to beat up others, but bots can do it so much more systematically :-(
While it's not appropriate to characterise them as Good Bots and Bad Bots (as the "Bad Bots" do some genuinely useful things and save a lot of work for humans), it is perhaps reasonable to characterise them as "interacting" and "non-interacting" and take special care with the interacting ones in terms of "tone" and, in the spirit of WP:BITE, maybe what they do/say should be different when dealing with newbies.
The paper
http://wikipedia-academy.de/2012/w/images/f/f0/13_Paper_Maik_Anderka_Benno_S tein_Matthias_Busse.pdf
showed that article-wide tags like {{refimprove}} were less likely to be effective than specific inline tags like {{citation needed}}. It's more work to do {{cn}} (you actually have to read the article) than to say "doesn't look like enough references for an articles of that size" (which is the Wikipedia equivalent of assessing student's work by word count) and slap on a {{refimprove}}. It's no different to being at school and being told "it's not good enough, do it again", without saying how to do it better. You don't teach people that way (well, not effectively); you teach people by giving detailed feedback. Article for Creation has the same problem; the reviewers reject the article without detailed feedback. At present, the article creator makes some random changes, crosses their fingers and resubmits, and usually gets rejected again by a different reviewer often for a different reason. Eventually the article creator gives up and then we delete the draft some months later. We are the on-line experts at chewing people up and spitting them out. Who decides how AfC works? It's established community members who don't create articles through AfC, and the new editors who do create articles via AfC only get their "say" by the one method at their disposal, they give up and walk away. Hmm, reminds me of
https://en.wikipedia.org/wiki/No_taxation_without_representation
and look where that ended (given the international readership of this list, I'll reserve judgement on whether or not it was a good outcome :-) )
Personally I think we should look for the simple interventions and experiment with them and see if they can turn around editor attrition before we look to the complex interventions (like the fully collaborative editing environment). It might be far simpler for watchlists to show a couple of things (I'll leave the specifics to the UX people) 1) that one of the editors since your last visit is a newbie (maybe this could show in the relevant entry in the edit history too) and 2) that the last edit was very recent, suggesting the possibility that someone may be currently editing it (and hence more likely to create edit conflicts if you go in). I don't how if it is a simple matter to show that the page is current open for edit (I suspect not, but don't know the internals of the code), but if it was easy, that would be an even better thing to signal. We don't need to change how things work; it might be sufficient to just give clearer signals about what's going on.
I note that this process of signalling is the key to highly scalable insect behaviour (e.g. ants, termites, bees etc), aka stigmergy. Maybe we should try a little stigmergy in Wikipedia. Don't change how things work, just provide humans (and bots) with better information about the situation and hope they respond more appropriately.
Kerry
_____
From: wiki-research-l-bounces@lists.wikimedia.org [mailto:wiki-research-l-bounces@lists.wikimedia.org] On Behalf Of Gerard Meijssen Sent: Saturday, 27 September 2014 5:48 AM To: Research into Wikimedia content and communities Subject: Re: [Wiki-research-l] FW: What works for increasing editorengagement?
Hoi,
Did you read this [1] the notion that bots are good for increasing the number of editors is contentious. However, numbers from the Swedish Wikipedia experience confirim exactly that bots are good. They not only increase the number of readers but also the number of editors.. <BIG GRIN>
Thanks,
GerardM
[1] http://ultimategerardm.blogspot.nl/2014/09/wikipedia-to-bot-or-not-to-bot-ii .html
On 26 September 2014 14:31, WereSpielChequers werespielchequers@gmail.com wrote:
Scott,
That's why the rest of my email focussed on things that we could that would improve editor retention and which would be uncontentious, but also there is a third question, are people's assumptions re newbie behaviour true? This is where research would be useful. Where the problem lies in mutually contradictory assumptions about user behaviour then the best way to break the logjam is with research, now I'm confident that the research will support my assumptions, but if I am wrong then I'm prepared to back solutions that I have previously opposed.
Regards
Jonathan Cardy
On 26 Sep 2014, at 09:56, Scott Hale computermacgyver@gmail.com wrote:
On Fri, Sep 26, 2014 at 1:46 PM, WereSpielChequers werespielchequers@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 computermacgyver@gmail.com 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
_______________________________________________ Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
Hoi, It is a widely held belief that bots that create articles are bad. It is believed that they prevent people from writing new articles. It is why several projects prohibit the use of bots for the creation of new articles. The German Wikipedia is a great example at that.
Yes there are the "social" bots. I am happy that I do no know about them at all.
Thanks, GerardM
On 27 September 2014 11:01, Kerry Raymond kerry.raymond@gmail.com wrote:
I think the belief that bots cause editor attrition relates to the bots that “slap the editor in the face” by reverting, writing something critical on the user’s talk page, etc. In the Swedish example, I gather the bots were creating new articles so they weren’t beating up other editors but rather providing more articles for people to read and add to. I think it’s the “beating up” that causes attrition. We have plenty of editors who are happy to beat up others, but bots can do it so much more systematically L
While it’s not appropriate to characterise them as Good Bots and Bad Bots (as the “Bad Bots” do some genuinely useful things and save a lot of work for humans), it is perhaps reasonable to characterise them as “interacting” and “non-interacting” and take special care with the interacting ones in terms of “tone” and, in the spirit of WP:BITE, maybe what they do/say should be different when dealing with newbies.
The paper
http://wikipedia-academy.de/2012/w/images/f/f0/13_Paper_Maik_Anderka_Benno_S...
showed that article-wide tags like {{refimprove}} were less likely to be effective than specific inline tags like {{citation needed}}. It’s more work to do {{cn}} (you actually have to read the article) than to say “doesn’t look like enough references for an articles of that size” (which is the Wikipedia equivalent of assessing student’s work by word count) and slap on a {{refimprove}}. It’s no different to being at school and being told “it’s not good enough, do it again”, without saying how to do it better. You don’t teach people that way (well, not effectively); you teach people by giving detailed feedback. Article for Creation has the same problem; the reviewers reject the article without detailed feedback. At present, the article creator makes some random changes, crosses their fingers and resubmits, and usually gets rejected again by a different reviewer often for a different reason. Eventually the article creator gives up and then we delete the draft some months later. We are the on-line experts at chewing people up and spitting them out. Who decides how AfC works? It’s established community members who don’t create articles through AfC, and the new editors who do create articles via AfC only get their “say” by the one method at their disposal, they give up and walk away. Hmm, reminds me of
https://en.wikipedia.org/wiki/No_taxation_without_representation
and look where that ended (given the international readership of this list, I’ll reserve judgement on whether or not it was a good outcome J )
Personally I think we should look for the simple interventions and experiment with them and see if they can turn around editor attrition before we look to the complex interventions (like the fully collaborative editing environment). It might be far simpler for watchlists to show a couple of things (I’ll leave the specifics to the UX people) 1) that one of the editors since your last visit is a newbie (maybe this could show in the relevant entry in the edit history too) and 2) that the last edit was very recent, suggesting the possibility that someone may be currently editing it (and hence more likely to create edit conflicts if you go in). I don’t how if it is a simple matter to show that the page is current open for edit (I suspect not, but don’t know the internals of the code), but if it was easy, that would be an even better thing to signal. We don’t need to change how things work; it might be sufficient to just give clearer signals about what’s going on.
I note that this process of signalling is the key to highly scalable insect behaviour (e.g. ants, termites, bees etc), aka stigmergy. Maybe we should try a little stigmergy in Wikipedia. Don’t change how things work, just provide humans (and bots) with better information about the situation and hope they respond more appropriately.
Kerry
*From:* wiki-research-l-bounces@lists.wikimedia.org [mailto: wiki-research-l-bounces@lists.wikimedia.org] *On Behalf Of *Gerard Meijssen *Sent:* Saturday, 27 September 2014 5:48 AM *To:* Research into Wikimedia content and communities *Subject:* Re: [Wiki-research-l] FW: What works for increasing editorengagement?
Hoi,
Did you read this [1] the notion that bots are good for increasing the number of editors is contentious. However, numbers from the Swedish Wikipedia experience confirim exactly that bots are good. They not only increase the number of readers but also the number of editors.. <BIG GRIN>
Thanks,
GerardM[1] http://ultimategerardm.blogspot.nl/2014/09/wikipedia-to-bot-or-not-to-bot-ii...
On 26 September 2014 14:31, WereSpielChequers werespielchequers@gmail.com wrote:
Scott,
That's why the rest of my email focussed on things that we could that would improve editor retention and which would be uncontentious, but also there is a third question, are people's assumptions re newbie behaviour true? This is where research would be useful. Where the problem lies in mutually contradictory assumptions about user behaviour then the best way to break the logjam is with research, now I'm confident that the research will support my assumptions, but if I am wrong then I'm prepared to back solutions that I have previously opposed.
Regards
Jonathan Cardy
On 26 Sep 2014, at 09:56, Scott Hale computermacgyver@gmail.com wrote:
On Fri, Sep 26, 2014 at 1:46 PM, WereSpielChequers < werespielchequers@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 computermacgyver@gmail.com 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
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
I wouldn't say it is a widely held belief that bot creation of articles is bad. I'd rather say that it is one of the shibboleths of extreme deletionism that bot creation of articles is a bad thing. There are plenty of people who think that when done well it is very valuable.
As for the good v bad bots, I doubt that anyone objects to the bots that add the date when people add citation needed. I appreciate that I don't have to worry about that or about adding the padlock symbol to pages I semi protect - there are bots that do that for me. One can also assume that those people who have set up their talk page to take advantage of archiving bots do so because they like such bots, when one of the archiving bots stopped working a while back there were people looking to revive or replace, not celebrating its demise.
My hypothesis is that people who have ticked the watchlist option to ignore bot edits are much more tolerant of them than those who haven't, though I wonder how one could tease out cause and effect here .
But going back to Kerry's point about bots that "that “slap the editor in the face” by reverting, writing something critical on the user’s talk page, etc". I wonder what people make of bracket bot and disambig bot? In theory changing such bots to notifications should make the wiki a nicer place as these are precisely the sort of things where people appreciate a one to one word but resent a public rebuke. Of course doing so would lose us another chunk of edits and thereby feed the "raw edit count is falling" meme. But it would be a great opportunity for research, especially if we did an A/B trial for a few months using notification for half the community and bots for the other half. Notification has the drawback that you only see it when you log on for that account, and it isn't seen by the people who watchlist your user page. So you would lose the edits done by those who tidy up after wiki friends. Hence the need for research and ultimately perhaps a preference or linked account system.
Regards
Jonathan Cardy
On 27 Sep 2014, at 15:44, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, It is a widely held belief that bots that create articles are bad. It is believed that they prevent people from writing new articles. It is why several projects prohibit the use of bots for the creation of new articles. The German Wikipedia is a great example at that.
Yes there are the "social" bots. I am happy that I do no know about them at all.
Thanks, GerardM
On 27 September 2014 11:01, Kerry Raymond kerry.raymond@gmail.com wrote: I think the belief that bots cause editor attrition relates to the bots that “slap the editor in the face” by reverting, writing something critical on the user’s talk page, etc. In the Swedish example, I gather the bots were creating new articles so they weren’t beating up other editors but rather providing more articles for people to read and add to. I think it’s the “beating up” that causes attrition. We have plenty of editors who are happy to beat up others, but bots can do it so much more systematically L
While it’s not appropriate to characterise them as Good Bots and Bad Bots (as the “Bad Bots” do some genuinely useful things and save a lot of work for humans), it is perhaps reasonable to characterise them as “interacting” and “non-interacting” and take special care with the interacting ones in terms of “tone” and, in the spirit of WP:BITE, maybe what they do/say should be different when dealing with newbies.
The paper
http://wikipedia-academy.de/2012/w/images/f/f0/13_Paper_Maik_Anderka_Benno_S...
showed that article-wide tags like {{refimprove}} were less likely to be effective than specific inline tags like {{citation needed}}. It’s more work to do {{cn}} (you actually have to read the article) than to say “doesn’t look like enough references for an articles of that size” (which is the Wikipedia equivalent of assessing student’s work by word count) and slap on a {{refimprove}}. It’s no different to being at school and being told “it’s not good enough, do it again”, without saying how to do it better. You don’t teach people that way (well, not effectively); you teach people by giving detailed feedback. Article for Creation has the same problem; the reviewers reject the article without detailed feedback. At present, the article creator makes some random changes, crosses their fingers and resubmits, and usually gets rejected again by a different reviewer often for a different reason. Eventually the article creator gives up and then we delete the draft some months later. We are the on-line experts at chewing people up and spitting them out. Who decides how AfC works? It’s established community members who don’t create articles through AfC, and the new editors who do create articles via AfC only get their “say” by the one method at their disposal, they give up and walk away. Hmm, reminds me of
https://en.wikipedia.org/wiki/No_taxation_without_representation
and look where that ended (given the international readership of this list, I’ll reserve judgement on whether or not it was a good outcome J )
Personally I think we should look for the simple interventions and experiment with them and see if they can turn around editor attrition before we look to the complex interventions (like the fully collaborative editing environment). It might be far simpler for watchlists to show a couple of things (I’ll leave the specifics to the UX people) 1) that one of the editors since your last visit is a newbie (maybe this could show in the relevant entry in the edit history too) and 2) that the last edit was very recent, suggesting the possibility that someone may be currently editing it (and hence more likely to create edit conflicts if you go in). I don’t how if it is a simple matter to show that the page is current open for edit (I suspect not, but don’t know the internals of the code), but if it was easy, that would be an even better thing to signal. We don’t need to change how things work; it might be sufficient to just give clearer signals about what’s going on.
I note that this process of signalling is the key to highly scalable insect behaviour (e.g. ants, termites, bees etc), aka stigmergy. Maybe we should try a little stigmergy in Wikipedia. Don’t change how things work, just provide humans (and bots) with better information about the situation and hope they respond more appropriately.
Kerry
From: wiki-research-l-bounces@lists.wikimedia.org [mailto:wiki-research-l-bounces@lists.wikimedia.org] On Behalf Of Gerard Meijssen Sent: Saturday, 27 September 2014 5:48 AM To: Research into Wikimedia content and communities Subject: Re: [Wiki-research-l] FW: What works for increasing editorengagement?
Hoi,
Did you read this [1] the notion that bots are good for increasing the number of editors is contentious. However, numbers from the Swedish Wikipedia experience confirim exactly that bots are good. They not only increase the number of readers but also the number of editors.. <BIG GRIN>
Thanks,
GerardM[1] http://ultimategerardm.blogspot.nl/2014/09/wikipedia-to-bot-or-not-to-bot-ii...
On 26 September 2014 14:31, WereSpielChequers werespielchequers@gmail.com wrote:
Scott,
That's why the rest of my email focussed on things that we could that would improve editor retention and which would be uncontentious, but also there is a third question, are people's assumptions re newbie behaviour true? This is where research would be useful. Where the problem lies in mutually contradictory assumptions about user behaviour then the best way to break the logjam is with research, now I'm confident that the research will support my assumptions, but if I am wrong then I'm prepared to back solutions that I have previously opposed.
Regards
Jonathan Cardy
On 26 Sep 2014, at 09:56, Scott Hale computermacgyver@gmail.com wrote:
On Fri, Sep 26, 2014 at 1:46 PM, WereSpielChequers werespielchequers@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 computermacgyver@gmail.com 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
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
I don't see these as a personal rebuke when I get them, and they are worded quite gently, But they still inevitably share the same perception as all templates--but they are hardly the sort of thing that really needs a truly personal notice. I think notifications might be the ideal solution. We have a good system there with notifications, and we shoudl use it. Have you proposed it at the VP yet?
On Sun, Sep 28, 2014 at 3:53 AM, WereSpielChequers < werespielchequers@gmail.com> wrote:
I wouldn't say it is a widely held belief that bot creation of articles is bad. I'd rather say that it is one of the shibboleths of extreme deletionism that bot creation of articles is a bad thing. There are plenty of people who think that when done well it is very valuable.
As for the good v bad bots, I doubt that anyone objects to the bots that add the date when people add citation needed. I appreciate that I don't have to worry about that or about adding the padlock symbol to pages I semi protect - there are bots that do that for me. One can also assume that those people who have set up their talk page to take advantage of archiving bots do so because they like such bots, when one of the archiving bots stopped working a while back there were people looking to revive or replace, not celebrating its demise.
My hypothesis is that people who have ticked the watchlist option to ignore bot edits are much more tolerant of them than those who haven't, though I wonder how one could tease out cause and effect here .
But going back to Kerry's point about bots that "that “slap the editor in the face” by reverting, writing something critical on the user’s talk page, etc". I wonder what people make of bracket bot and disambig bot? In theory changing such bots to notifications should make the wiki a nicer place as these are precisely the sort of things where people appreciate a one to one word but resent a public rebuke. Of course doing so would lose us another chunk of edits and thereby feed the "raw edit count is falling" meme. But it would be a great opportunity for research, especially if we did an A/B trial for a few months using notification for half the community and bots for the other half. Notification has the drawback that you only see it when you log on for that account, and it isn't seen by the people who watchlist your user page. So you would lose the edits done by those who tidy up after wiki friends. Hence the need for research and ultimately perhaps a preference or linked account system.
Regards
Jonathan Cardy
On 27 Sep 2014, at 15:44, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, It is a widely held belief that bots that create articles are bad. It is believed that they prevent people from writing new articles. It is why several projects prohibit the use of bots for the creation of new articles. The German Wikipedia is a great example at that.
Yes there are the "social" bots. I am happy that I do no know about them at all.
Thanks, GerardM
On 27 September 2014 11:01, Kerry Raymond kerry.raymond@gmail.com wrote:
I think the belief that bots cause editor attrition relates to the bots that “slap the editor in the face” by reverting, writing something critical on the user’s talk page, etc. In the Swedish example, I gather the bots were creating new articles so they weren’t beating up other editors but rather providing more articles for people to read and add to. I think it’s the “beating up” that causes attrition. We have plenty of editors who are happy to beat up others, but bots can do it so much more systematically L
While it’s not appropriate to characterise them as Good Bots and Bad Bots (as the “Bad Bots” do some genuinely useful things and save a lot of work for humans), it is perhaps reasonable to characterise them as “interacting” and “non-interacting” and take special care with the interacting ones in terms of “tone” and, in the spirit of WP:BITE, maybe what they do/say should be different when dealing with newbies.
The paper
http://wikipedia-academy.de/2012/w/images/f/f0/13_Paper_Maik_Anderka_Benno_S...
showed that article-wide tags like {{refimprove}} were less likely to be effective than specific inline tags like {{citation needed}}. It’s more work to do {{cn}} (you actually have to read the article) than to say “doesn’t look like enough references for an articles of that size” (which is the Wikipedia equivalent of assessing student’s work by word count) and slap on a {{refimprove}}. It’s no different to being at school and being told “it’s not good enough, do it again”, without saying how to do it better. You don’t teach people that way (well, not effectively); you teach people by giving detailed feedback. Article for Creation has the same problem; the reviewers reject the article without detailed feedback. At present, the article creator makes some random changes, crosses their fingers and resubmits, and usually gets rejected again by a different reviewer often for a different reason. Eventually the article creator gives up and then we delete the draft some months later. We are the on-line experts at chewing people up and spitting them out. Who decides how AfC works? It’s established community members who don’t create articles through AfC, and the new editors who do create articles via AfC only get their “say” by the one method at their disposal, they give up and walk away. Hmm, reminds me of
https://en.wikipedia.org/wiki/No_taxation_without_representation
and look where that ended (given the international readership of this list, I’ll reserve judgement on whether or not it was a good outcome J )
Personally I think we should look for the simple interventions and experiment with them and see if they can turn around editor attrition before we look to the complex interventions (like the fully collaborative editing environment). It might be far simpler for watchlists to show a couple of things (I’ll leave the specifics to the UX people) 1) that one of the editors since your last visit is a newbie (maybe this could show in the relevant entry in the edit history too) and 2) that the last edit was very recent, suggesting the possibility that someone may be currently editing it (and hence more likely to create edit conflicts if you go in). I don’t how if it is a simple matter to show that the page is current open for edit (I suspect not, but don’t know the internals of the code), but if it was easy, that would be an even better thing to signal. We don’t need to change how things work; it might be sufficient to just give clearer signals about what’s going on.
I note that this process of signalling is the key to highly scalable insect behaviour (e.g. ants, termites, bees etc), aka stigmergy. Maybe we should try a little stigmergy in Wikipedia. Don’t change how things work, just provide humans (and bots) with better information about the situation and hope they respond more appropriately.
Kerry
*From:* wiki-research-l-bounces@lists.wikimedia.org [mailto: wiki-research-l-bounces@lists.wikimedia.org] *On Behalf Of *Gerard Meijssen *Sent:* Saturday, 27 September 2014 5:48 AM *To:* Research into Wikimedia content and communities *Subject:* Re: [Wiki-research-l] FW: What works for increasing editorengagement?
Hoi,
Did you read this [1] the notion that bots are good for increasing the number of editors is contentious. However, numbers from the Swedish Wikipedia experience confirim exactly that bots are good. They not only increase the number of readers but also the number of editors.. <BIG GRIN>
Thanks,
GerardM[1] http://ultimategerardm.blogspot.nl/2014/09/wikipedia-to-bot-or-not-to-bot-ii...
On 26 September 2014 14:31, WereSpielChequers < werespielchequers@gmail.com> wrote:
Scott,
That's why the rest of my email focussed on things that we could that would improve editor retention and which would be uncontentious, but also there is a third question, are people's assumptions re newbie behaviour true? This is where research would be useful. Where the problem lies in mutually contradictory assumptions about user behaviour then the best way to break the logjam is with research, now I'm confident that the research will support my assumptions, but if I am wrong then I'm prepared to back solutions that I have previously opposed.
Regards
Jonathan Cardy
On 26 Sep 2014, at 09:56, Scott Hale computermacgyver@gmail.com wrote:
On Fri, Sep 26, 2014 at 1:46 PM, WereSpielChequers < werespielchequers@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 computermacgyver@gmail.com 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
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
wiki-research-l@lists.wikimedia.org