Pursuant to prior discussions about the need for a research
policy on Wikipedia, WikiProject Research is drafting a
policy regarding the recruitment of Wikipedia users to
participate in studies.
At this time, we have a proposed policy, and an accompanying
group that would facilitate recruitment of subjects in much
the same way that the Bot Approvals Group approves bots.
The policy proposal can be found at:
http://en.wikipedia.org/wiki/Wikipedia:Research
The Subject Recruitment Approvals Group mentioned in the proposal
is being described at:
http://en.wikipedia.org/wiki/Wikipedia:Subject_Recruitment_Approvals_Group
Before we move forward with seeking approval from the Wikipedia
community, we would like additional input about the proposal,
and would welcome additional help improving it.
Also, please consider participating in WikiProject Research at:
http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Research
--
Bryan Song
GroupLens Research
University of Minnesota
Hi Valerio,
This kind of request is a better fit for the Research mailing list. I've
included the email for that list in the To: line of this email reply.
Pine
On Wed, Sep 10, 2014 at 4:15 AM, Valerio Schiavoni <
valerio.schiavoni(a)gmail.com> wrote:
> Dear WikiMedia foundation,
> in the context of a EU research project [1], we are interested in accessing
> wikipedia access traces.
> In the past, such traces were given for research purposes to other groups
> [2].
> Unfortunately, only a small percentage (10%) of that trace has been made
> made available (10%).
> We are interested in accessing the totality of that same trace (or even
> better, a more recent one, but the same one will do).
>
> If this is not the correct ML to use for such requests, could please anyone
> redirect me to correct one ?
>
> Thanks again for your attention,
>
> Valerio Schiavoni
> Post-Doc Researcher
> University of Neuchatel, Switzerland
>
>
> 1 - http://www.leads-project.eu
> 2 - http://www.wikibench.eu/?page_id=60
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
*Apologies for cross-posting*
Complete our survey for a chance to *win one of three Ipad minis*!
Only 1 day left!
---------------------------------------------------------------------
Hello instructors, teachers, faculty ...
If you use social media for one or more of your classes, we would like
to invite you to participate in an online survey. The survey should take
you no longer than 35 minutes to complete. This survey is being
conducted as part of a study on Social Media and Learning, supported by
the Social Sciences and Humanities Research Council (SSHRC) of Canada.
As a way to thank you for your participation in the survey, after
completion, you will be given the option to enter your name and email
address to enroll you in a random drawing to win one of three *Apple
iPad minis*! The random drawing will take place on October 1, 2014 and
the winner will be notified on the same day via email. Any optional
contact information provided cannot be connected to your survey responses.
If you would like to participate, please go to
http://tinyurl.com/SMlearningsurvey
--
Anatoliy Gruzd, PhD
Associate Professor, Ted Rogers School of Management
Director, Social Media Lab
Ryerson University
Address: Room 2-071 (8th floor), 55 Dundas St. West, Toronto, ON Canada
M5G 2C5,
Mailing Address: 350 Victoria Street, Toronto, ON, Canada M5B 2K3,
Email: gruzd(a)ryerson.ca
Twitter: @gruzd
Tel: 416-979-5000 ext. 7937
Lab: http://SocialMediaLab.ca
Homepage: http://AnatoliyGruzd.ca
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)
[Re-sending as it bounced first time.]
On 25 September 2014 22:45, Pine W <wiki.pine(a)gmail.com> wrote:
> 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.
>
Hey.
[This is a bit off-topic for wiki-research-l, but I've been asked to
answer.]
First things first: There aren't any plans right now to try to roll this
out any time soon.
Collaborative real-time editing is an interesting task in terms of
engineering, but an exceptional challenge in terms of product. I think that
it's reasonable to talk about it as a possible solution to issues, but the
number of problems it raises is so great that people should be careful to
not talk of it as some magic pixie dust. :-)
For a couple of brief examples:
If the objective is to prevent all edit conflicts by making parallel edits
them impossible, this means either:
* everyone has to use the collaborative editor;
* people who can't use the collaborative editor (e.g. old computer, slow
network, no JavaScript, etc.) can't edit at all;
* people who don't like the collaborative editor are unable to edit ever
again; and
* bots can't edit at all (because they can't react to prompts from other
users)
… or:
* you have to choose to use the collaborative editor for each edit (how do
newbies know, or is it opt-out somehow?)
* as soon as someone wants to edit an article collaboratively, everyone
else's edits die and they're told so (or they all have to wait for the
collaborative edit session to end and then manually resolve the edit
conflict);
* for people who can't or don't want to use the collaborative editor, and
all bots, the article is essentially locked from their editing until the
collaborative edit is finished.
Neither of these are great options.
If instead we're happy to keep having edit conflicts, we can allow
parallel edits, but then the benefit for newbies (and, frankly, the rest of
us) goes away the second your collaborative edit conflicts with a
non-collaborative edit. Whoops.
Say that we've decided on a course of action for the above, maybe by
biting the bullet and denying people with older computers *etc.* the
ability to edit (which I think would be sad and a dereliction of
our values); what do you do when there are too many parallel editors of an
article?
When you're editing in a real-time collaborative editor, that means you see
the edits of each of the participants, alongside their cursors/selections
and comments in the chat system if there is one (which there normally is).
When there's two or three of these, it's relatively easy to see what's
happening. But what if there are 1,000 people trying to edit the article at
once (e.g. the article of a very famous individual just after they've died
unexpectedly; think Michael Jackson or Robin Williams). Showing 1,000
cursors at once isn't just unhelpful – the level of traffic would probably
kill most users' browsers. Consequently, there needs to be a limit somehow
on the number of participants; maybe call it 10.
So, what happens when you click edit on an article where 10 people are
already editing?
* Do you just get told "tough"?
* Does the least-recently active editor get kicked out so you can join?
* Does this mean that all I need is 11 bots requesting to edit an article
to DoS it?
If you're a "special" user (e.g. a sysop), can you get into a collaborative
edit even if it's at the limit?
* If yes, doesn't this go against our values to place some editors above
others?
* If yes, do we just let the system "actually" cope with 11 not 10 editors,
or do we kick someone out?
* If no, how do we resolve the issues with too many editors locking an
article?
Then there are some really deep issues (more germane to this list) about
how article histories and revisions work, about the atomicity of edits and
the semantic concepts of saving, about blame maps vs. personal contribution
histories, about the concept of flagged revisions and suppressed edits,
about reversions and protected pages, and about legal matters such as
around multi-licensing and deleted edits.
The short answer is that it's a really interesting area of possibilities,
but we're going to want to work through a lot of these issues and come up
with an actual proposal about what this would mean.
Yours,
--
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.
jforrester(a)wikimedia.org | @jdforrester
--
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.
jforrester(a)wikimedia.org | @jdforrester
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" <luca(a)dealfaro.com> 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 <
werespielchequers(a)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 <luca(a)dealfaro.com> 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 <jsalsman(a)gmail.com>
> wrote:
>
>> Aaron, would you please post the script you used to create
>>
>> https://commons.wikimedia.org/wiki/File:Desirable_newcomer_survival_over_ti…
>> ?
>>
>> 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(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
Aaron, would you please post the script you used to create
https://commons.wikimedia.org/wiki/File:Desirable_newcomer_survival_over_ti…
?
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....
Thanks, Aaron, that is very helpful!
Do you also have data sets for number of still-extant non-redirect
articles created for the good-faith and golden users?
I can figure that out from the API, but I'm busy. Also, I have
previously hypothesized that creating an article is strongly
correlated with survival of desirable newcomers, and you probably have
people working for you who have no preconceived notions on the
question, or if you don't you can find them.
Best regards,
James Salsman
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....
_____
From: Kerry Raymond [mailto:kerry.raymond@gmail.com]
Sent: Tuesday, 16 September 2014 12:23 PM
To: Research into Wikimedia content and communities
Cc: Editor Engagement
Subject: Re: [Wiki-research-l] What works for increasing editor engagement?
With the mood bar, the communication back to the editor was through their user page and email (when known). Do you have any data to show where they saw it (or from where they responded to it)? I've long suspected that new users don't know about User Talk and this frustrates our efforts to communicate with them. so I would be interested to know if there was any difference in reaction from those communicated with via user talk alone and those who also got email and what that might say about user talk as a means to communicate with new users. I note that on the mobile interface running on my ipad, I cannot find a way to get to my User Talk page (as far as I can see), short of entering the URL manually or switching to the desktop interface, which makes user talk pretty useless way of communicating with mobile users.
Sent from my iPad
On 16 Sep 2014, at 6:02 am, Giovanni Luca Ciampaglia <gciampag(a)indiana.edu> wrote:
Hi Pine,
to answer your question on results about improving editor retention, there is a new paper authored by me and Dario coming out soon about MoodBar, an early EE experiment whose aim was to elicit feedback from newly registered editors, that shows that lightweight socialization (e.g. reporting feedback about editing experience and receiving help from more experienced users) improves long-term editor retention.
The pre-print of the paper is up on the arxiv http://arxiv.org/abs/1409.1496
I also gave a talk about it at the Mediawiki metrics meeting earlier this summer: https://www.youtube.com/watch?v=Rn4-cBYxttA
Cheers,
Giovanni Luca Ciampaglia
✎ 919 E 10th ∙ Bloomington 47408 IN ∙ USA
☞ http://www.glciampaglia.com/
✆ +1 812 855-7261
✉ gciampag(a)indiana.edu
2014-09-11 2:00 GMT-04:00 Pine W <wiki.pine(a)gmail.com>:
Hello research colleagues,
When I look at the WMF Report Card, it appears to me that the global active editor stats and the number of new accounts being registered per month has been relatively flat since at least 2011.
Those of you who work in EE research and analytics, I would like to ask if there is a summary of techniques that you have found that do produce statistically significant results in improving editor retention. I know that some of you write tools, design projects, or pull and analyze data about editors. It looks to me like WMF is investing significant effort in research and tool creation, but we're not moving the needle to create the results that we had hoped to achieve. So I'd like to ask what have we learned from all of our time working on editor engagement about techniques and programs that do improve the EE stats significant ways, so that we can hopefully accelerate the implementation of programs and techniques that have demonstrated success.
I'd also like to ask what barriers you think prevent us from becoming more effective at improving the number of users who register and the number of active editors. For example, are users who go through GettingStarted often being deterred by quickly being confronted by experienced editors in ways that make the newbies want to leave? If that is a significant problem, how do you suggest addressing this?
One of my concerns about investing further in developing Flow, analytics tools like like WIkimetrics, and further complex editor engagement research projects, is that the most important challenges related to editor engagement may be problems that can only be solved through primarily interpersonal and social means rather than the use of software tools and mass communications. I like Wikimetrics and I use it, and I think there's an important place for analytics and tool development in EE work, but I wonder if WMF should scale up the emphasis on grassroots social and interpersonal efforts, particularly in the context of the 2015+ Strategic Plan and Jimmy's speech at the 2014 Wikimania. What do you think,and if your answer is yes, how do you think WMF can do this while respecting the autonomy and social processes of the volunteer projects?
Thanks,
Pine
_______________________________________________
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
