Re: [Wiki-research-l] Gaps

[Leila Zia]

On Thu, Feb 8, 2018 at 8:56 PM, Kerry Raymond  wrote:
> I think we can't address content gaps unless we also address contributor gaps.

This is very important. We very likely have reader/consumer gaps, (for
sure) content gaps, and contributor gaps and these gaps are connected
to each other in ways that we need to much better understand.

Leila

___
Wiki-research-l mailing list
Wiki-research-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wiki-research-l

Re: [Wiki-research-l] Gaps

[Kerry Raymond]

I think there are two parts to the problem of filling gaps. Drawing attention 
to the gaps is half of the problem. The other half of the problem is finding 
the editor who wants to write that article. For example, I often check on the 
"missing topics" list for WikiProject Queensland (which is machine-generated by 
counting the number of redlinks in articles tagged on the Talk page as 
belonging to that project).

https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Queensland/Missing_topics

This is not a highly sophisticated algorithm but it does result in my thinking 
"oh well, I am sure I could at least write a stub on that topic" and so I write 
an article. 

But if you look at the first couple of screens of those "most missing" topics, 
there are lots of racing car drivers. I have no interest whatsoever in racing 
car drivers, I have no idea what sources might exist or which might be 
reliable. So as I pick off other topics from the "most missing" list, it has 
the effect of increasing the density of racing car drivers at the top of the 
list. Clearly we have a content gap around racing car drivers, but I won't be 
doing anything about it.

This reinforces the point Leila makes about personalising the recommendations. 
I think it's more important to target the right people even if the list you 
present to them isn't overly sophisticated. The right person will be able to 
mentally filter a list of things vaguely associated with their topic interests. 
As Leila says, there's probably less benefit in targeting new users to write 
new articles. But I've started over 4000 articles and I bet 90% are WikiProject 
Queensland. Show me any list of wanted Queensland topics and I'll probably be 
willing to write about *many * of them (but not all). Similarly if you look at 
the categories of the articles I write, the category Queensland Heritage 
Register will come up a lot (probably 1/3 of my articles are about heritage 
properties). Probably another 1/3 are articles about Queensland 
towns/suburbs/localities. I think looking at the categories/projects of the 
articles people write is a very strong indicator of interest areas. And the 
more articles they write, the more sure you can be that they are confident 
about starting new articles (a lot of people are not willing to start new 
articles but will happily contribute to a stub -- probably had a past bad 
experience with article creation) and the more you can be sure about their 
areas of interest.

With the exception of redirects and disambiguation pages, I would think anyone 
who has started many articles is likely to have easily-inferred topic space 
interests. For that matter, a lot of people (myself included) talk about their 
interest areas on their user page, so key words in user pages that fuzzy-match 
to project names or category names may be another indicator.

However, some of the content gaps on Wikipedia exist because we don't have 
contributors who are interested in the topic. Given that there is a known 
difference between the topics that women generally write about compared to men, 
it's clear that a lack of diversity in editors is likely to lead to content 
gaps. I would suspect the same is true about other personal characteristics. As 
an Australian, I am more likely to write about Australian than say Greenland, 
but I did holiday there last year, so actually I have written a little about 
Greenland and uploaded some photos, but that's just a "blip" in my contribution 
profile (and I don't think I started any new articles about Greenland). If we 
have a content gap about Greenland, maybe we don't have enough Greenlanders to 
fill it? I think we can't address content gaps unless we also address 
contributor gaps. This in turn may result in devolving responsibility for 
things like notability and verifiability down to the Project level. For 
example, it is often commented that Indigenous Australian topics are a content 
gap. The problem is a lack of sources. Indigenous Australians did not have a 
written language so oral sources are very important, but en.Wikipedia isn't 
keen on oral sources, so there's a content gap that's hard to fill. And I 
suspect we have very few Indigenous Australians writing for Wikipedia. 
Statistically 3% of our population self-identifies as Indigenous but they tend 
to have lower educational attainments which probably makes them less likely to 
be Wikipedia contributors who, based on the 2011 survey, have above average 
likelihood of having a university degree. 

So I think we have two flavours of content gap, those for which we have active 
contributors in the broader topic space who may be enticed to write about the 
missing topics (which is the problem being principally addressed by this area 
of research), and those where we do not have active contributors.

Kerry





___
Wiki-research-l mailing list
Wiki-research-l@lists.wikimedia.org
https://lists.wikimedia.org/mail

Re: [Wiki-research-l] Gaps

[Leila Zia]

Hi Heather,

Thanks for writing. Below are some of my thoughts.

* Whether automatic recommendations work rely heavily on at least a
few factors: the users who interact with these recommendations and
their level of expertise with editing Wikimedia projects, the quality
of the recommendations, how much context is provided as part of the
recommendations, incentives, and the design of the platform/tool/etc.
where these recommendations get surfaced. The last point is something
very critical. Design is key in this context.

* We've had some good success stories with recommendations. As you
have seen, the work we did in 2015 shows that you can significantly
increase article creation rate (factor of 3.2 without loss in quality)
if you do personalized recommendations.[0] Obviously, creation of an
article is a task suited more towards the more experienced editors as
newcomers. Had we done a similar experiment with newcomers, my gut
feeling is that we would have seen a very different result. We also
build a recommendation API [1] that is now being used in Content
Translation for editors to receive Suggestions on what to edit next.
We could see a spike of increase in contributions in the tool after
this feature was introduced. somewhere between 8-15% of the
contributions through the tool come thanks to the recommendations
today.[2] There are other success stories around as well. For example,
Ma Commune [3] focuses on helping French Wikipedia editors expand the
already existing articles (specific and limited types of articles for
now). Recommendations have also worked really well in the context of
Wikidata, where contributions can be made through games such as The
Distributed Game [4].

* Specifically about the work we do in knowledge gaps, we're at the
moment very much focused on the realm of machine in the loop (as
opposed to human in the loop) [5]. By this I mean: our aim is to
understand what humans are trying to do on Wikimedia projects and
bring in machines/algorithms to do what they want to do more
easily/efficiently, with least frustration and pain. An example of
this approach was when we interviewed a couple of editathon organizers
in Africa as part of The Africa Destubathon and learned that they were
doing a lot of manual work extracting structures of articles to create
templates for newcomers to learn how to expand an already existing
article. That's when we became sure that investing on section
recommendations actually makes sense (later we learned we can help
other projects such as Ma Commune, too, which is great.)

* More recently, Contributors team conducted a research study to
understand the needs of Wikipedia editors through in-person interviews
with editors. The focus areas coming out of this research [6] suggest
that proving in-context help and task recommendations are important.

I hope these pointers help. I know we will talk about these more when
we talk next, but if you or others have questions or comments in the
mean time, I'd be happy to expand. Just be aware that it's annual
planning time around here and we may be slow in responding. :)

Best,
Leila

[0] https://arxiv.org/abs/1604.03235
[1] https://www.mediawiki.org/wiki/GapFinder/Developers
[2] These numbers are a few months old, I need to get updates. :)
[3] https://macommune.wikipedia.fr/
[4] http://magnusmanske.de/wordpress/?p=362
[5] Borrowing the term from Ricardo Baeza-Yates.
[6] https://www.mediawiki.org/wiki/New_Editor_Experiences#Focuses

--
Leila Zia
Senior Research Scientist
Wikimedia Foundation


On Thu, Feb 8, 2018 at 7:03 PM, Heather Ford  wrote:
> Having a look at the new WMF research site, I noticed that it seems that
> notification and recommendations mechanisms are the key strategy being
> focused on re. the filling of Wikipedia's content gaps. Having just
> finished a research project on just this problem and coming to the opposite
> conclusion i.e. that automated mechanisms were insufficient for solving the
> gaps problem, I was curious to find out more.
>
> This latest research that I was involved in with colleagues was based on an
> action research project aiming to fill gaps in topics relating to South
> Africa. The team tried a range of different strategies discussed in the
> literature for filling Wikipedia's gaps without any wild success. Automated
> mechanisms that featured missing and incomplete articles catalysed very few
> edits.
>
> When looking for related research, it seemed that others had come to a
> similar conclusion i.e. that automated notification/recommendations alone
> didn't lead to improvements in particular target areas. That makes me think
> that a) I just haven't come across the right research or b) that there are
> different types of gaps and that those different types require different
> solutions i.e. the difference between filling gaps across language
> versions, gaps created by incomplete articles about topics for which there
> are few online/reliable sources is different from the lack of ar

[Wiki-research-l] Gaps

[Heather Ford]

Having a look at the new WMF research site, I noticed that it seems that
notification and recommendations mechanisms are the key strategy being
focused on re. the filling of Wikipedia's content gaps. Having just
finished a research project on just this problem and coming to the opposite
conclusion i.e. that automated mechanisms were insufficient for solving the
gaps problem, I was curious to find out more.

This latest research that I was involved in with colleagues was based on an
action research project aiming to fill gaps in topics relating to South
Africa. The team tried a range of different strategies discussed in the
literature for filling Wikipedia's gaps without any wild success. Automated
mechanisms that featured missing and incomplete articles catalysed very few
edits.

When looking for related research, it seemed that others had come to a
similar conclusion i.e. that automated notification/recommendations alone
didn't lead to improvements in particular target areas. That makes me think
that a) I just haven't come across the right research or b) that there are
different types of gaps and that those different types require different
solutions i.e. the difference between filling gaps across language
versions, gaps created by incomplete articles about topics for which there
are few online/reliable sources is different from the lack of articles
about topics for which there are many online/reliable sources, gaps in
articles about particular topics, relating to particular geographic areas
etc.

Does anyone have any insight here? - either on research that would help
practitioners decide how to go about a project of filling gaps in a
particular subject area or about whether the key focus of research at the
WMF is on filling gaps via automated means such as recommendation and
notification mechanisms?

Many thanks!

Best,
Heather.
___
Wiki-research-l mailing list
Wiki-research-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wiki-research-l

Re: [Wiki-research-l] [Analytics] A new landing page for the Wikimedia Research team

[Jonathan Morgan]

Quick heads up that there's now a Phab tag[1] for the landing page. Please
feel free to use this tag to document issues and feature requests.

Thanks,
Jonathan

1. https://phabricator.wikimedia.org/project/profile/3243/

On Thu, Feb 8, 2018 at 8:46 AM, Jonathan Morgan 
wrote:

> Aaron: I'll ask Baha about the issue tracking... *issue* today. The code
> is hosted on Gerrit now, with a one-way mirror on this GitHub repo[1],
> which is not ideal from an openness/collaboration POV. For me, enabling
> easy issue tracking and pull requests is the most pressing issue. In the
> meantime, you can submit tasks through Phab. Add them to the Research
> board[2] and/or as subtasks of our Landing Page creation epic[3]. Not
> ideal, but at least you can capture things this way.
>
> Federico: Translation via translatewiki would be very cool. We haven't
> prioritized this because, well, none of our on-wiki research team pages
> were ever translated, and this microsite is intended to supplement our
> on-wiki content, not replace it. But it sounds like a potential 'roadmap'
> kinda deal and I'll make sure to track it.
>
> Iolanda: this is the landing page for the Wikimedia Foundation Research
> team[4], not for the international community of researchers who study
> Wiki[*]edia. It's also not the landing page for all researchers and
> research activities within the Wikimedia Foundation--just those of team
> members (and Aaron, whose Scoring Platform team is a kind of spin
> off/sibling of the research team).
>
> Thanks everyone for the feedback so far. Keep it coming,
>
> Jonathan
>
> 1. https://github.com/wikimedia/research-landing-page
> 2. https://phabricator.wikimedia.org/tag/research/
> 3. https://phabricator.wikimedia.org/T107389
> 4. https://www.mediawiki.org/wiki/Wikimedia_Research
>
> On Thu, Feb 8, 2018 at 8:09 AM, Aaron Halfaker 
> wrote:
>
>> Hey folks, I see you're using github[1], but you've disabled the issue
>> tracker there.  Where should I submit bug reports and feature requests?
>> Maybe you could add a link next to "source code" at the bottom of the
>> page.
>>
>> 1. https://github.com/wikimedia/research-landing-page
>>
>> On Thu, Feb 8, 2018 at 10:02 AM, Aaron Halfaker > >
>> wrote:
>>
>> > Depends on which standard.  This is not a wiki page so it won't be
>> > translatable using the on-wiki translate tools.  However, it's quite
>> > possible that we could use something like translatewiki.net.  I'm not
>> > sure if that is on the road map.  Dario, what do you think?
>> >
>> > On Thu, Feb 8, 2018 at 1:31 AM, Federico Leva (Nemo) <
>> nemow...@gmail.com>
>> > wrote:
>> >
>> >> Will it be translatable with standard tools?
>> >>
>> >> Federico
>> >>
>> >>
>> >> ___
>> >> 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
>>
>
>
>
> --
> Jonathan T. Morgan
> Senior Design Researcher
> Wikimedia Foundation
> User:Jmorgan (WMF) 
>
>


-- 
Jonathan T. Morgan
Senior Design Researcher
Wikimedia Foundation
User:Jmorgan (WMF) 
___
Wiki-research-l mailing list
Wiki-research-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wiki-research-l

Re: [Wiki-research-l] [Analytics] A new landing page for the Wikimedia Research team

[Jonathan Morgan]

Aaron: I'll ask Baha about the issue tracking... *issue* today. The code is
hosted on Gerrit now, with a one-way mirror on this GitHub repo[1], which
is not ideal from an openness/collaboration POV. For me, enabling easy
issue tracking and pull requests is the most pressing issue. In the
meantime, you can submit tasks through Phab. Add them to the Research
board[2] and/or as subtasks of our Landing Page creation epic[3]. Not
ideal, but at least you can capture things this way.

Federico: Translation via translatewiki would be very cool. We haven't
prioritized this because, well, none of our on-wiki research team pages
were ever translated, and this microsite is intended to supplement our
on-wiki content, not replace it. But it sounds like a potential 'roadmap'
kinda deal and I'll make sure to track it.

Iolanda: this is the landing page for the Wikimedia Foundation Research
team[4], not for the international community of researchers who study
Wiki[*]edia. It's also not the landing page for all researchers and
research activities within the Wikimedia Foundation--just those of team
members (and Aaron, whose Scoring Platform team is a kind of spin
off/sibling of the research team).

Thanks everyone for the feedback so far. Keep it coming,

Jonathan

1. https://github.com/wikimedia/research-landing-page
2. https://phabricator.wikimedia.org/tag/research/
3. https://phabricator.wikimedia.org/T107389
4. https://www.mediawiki.org/wiki/Wikimedia_Research

On Thu, Feb 8, 2018 at 8:09 AM, Aaron Halfaker 
wrote:

> Hey folks, I see you're using github[1], but you've disabled the issue
> tracker there.  Where should I submit bug reports and feature requests?
> Maybe you could add a link next to "source code" at the bottom of the page.
>
> 1. https://github.com/wikimedia/research-landing-page
>
> On Thu, Feb 8, 2018 at 10:02 AM, Aaron Halfaker 
> wrote:
>
> > Depends on which standard.  This is not a wiki page so it won't be
> > translatable using the on-wiki translate tools.  However, it's quite
> > possible that we could use something like translatewiki.net.  I'm not
> > sure if that is on the road map.  Dario, what do you think?
> >
> > On Thu, Feb 8, 2018 at 1:31 AM, Federico Leva (Nemo)  >
> > wrote:
> >
> >> Will it be translatable with standard tools?
> >>
> >> Federico
> >>
> >>
> >> ___
> >> 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
>



-- 
Jonathan T. Morgan
Senior Design Researcher
Wikimedia Foundation
User:Jmorgan (WMF) 
___
Wiki-research-l mailing list
Wiki-research-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wiki-research-l

Re: [Wiki-research-l] [Analytics] A new landing page for the Wikimedia Research team

[Aaron Halfaker]

Hey folks, I see you're using github[1], but you've disabled the issue
tracker there.  Where should I submit bug reports and feature requests?
Maybe you could add a link next to "source code" at the bottom of the page.

1. https://github.com/wikimedia/research-landing-page

On Thu, Feb 8, 2018 at 10:02 AM, Aaron Halfaker 
wrote:

> Depends on which standard.  This is not a wiki page so it won't be
> translatable using the on-wiki translate tools.  However, it's quite
> possible that we could use something like translatewiki.net.  I'm not
> sure if that is on the road map.  Dario, what do you think?
>
> On Thu, Feb 8, 2018 at 1:31 AM, Federico Leva (Nemo) 
> wrote:
>
>> Will it be translatable with standard tools?
>>
>> Federico
>>
>>
>> ___
>> Wiki-research-l mailing list
>> Wiki-research-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
>>
>
>
___
Wiki-research-l mailing list
Wiki-research-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wiki-research-l

Re: [Wiki-research-l] [Analytics] A new landing page for the Wikimedia Research team

[Aaron Halfaker]

Depends on which standard.  This is not a wiki page so it won't be
translatable using the on-wiki translate tools.  However, it's quite
possible that we could use something like translatewiki.net.  I'm not sure
if that is on the road map.  Dario, what do you think?

On Thu, Feb 8, 2018 at 1:31 AM, Federico Leva (Nemo) 
wrote:

> Will it be translatable with standard tools?
>
> Federico
>
>
> ___
> 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] CfP CIDOC abstracts Provenance of Knowledge, Heraklion 30sep-4Oct 2018

[Trilce Navarrete]

Dear all,

I am wondering if anybody would be interested in proposing a Wikidata
mapping using CIDOC CRM.  Heraklion, where the conference will take place,
is a CRM centre where lots of LOD specialists will join.

I would be happy to answer any questions

best
Trilce













**CIDOC 2018 Call for Papers* OPEN UNTIL February 28, 2018Now through
February 28, we are accepting proposals for presentations, workshops, and
case studies for the International Committee for Documentation (CIDOC) of
the International Council of Museum’s (ICOM) annual conference. Every year,
the CIDOC conference brings together museums and cultural heritage
professionals and researchers together in a dynamic, common forum to share
knowledge and experience, to gain new perspectives and to make new
connections. The theme of this year’s conference is Provenance of
Knowledge. Visit the CIDOC 2018 Call for Papers page for submission
guidelines and selection criteria: http://www.cidoc2018.com/call-papers
This year’s conference will be held
in the historical seaside city of Heraklion, Crete in Greece from the 29th
of September until the 4th of October. The conference offers a full
programme of sessions and working groups offering new perspectives and
hands on learning experiences. Conference participants, moreover, will have
the chance to experience the museological, historical and natural wealth of
Crete through a full cultural programme, including a visit to the
archaeological site of Knossos, palatial capital of the ancient Minoan
civilization.The thematic focus of the conference is ‘the Provenance of
Knowledge.’ As an essential aspect of documentation, Provenance of
Knowledge refers to the work of tracing the origins of the information and
knowledge about an object, an entity or an idea in order to reconstruct the
whole chain of creation, use, interpretation and dissemination of this
knowledge. The aim of such reconstruction is to confirm or disconfirm,
illustrate, and draw upon the information contained in documentation in
order to facilitate understanding across cultures and time. Work on
provenance of knowledge by different professionals from different
perspectives helps draw together the various threads of documentation,
scholarship and the material evidence kept in museums and other memory
institutions into a common resource for humankind.The task of validating
the information and knowledge held in memory institutions is increasingly
aided by the use of digital technologies in documentation. Such advances,
however, bring their own difficulties, as the abundance of the available
information makes it difficult to introduce standards and processes to
model and maintain the development and validity of documented information.
Therefore, perspectives on unravelling the complications of digital
provenance of knowledge are particularly welcome.The 2018 CIDOC conference
aims at supporting museums and memory institutions in the task of
documentation by deepening our common understanding of the challenges of
provenance of knowledge and the importance of documentation as a means of
knowledge preservation, dissemination and exchange between peoples and
across time.You are, therefore, warmly welcomed to share your insight into
the questions of provenance of knowledge and documentation generally with
the documentation community of CIDOC that will be gathered on the beautiful
island of Crete, Sep. 30 – Oct. 5, 2018.Visit the CIDOC 2018 Call for
Papers page for submission guidelines and selection criteria:
http://www.cidoc2018.com/call-papers *

-- 
:..::...::..::...::..:
Trilce Navarrete

m: +31 (0)6 244 84998 | s: trilcen | t: @trilcenavarrete
w: trilcenavarrete.com
___
Wiki-research-l mailing list
Wiki-research-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wiki-research-l