Re: [Wikimedia-l] [Wikimedia Research Showcase] July 15, 2020: Medical Knowledge on Wikipedia

[Janna Layton]

Hello all,

Reminder that this very topical Research Showcase will be happening on
Wednesday.

On Thu, Jul 9, 2020 at 12:26 PM Janna Layton  wrote:

> Hi all,
>
> The next Research Showcase will be live-streamed on Wednesday, July 15, at
> 9:30 AM PDT/16:30 UTC.
>
> Wikipedia is one of the most important online resources for health
> information. This has been especially highlighted during the Covid-19
> pandemic: since the beginning of the year more than 5000 articles related
> to Covid-19 have been created receiving more than 400M pageviews.
> Therefore, for this month’s showcase our two invited speakers will help us
> get a better understanding of the state of medical knowledge in Wikipedia.
> In the first talk, Denise Smith will give an overview on how Wikipedia's
> health content is used by different audiences (public, students, or
> practitioners). In the second talk, Giovanni Colavizza will present results
> on how editors on Wikipedia find, select, and integrate scientific
> information on Covid-19 into Wikipedia articles.
>
> YouTube stream: https://www.youtube.com/watch?v=qIV26lWrD9c
>
> As usual, you can join the conversation on IRC at #wikimedia-research. You
> can also watch our past research showcases here:
> https://www.mediawiki.org/wiki/Wikimedia_Research/Showcase
>
> This month's presentations:
>
> Wikipedia for health information - Situating Wikipedia as a health
> information resource
>
> By Denise Smith (McMaster University, Health Sciences Library & Western
> University, Faculty of Information & Media Studies)
>
> Wikipedia is the most frequently accessed web site for health information,
> but the various ways users engage with Wikipedia’s health content has not
> been thoroughly investigated or reported. This talk will summarize the
> findings of a comprehensive literature review published in February. It
> explores all the contexts in which Wikipedia’s health content is used that
> have been reported in academic literature. The talk will focus on the
> findings reported in this paper, the potential impact of this study in
> health and medical librarianship, the practice of medicine, and medical or
> health education.
>
>
>-
>
>D.A. Smith (2020). "Situating Wikipedia as a health information
>resource in various contexts: A scoping review". PLoS ONE.
>https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0228786
>
>
>
> COVID-19 research in Wikipedia
>
> By Giovanni Colavizza (University of Amsterdam, Netherlands)
>
> Wikipedia is one of the main sources of free knowledge on the Web. During
> the first few months of the pandemic, over 4,500 new Wikipedia pages on
> COVID-19 have been created and have accumulated close to 250M pageviews by
> early April 2020.1 At the same time, an unprecedented amount of scientific
> articles on COVID-19 and the ongoing pandemic have been published online.
> Wikipedia’s contents are based on reliable sources, primarily scientific
> literature. Given its public function, it is crucial for Wikipedia to rely
> on representative and reliable scientific results, especially so in a time
> of crisis. We assess the coverage of COVID-19-related research in Wikipedia
> via citations. We find that Wikipedia editors are integrating new research
> at an unprecedented fast pace. While doing so, they are able to provide a
> largely representative coverage of COVID-19-related research. We show that
> all the main topics discussed in this literature are proportionally
> represented from Wikipedia, after accounting for article-level effects. We
> further use regression analyses to model citations from Wikipedia and show
> that, despite the pressure to keep up with novel results, Wikipedia editors
> rely on literature which is highly cited, widely shared on social media,
> and has been peer-reviewed.
>
>
>-
>
>G. Colavizza (2020). "COVID-19 research in Wikipedia". bioRxiv.
>https://www.biorxiv.org/content/10.1101/2020.05.10.087643v2
>
>
> --
> Janna Layton (she/her)
> Administrative Assistant - Product & Technology
> Wikimedia Foundation 
>
> --
> Janna Layton (she/her)
> Administrative Assistant - Product & Technology
> Wikimedia Foundation 
>


-- 
Janna Layton (she/her)
Administrative Assistant - Product & Technology
Wikimedia Foundation 
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] New essay on the ambiguity of NC licenses

[Alessandro Marchetti via Wikimedia-l]

 I would probably never try to convince somebody about NC license. It sounds 
pushy and almost never works, it's like optimizing a process that has a 0.1% 
output. of course I can spend less time to do so, and maybe double the effect, 
but it's still a limited output. 

I prefer to agree with them, build a trust, produce other content with such 
trust (that is not related to files of their production) and than, maybe, we 
face the issue of images.
For example I almost convinced an artist to give me in free license 
reproductions of his public artworks that are already destroyed, until a person 
close to him stopped him (and he agreed with me prgamatically, I think that he 
stopped only for sentimental reason)
There are other way to get free files ad they have nothing to do about "being 
used on Wikipedia". if you want to be used on Wikipedia, you put it there, in 
my experience this is not a critical factor in changing the opinion. For 
example Wiki Science Competition gets files also from scientists that would 
normally use NC, but it's not really about explaining the license, it's about 
getting a prize, a visibility and being part of a network, a strat a discussion 
about outreach. 

Alessandro


Il lunedì 13 luglio 2020, 08:25:39 CEST, Pete Forsyth 
 ha scritto:  
 
 Erik, thanks for posting the essay here. Glad to see the interest in this
topic.

I wrote this because I have found that when somebody asks me about the NC
provision, I often want to point them to a simple webpage (rather than
"reinventing the wheel" every time it comes up). There are some pages out
there (I listed some in the "See also" section), but I have yet to find
somewhere this particular point -- the need of a general license to issue
clear guidance -- articulated anywhere in a concise, accessible way.

I'm surprised (and a little disappointed) to see that the possibility of
Wikimedia generally accepting NC-licensed work is being discussed. But
apart from that discussion, I think many of you in this discussion have, at
one time or another, wanted to help guide someone toward using a more
permissive license, rather than a NC license.

For those who have, do you have favorite webpages you find helpful to
share? Does this one seem like a useful addition? I'd appreciate any
feedback or constructive edits to this essay; I also think it would be
useful to have some of the other arguments, currently collected in longer
documents, expressed in more "bite-sized" pieces like this, which could be
linked together. Do others agree, and if so, are you inclined to help draft
some complementary pages?

-Pete
[[User:Peteforsyth]]

On Sun, Jul 12, 2020 at 3:23 PM effe iets anders 
wrote:

> The question is however as well: how many open licensed content creators
> would switch to NC if they were aware that this would be 'good enough' for
> Wikipedia - even if that means in reality only English Wikipedia (but who
> cares about other languages) and without actually allowing to build on top
> of it?
>
> I have found the argument 'don't use NC because then it can't be used on
> Wikipedia' rather convincing in the past. It will not always work, and I
> also wish it would convince /more/ organizations. But then, I would also
> wish that enwiki wouldn't use fair use exceptions - so maybe I'm not the
> benchmark you'd be looking at anyway.
>
> Lodewijk
>
> On Sat, Jul 11, 2020 at 5:32 PM James Heilman  wrote:
>
> > Yes one of the stronger reasons to reject all use of the NC license is
> that
> > it increases incentives for other organizations to actually adopt open
> > licenses. I simply wish that such a position would convince more
> > organizations. WHO has repeatedly told me that we, as a non-profit, are
> > already free to use their work and if we chose not to, that is on us.
> >
> > James
> >
> > On Sat, Jul 11, 2020 at 6:19 PM Erik Moeller 
> wrote:
> >
> > > Hi James :)
> > >
> > > (This is my last reply for today, given the recommended posting limit
> > > on this list.)
> > >
> > > > We all agree that NC licenses are exceedingly poor due to the reasons
> > > > listed, yet we leave a lot of useful content (such as Khan academy
> > > videos)
> > > > less accessible to our readers because we disallow any such use.
> > >
> > > I completely agree. I'm wondering if efforts have been made at the WMF
> > > or chapter level to partner with these organizations on new
> > > initiatives, where a more permissive license could be used? This could
> > > perhaps help to introduce CC-BY-SA/CC-BY to orgs like Khan Academy,
> > > and help lay the groundwork for potentially changing their default
> > > license.
> > >
> > > > This is a balance between pragmatism and idealism.
> > >
> > > I disagree with your framing here. There are many pragmatic reasons to
> > > want to build a knowledge commons with uniform expectations for how it
> > > can be built upon and re-used. It's also pragmatic to be careful about
> > > altering the incentive structure for contributors. 

Re: [Wikimedia-l] Fwd: Re: [Wikitech-l] CI and Code Review

[Grant Ingersoll]

Apologies for the cross-post, but doing so because the thread was
forwarded, also apologies for the length.

On Wed, Jul 8, 2020 at 5:01 PM Maarten Dammers  wrote:

> Of interest to the wider community. I really hope this is not part of a
> larger pattern of the WMF ignoring community.
>
>
"Never attribute to malice that which is adequately explained by
stupidity." [1]


In this case, my own stupidity (I'm the new CTO here at the WMF, for
context), or perhaps to be a little kinder to myself, a combination of bias
and naivety: my engineering bias towards wanting to solve a problem I felt
was important to take action on (context provided shortly) which got in the
way of taking a user-centric approach first in trying to understand what
the needs and wants are of the people using the system.  As I said on the
talk page, I mistakenly thought that the main feedback loops would be about
porting workflows and not about the tool itself.


Even though many have publicly said that moving from Gerrit might still be
the right decision, how we go about deciding that is just as important as
what we do and I messed that up. Given that perspective, I've asked the
team to pause with moving forward on changes to our Code Review (CR) tools
and to begin a consultation that includes the option of sticking with what
we have for CR. I've also asked my team to update some of our decision
making processes relative to topics like this to make sure we properly hear
from stakeholders (e.g. in this case, both staff developers and our broader
community of developers) along the way.


For some more context, if it is helpful:


I'm ~11 months in here and still learning every day.  While I've worked in
open source for a long time, this community is new to me and different
enough that I have and continue to need to update and adjust the way I
think and the way I direct my teams to do their work.


Coming in and talking with our tech teams and folks in the community, I see
a few themes that have emerged that contributed to me wanting to move
forward faster on this decision:


1. We have a lot of tech debt[2].  In many cases, I think software,
especially software that is successful, can collapse under its own weight
if people are not careful in servicing that tech debt.  The work required
to both maintain existing infrastructure, products and services while at
the same time improving what we offer is a delicate balancing act. At our
scale, there is a significant and justified bias towards production, but it
has come at a cost that has compounded over the years and has a very real
human toll. Much of this debt was created because we had to invent things
that didn't exist.  Now some of those things do exist and we should check
to see whether we can replace those older, albeit well-understood-by-us
systems, with newer ones that have become standards or best in class and
are still in line with our open source values.


2. The tech debt and the sheer number of services we support (many of which
aren't fully maintained[3]) is compounded by the scale at which we support
them. The result is that a number of people, especially those on the front
line of caring for that software, are either burnt out, or approaching that
point. A global pandemic hasn't helped. I view much of my role here early
on as one of trying to help somehow reduce that burnout. Modernizing and
upgrading our processes and toolchains can, I think, help fight this, even
if there is some short term pain in the shift.


All that being said, in this particular case, we have a team of people who
work on maintaining our CI (Continuous Integration) and CR systems who have
long been looking at replacing our CI system. This system runs on an
end-of-lifed version of Python and on an end-of-lifed version of Zuul, and
it’s critical we correct this since end-of-lifed software doesn’t receive
security updates. This is primarily behind the scenes work that most people
don't have to think about. There is also a growing sense of desire by some
of our developers to adopt more mainstream, well understood toolchains like
Gitlab/Github for development, combined with my own view that CI/CR is
*not* somewhere we should be deviating from broad industry norms on
ourselves and that we should adopt workflows that are (de facto) standards
(e.g. Gitlab/Github, with Gitlab being the open one of the two) amongst
developers irrespective of their backgrounds. Those two things led to my
biased thinking that it was obvious it needed to be changed and that the
primary feedback needed would therefore be on the workflows, not the tool
itself.


While I still think it needs to be changed, I completely missed, as I said
above, the stakeholder angle  here and basic community laws of not
surprising people.  For that I apologize.  We are now working to correct
this, even if it means it's going to take longer or we end up sticking with
the status quo on CR.


Thanks,

Grant



[1] 

Re: [Wikimedia-l] Affiliations Committee 2020 Mid-Term Election results

[Rajeeb Dutta]

I congratulate all the elected members.

Best Regards,
Rajeeb.
(U: Marajozkee)
(Sent from my iPhone pardon the brevity) 

> On 13-Jul-2020, at 2:58 AM, Rosie Stephenson-Goodknight 
>  wrote:
> 
> Subject line: Affiliations Committee 2020 Mid-Term Election results
> 
> Dear everyone,
> 
> We are happy to share that Başak Tosun, Bunty Avieson, Jeffery Keefer,
> Ravan Al-Taie, and Suyash Dwivedi are new members who have been appointed
> to the Affiliations Committee, while Camelia Boban has been re-appointed.
> 
> Here are Başak Tosun, Bunty Avieson, Jeffery Keefer, Ravan Al-Taie, and
> Suyash Dwivedi, in their own words:
> 
> 
>   1.
> 
>   Başak Tosun:
>   I have been a contributor to Wikimedia projects since 2005. I mainly
>   contribute to Turkish Wikipedia. For a long time, I was only an online
>   contributor; I discovered that contributions to free knowledge could go
>   beyond editing after I joined an international WikiCamp in 2015. Then I
>   contacted fellow wikipedians to form a user group in Turkey and became one
>   of the founder members of Wikimedia Community User Group Turkey. I took the
>   responsibility of Wikipedia Education Programs in the group and organised
>   Education Programs in several courses at 8 different universities.
>   Additionally, I take part in organising edit-a-thons, partnership search,
>   organising local contests.
> 
> 
> 
>   1.
> 
>   Bunty Avieson:
>   I am a media academic at University of Sydney and a member of Wikimedia
>   Australia. I learned to edit at an Art & Feminism event in March 2017 and
>   immediately followed up with an online course. I have since hosted
>   edit-a-thons in Sydney and Bhutan, but my interest goes beyond editing to
>   the larger goals of the Wikimedia movement, particularly around knowledge
>   equity and diversity. I’m currently leading two research projects to build
>   smaller language Wikipedias. One is a collaboration with Tata Institute of
>   Social Sciences in Mumbai to train two groups of retired Tamils, in both
>   Sydney and Mumbai, to edit Tamil Wikipedia. The other is a three-year
>   project funded by the Australian Research Council, to train Bhutanese to
>   publish on both English Wikipedia and also develop their Dzongkha site. I'm
>   an active member of Women Write Wiki and Women In Red.
> 
> 
> 
>   1.
> 
>   Jeffery Keefer:
>   I serve as a Wikimedian in Residence for the Patient-Centered Outcomes
>   Research Institute (PCORI). I started editing Wikipedia three years ago
>   while attending an open education conference in London where I went to a
>   workshop and was challenged to learn to try editing Wikipedia. Between then
>   and now Wikimedia has become my online home, where I edit and teach
>   students how to use our Wikimedia projects, am active across all three
>   types of Affiliates, and was one of the writers of the Movement Strategy
>   Recommendations. I have a PhD in educational research. I am or have been
>   involved in a number of Wikipedia + Wikimedia projects across the Movement:
>   Wikimedia Movement Strategy: Integrator, Writer, and Co-Coordinator of the
>   Capacity Building Working Group; Election Facilitator for the
>   Affiliate-Selected Board Seats (ASBS) election, 2019; Member of the Board,
>   Wikimedia New York City; Member, Project Grants Committee; AffCom Reporting
>   Representative, LGBT+ User Group; Member, Editorial Board of the
>   WikiJournal of Humanities; Member, Wikimedians in Residence Exchange
>   Network; Member, Wiki Project Med Foundation Member; WikiConference
>   North America User Group.
> 
> 
> 
>   1.
> 
>   Ravan Al-Taie:
>   I am Ravan Al-Taie. I'm the founder of Iraqi Wikimedians User Group. I
>   am an engineer, working as a professional in the Oil industry. I started
>   editing Wikipedia in 2008, edited Arabic wikipedia and became an admin in
>   2013 for more than 6 years. In 2015, My mother language is Arabic, but I
>   speak Kurdish language fluently as well, that's why I helped in Kurdish
>   Wikipedia and currently helping other colleagues to correctly start Kurdish
>   Wikipidian user group as per the foundation process because I strongly
>   believe the more diverse we are the best to be in representing the global
>   knowledge heritage. I've led several offline activities such as organizing
>   WLM for 3 years in Iraq, as well as starting the first editathon and
>   learning workshop in all Iraq with great success. After that, I've focused
>   on bringing more women to the movement in order to decrease the big gender
>   gap that we have in Arabic Wikipedia.
> 
> 
> 
>   1.
> 
>   Suyash Dwivedi:
>   I have done my graduation in Electronics Engineering and have been a
>   Wikimedian since 2013. Mostly I edit on Commons, Hindi, English, Wikidata,
>   GLAM, Wikivoyage and sometimes on other Wikipedia projects. I have
>   organized many outreach activities, including conferences and edit-a-thons.
>   I am the founder member of Hindi Wikimedians 

Re: [Wikimedia-l] New essay on the ambiguity of NC licenses

[Pete Forsyth]

Erik, thanks for posting the essay here. Glad to see the interest in this
topic.

I wrote this because I have found that when somebody asks me about the NC
provision, I often want to point them to a simple webpage (rather than
"reinventing the wheel" every time it comes up). There are some pages out
there (I listed some in the "See also" section), but I have yet to find
somewhere this particular point -- the need of a general license to issue
clear guidance -- articulated anywhere in a concise, accessible way.

I'm surprised (and a little disappointed) to see that the possibility of
Wikimedia generally accepting NC-licensed work is being discussed. But
apart from that discussion, I think many of you in this discussion have, at
one time or another, wanted to help guide someone toward using a more
permissive license, rather than a NC license.

For those who have, do you have favorite webpages you find helpful to
share? Does this one seem like a useful addition? I'd appreciate any
feedback or constructive edits to this essay; I also think it would be
useful to have some of the other arguments, currently collected in longer
documents, expressed in more "bite-sized" pieces like this, which could be
linked together. Do others agree, and if so, are you inclined to help draft
some complementary pages?

-Pete
[[User:Peteforsyth]]

On Sun, Jul 12, 2020 at 3:23 PM effe iets anders 
wrote:

> The question is however as well: how many open licensed content creators
> would switch to NC if they were aware that this would be 'good enough' for
> Wikipedia - even if that means in reality only English Wikipedia (but who
> cares about other languages) and without actually allowing to build on top
> of it?
>
> I have found the argument 'don't use NC because then it can't be used on
> Wikipedia' rather convincing in the past. It will not always work, and I
> also wish it would convince /more/ organizations. But then, I would also
> wish that enwiki wouldn't use fair use exceptions - so maybe I'm not the
> benchmark you'd be looking at anyway.
>
> Lodewijk
>
> On Sat, Jul 11, 2020 at 5:32 PM James Heilman  wrote:
>
> > Yes one of the stronger reasons to reject all use of the NC license is
> that
> > it increases incentives for other organizations to actually adopt open
> > licenses. I simply wish that such a position would convince more
> > organizations. WHO has repeatedly told me that we, as a non-profit, are
> > already free to use their work and if we chose not to, that is on us.
> >
> > James
> >
> > On Sat, Jul 11, 2020 at 6:19 PM Erik Moeller 
> wrote:
> >
> > > Hi James :)
> > >
> > > (This is my last reply for today, given the recommended posting limit
> > > on this list.)
> > >
> > > > We all agree that NC licenses are exceedingly poor due to the reasons
> > > > listed, yet we leave a lot of useful content (such as Khan academy
> > > videos)
> > > > less accessible to our readers because we disallow any such use.
> > >
> > > I completely agree. I'm wondering if efforts have been made at the WMF
> > > or chapter level to partner with these organizations on new
> > > initiatives, where a more permissive license could be used? This could
> > > perhaps help to introduce CC-BY-SA/CC-BY to orgs like Khan Academy,
> > > and help lay the groundwork for potentially changing their default
> > > license.
> > >
> > > > This is a balance between pragmatism and idealism.
> > >
> > > I disagree with your framing here. There are many pragmatic reasons to
> > > want to build a knowledge commons with uniform expectations for how it
> > > can be built upon and re-used. It's also pragmatic to be careful about
> > > altering the incentive structure for contributors. Right now,
> > > Wikimedia Commons hosts millions of contributions under permissive
> > > licenses. How many of those folks would have chosen an "exceedingly
> > > poor" (your words) option like NC, if that was available? And if a
> > > nonfree carve-out is limited to organizations like Khan Academy, how
> > > is such a carve-out fair and equitable to contributors who have, in
> > > some cases, given up potential commercial revenue to contribute to
> > > Wikimedia projects?
> > >
> > > If a license is "exceedingly poor" and harmful to the goals of the
> > > free culture movement, incorporating more information under such terms
> > > strikes me as neither idealistic nor pragmatic -- it would just be
> > > short-sighted.
> > >
> > > Warmly,
> > > Erik
> > >
> > > ___
> > > Wikimedia-l mailing list, guidelines at:
> > > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> > > https://meta.wikimedia.org/wiki/Wikimedia-l
> > > New messages to: Wikimedia-l@lists.wikimedia.org
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > 
> >
> >
> >
> > --
> > James Heilman
> > MD, CCFP-EM, Wikipedian
> >