On 27 Sep 2014, at 15:44, Gerard Meijssen
<gerard.meijssen(a)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(a)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_…
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(a)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-i…
On 26 September 2014 14:31, WereSpielChequers <werespielchequers(a)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(a)gmail.com> wrote:
On Fri, Sep 26, 2014 at 1:46 PM, WereSpielChequers <werespielchequers(a)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(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
_______________________________________________
Wiki-research-l mailing list
Wiki-research-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
_______________________________________________
Wiki-research-l mailing list
Wiki-research-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
_______________________________________________
Wiki-research-l mailing list
Wiki-research-l(a)lists.wikimedia.org