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.meijs...@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.raym...@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_Stein_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 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-boun...@lists.wikimedia.org >> [mailto:wiki-research-l-boun...@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 <werespielchequ...@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 <computermacgy...@gmail.com> wrote: >>> >>> >>> 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 <computermacgy...@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
