[Wikimedia-l] Re: Outcomes from the March Meeting for the Wikimedia Foundation Board of Trustees

[Steven Walling]

On Thu, Mar 28, 2024 at 1:51 PM Samuel Klein  wrote:

> I wanted to clarify that it is not 3% of all donors that go on to make an
>> unreverted edit.  All donors are directed to a “Thank You” page after their
>> donations, which includes several calls-to-action.  This year, we included
>> a call to “Try editing Wikipedia”. Due to the way that we restrict tracking
>> due to user privacy, the chart representing the editing funnel
>> 
>> actually starts once a donor has clicked that call to create an account. In
>> other words, of the people who donated during the Big English banner
>> campaign, only 12,005 actually clicked through from the donor Thank You
>> page to create an account. From those who click through, about 3.7% of
>> people end up completing an unreverted edit.
>>
> I see, that explains why this wasn't more than a footnote.  :)   Someone
> who just donated is unlikely to be a bot or spammer, so not surprising
> their edit quality is higher.
>
> Once someone decides to try editing, ideally almost all of them would make
> an edit, without needing to make an account.  Perhaps: "Try editing" -->
> simple interface for easy edits --> make a few edits -->  see a few edits
> by others to review  (or offer the same edits to a few people) --> only
> then make an account via simple creation popup...
>

We actually have tried something similar years ago (asking unregistered
editors to sign up after editing or even as a part of saving) and it didn’t
really work. The thing is that we’ve never really explained why there’s a
compelling reason to have an account to edit I think.

The Growth team has done a good job though in recent years with recommended
tasks for new editors. It’s not perfect but once you sign up there is a
pretty good onboarding path. One thing I’d love to see is testing more of a
focus on joining WikiProjects. Generic mentorship and tasks are good, but
connecting with a group of people also interested in your topic of choice
is cooler. It’s why social products like Reddit, Facebook Groups, etc are
so sticky.

The truth is with any engagement, reading or editing, there will be a steep
drop off rate in many (if not most) steps in a process. It’s still very
nice to see edits happen as a part of the fundraising campaigns. The call
to participate has no downside even if the impact is relatively small.



> Thank you for clarifying and updating the report.  I left a few comments
> on that talk page
> 
> .
>
> SJ
> ___
> Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines
> at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/GJ56SCAYGK27S4UGALBSGH3DYEDVXLT6/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/MK2RGMQ25D5TA7SAZECBO4LGJADJHBTZ/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Xmldatadumps-l] Re: [Wikitech-l] Re: Wiki content and other dumps new ownership, feedback requested on new version!

[Steven Walling]

+1 to Dan. Ariel thank you for so many years of doing this essential work.

On Thu, Sep 28, 2023 at 4:14 AM Dan Andreescu 
wrote:

> Ariel, your dedication to dumps has always been an inspiration to me, both
> in how you handled the technology and how you fused that with your care for
> the ideas behind it.  Thank you, and hope we can do it justice with the
> next phase of Dumps.
>
> On Thu, Sep 28, 2023 at 12:39 AM Ariel Glenn WMF 
> wrote:
>
>> Hello folks!
>>
>> For some years now, I've been the main or only point of contact for the
>> Wiki project sql/xml dumps semimonthly, as well as for a number of
>> miscellaneous weekly datasets.
>>
>> This work is now passing to Data Platform Engineering (DPE), and your new
>> points of contact, starting right away, will be Will Doran (email:wdoran)
>> and Virginia Poundstone (email:vpoundstone). I'll still be lending a hand
>> in the background for a little while but by the end of the month I'll have
>> transitioned into a new role at the Wikimedia Foundation, working more
>> directly on MediaWiki itself.
>>
>> The Data Products team, a subteam of DPE, will be managing the current
>> dumps day-to-day, as well as working on a new dumps system intended to
>> replace and greatly improve the current one. What formats will it produce,
>> and what content, and in what bundles?  These are all great questions, and
>> you have a chance to help decide on the answers. The team is gathering
>> feedback right now; follow this link [
>> https://docs.google.com/forms/d/e/1FAIpQLScp2KzkcTF7kE8gilCeSogzpeoVN-8yp_SY6Q47eEbuYfXzsw/viewform?usp=sf_link]
>> to give your input!
>>
>> If you want to follow along on work being done on the new dumps system,
>> you can check the phabricator workboard at
>> https://phabricator.wikimedia.org/project/board/6630/ and look for items
>> with the "Dumps 2.0" tag.
>>
>> Members of the Data Products team are already stepping up to manage the
>> xmldatadumps-l mailing list, so you should not notice any changes as far as
>> that goes.
>>
>> And as always, for dumps-related questions people on this list cannot
>> answer, and which are not covered in the docs at
>> https://meta.wikimedia.org/wiki/Data_dumps or
>> https://wikitech.wikimedia.org/wiki/Dumps you can always email ops-dumps
>> (at) wikimedia.org.
>>
>> See you on the wikis!
>>
>> Ariel Glenn
>> ar...@wikimedia.org
>> ___
>> Wikitech-l mailing list -- wikitec...@lists.wikimedia.org
>> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
>>
>> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
>
> ___
> Wikitech-l mailing list -- wikitec...@lists.wikimedia.org
> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
___
Xmldatadumps-l mailing list -- xmldatadumps-l@lists.wikimedia.org
To unsubscribe send an email to xmldatadumps-l-le...@lists.wikimedia.org

[Wikitech-l] Re: Wiki content and other dumps new ownership, feedback requested on new version!

[Steven Walling]

+1 to Dan. Ariel thank you for so many years of doing this essential work.

On Thu, Sep 28, 2023 at 4:14 AM Dan Andreescu 
wrote:

> Ariel, your dedication to dumps has always been an inspiration to me, both
> in how you handled the technology and how you fused that with your care for
> the ideas behind it.  Thank you, and hope we can do it justice with the
> next phase of Dumps.
>
> On Thu, Sep 28, 2023 at 12:39 AM Ariel Glenn WMF 
> wrote:
>
>> Hello folks!
>>
>> For some years now, I've been the main or only point of contact for the
>> Wiki project sql/xml dumps semimonthly, as well as for a number of
>> miscellaneous weekly datasets.
>>
>> This work is now passing to Data Platform Engineering (DPE), and your new
>> points of contact, starting right away, will be Will Doran (email:wdoran)
>> and Virginia Poundstone (email:vpoundstone). I'll still be lending a hand
>> in the background for a little while but by the end of the month I'll have
>> transitioned into a new role at the Wikimedia Foundation, working more
>> directly on MediaWiki itself.
>>
>> The Data Products team, a subteam of DPE, will be managing the current
>> dumps day-to-day, as well as working on a new dumps system intended to
>> replace and greatly improve the current one. What formats will it produce,
>> and what content, and in what bundles?  These are all great questions, and
>> you have a chance to help decide on the answers. The team is gathering
>> feedback right now; follow this link [
>> https://docs.google.com/forms/d/e/1FAIpQLScp2KzkcTF7kE8gilCeSogzpeoVN-8yp_SY6Q47eEbuYfXzsw/viewform?usp=sf_link]
>> to give your input!
>>
>> If you want to follow along on work being done on the new dumps system,
>> you can check the phabricator workboard at
>> https://phabricator.wikimedia.org/project/board/6630/ and look for items
>> with the "Dumps 2.0" tag.
>>
>> Members of the Data Products team are already stepping up to manage the
>> xmldatadumps-l mailing list, so you should not notice any changes as far as
>> that goes.
>>
>> And as always, for dumps-related questions people on this list cannot
>> answer, and which are not covered in the docs at
>> https://meta.wikimedia.org/wiki/Data_dumps or
>> https://wikitech.wikimedia.org/wiki/Dumps you can always email ops-dumps
>> (at) wikimedia.org.
>>
>> See you on the wikis!
>>
>> Ariel Glenn
>> ar...@wikimedia.org
>> ___
>> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
>> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
>>
>> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
>
> ___
> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikimedia-l] Re: Launch of Justapedia

[Steven Walling]

On Sun, Sep 17, 2023 at 4:04 PM James Heilman  wrote:

> There are Wikis that have "succeeded" with IP editing turned off with
> some being WikEM and Eyewiki
>
> Additionally PT Wikipedia banned IP editing in 2020
>
> https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2020-11-01/News_and_notes
>
> Not sure how the later is going.
>
> James


These are all good examples of how we can’t take a “one size fits all”
approach when thinking about editing policies and features. The study of
the effects of no IP editing strongly reiterated this conclusion based on
the data:
https://meta.wikimedia.org/wiki/IP_Editing:_Privacy_Enhancement_and_Abuse_Mitigation/IP_Editing_Restriction_Study/Portuguese_Wikipedia

Portuguese Wikipedia is largely dominated by Brazilians. Brazil has some of
the highest social media use per capital in the world, so part of the
underlying reality is that PT Wikipedia users are probably unusually
willing to sign up for new services. This probably explains why in
Portuguese making people sign up didn’t result in fewer unreverted edits,
whereas when we tried even *suggesting* IP editors should sign up in other
wikis, it didn’t work:
https://meta.wikimedia.org/wiki/Research:Value_of_IP_Editing#Past_trials_of_this_idea_were_damaging

For starting a new general knowledge wiki, it’s a terrible idea to require
registration if you want to actually grow.


>
> On Sun, Sep 17, 2023 at 11:52 PM WereSpielChequers
>  wrote:
> >
> > Yesterday they had less than a hundred edits from just 6 individuals.
> The English language Wikipedia had around 150,000 edits. Justapedia needs a
> much bigger community for it to become more than a mirror.
> >
> > They've switched off IP editing, one of the mistakes citizendium made,
> so unless they relaunch themselves as the home of alternative medicine and
> alternative facts, I agree with Galder, they are unlikely to succeed.
> >
> >
> >
> > WSC
> >
> >
> >>
> >>
> >>
> >>
> >> Il giorno mar 12 set 2023 alle ore 08:15 Galder Gonzalez Larrañaga <
> galder...@hotmail.com> ha scritto:
> >>
> >> The logo is quite funny. According to that Information + Disinformation
> = Facts. It might be that they don't know what a Venn diagram is, or simply
> that they actually think that.
> >>
> >>
> >>
> >> Don't worry, this is just one more project that will fall into oblivion.
> >>
> >>
> >>
> >> Galder
> >>
> >>
> >>
> > ___
> > Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines
> at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> > Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/X7Z37EQNKLULOAL5N46RWE2UJMUWUVH6/
> > To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
>
>
>
> --
> James Heilman
> MD, CCFP-EM, Wikipedian
> ___
> Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines
> at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/KGYFOJJHDP7BQAUACEBO6DQWM5XHZKIV/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/IURNC3WJYQ6ZB7OQ2NOR6OXNLR5E43HG/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: Sharing an update on the Wikimedia Foundation Knowledge Equity Fund’s grantees

[Steven Walling]

 very long,
but maybe that's okay.

I’m also sharing details about the relationships that we’re building in the
> movement with some of our other new grantee.
>

I do not agree that generically "building relationships" is worth funding
$4.5 million of grants. I think Erik makes some really good points
previously that if we funded specific Wikimedian in residence / fellowship
type programs that were more akin to the GLAM movement or related movement
work on Art+Feminism then we could get both relationship building with
sister organizations *and* some kind of clear direct impact on Wikimedia
projects.


> Black Cultural Archives <https://blackculturalarchives.org/>: Given BCA’s
> focus, we have connected them with Wikimedia UK, Wiki Library User Group
> and Whose Knowledge to help them better understand how to connect their
> work and archives with the Wikimedia projects.
>
> Create Caribbean Research Institute <https://createcaribbean.org/create/>:
> As the first digital humanities centre in the Caribbean, Create Caribbean
> has natural alignment with Wiki Cari UG, as well as Noircir, Whose
> Knowledge, Projet:Université de Guyane, and WikiMujeres. We also plan to
> connect them to present or speak at Wiki Con North America.
>
> Criola <https://criola.org.br/>
>
> Criola is a civil society organization dedicated to advocating for the
> rights of Black women in Brazilian society. We have connected them with Whose
> Knowledge, WikiMujeres, Mujeres (mulheres) latino americanas in Wikimedia,
> and we will be connecting them with Mais_Teoria_da_Historia Na Brasil.
>
> Data for Black Lives <https://d4bl.org/>
>
> Given D4BL’s focus in the US, we have connected them with AfroCROWD and
> Black Lunch Table.
>
> Filipino American National Historical Society
> <http://fanhs-national.org/filam/>: FANHS is focused on Filipino American
> heritage, and as members of the diaspora we are connecting them with the
> PhilWiki Community, Wiki Advocates of Philippines and Wiki Libraries User
> Group.
>
> If you have other ideas for how we can improve, please reach out and let
> us know. Our email is equityf...@wikimedia.org.
>
> Best,
>
> Biyanto Rebin
>
> (committee member, Knowledge Equity Fund)
>
> On Fri, 18 Aug 2023 at 09:01, Samuel Klein  wrote:
>
>> ++.  Anything we can learn + apply from Outreachy (and their own
>> community of mentors, alums, and practitioners!) would be wonderful.
>> Their impact per unit of funding seems, at very casual inspection, well
>> ahead of all comparable initiatives.  And we could even fund them directly,
>> who have often helped us in turn. ;)
>>
>> On Fri, Aug 18, 2023 at 12:13 AM Erik Moeller 
>> wrote:
>>
>>> On Wed, Aug 16, 2023 at 10:23 PM Steven Walling
>>>  wrote:
>>>
>>> > With the money allocated to Knowledge Equity in the last couple years,
>>> we could have hired
>>> > at least a couple more software engineers to do work like fulfill
>>> community wishlist requests.
>>>
>>> I disagree with that framing. Wikimedia Foundation, even with reduced
>>> fundraising goals, is a very well-endowed organization that can easily
>>> shift more of its existing effort towards community wishlist requests.
>>> _All_ areas in which it spends money are deserving of healthy
>>> scrutiny, not just this new program. I feel it's best to evaluate this
>>> program on its own merits -- and to make a separate argument regarding
>>> the community wishlist & prioritization of software engineering
>>> ventures.
>>>
>>> To me, the question with these grants is whether there's a plausible
>>> theory of change that ties them back to the Wikimedia mission and
>>> movement. I share some skepticism about broad objectives around
>>> "improving quality of sources about X" without any _obvious and
>>> direct_ connection to the movement's work (i.e. concrete commitments
>>> about licensing and availability of information, or collaboration with
>>> Wikimedians). The Borealis Journalism Fund grant report [1] explicitly
>>> states:
>>>
>>> # of new images/media added to Wikimedia articles/pages: 0
>>> # of articles added or improved on Wikimedia projects: 0
>>> Absolute value of bytes added to or deleted from Wikimedia projects: 0
>>>
>>> (There are qualifiers in the report, but frankly, they're not very
>>> plausible ones.)
>>>
>>> I see a lot of value in WMF having new connections with these grantees
>>> -- these are organizations Wikimedia _should_ have a relationship
>&g

[Wikimedia-l] Re: Sharing an update on the Wikimedia Foundation Knowledge Equity Fund’s grantees

[Steven Walling]

On Wed, Aug 16, 2023 at 8:44 PM effe iets anders 
wrote:

> I'm very interested to see this develop further, and can understand some
> of the tensions that Steven has articulated. It's tricky to experience that
> we can't fund everything we want to do that has direct impact on our own
> work, and yet fund projects that don't feel like they directly support
> other activities our movement is deploying.
>

This last point—that we can’t fund everything we directly need but are
giving funds to only tangentially related special interest groups—hits home
for me.

With the money allocated to Knowledge Equity in the last couple years, we
could have hired at least a couple more software engineers to do work like
fulfill community wishlist requests. Especially in the context that we have
had to slow growth in the overall WMF budget and hiring, this program feels
particularly absurd.

The simple fact is that this program is being pointed to within the
community (at least on English Wikipedia) as a key example of how some
believe the annual fundraising campaigns are misleading to donors and
collecting funds that go to waste. There are editors gearing up yet again
to potentially run RFCs and pick a fight, despite thoughtful, diligent work
by the fundraising team to do outreach early and work collaboratively with
the community.

It will be sad if we end up having to scale back our primary fundraising
campaign a second year in a row, particularly if it’s over one relatively
small grant program. We should have just stopped this after a first pilot
year and moved on to try less controversial methods to improve knowledge
equity.

There is one analogy that comes to mind, and I'm not sure how accurate it
> is, but I wanted to share it as a thought experiment. In the 20th century,
> there was a range of technology companies that depended on scientific
> progress. Some of these companies, like IBM and Philips, then started to
> support also more fundamental research that did not necessarily always have
> a direct feed into their product pipeline. In a way, this kind of program
> has the same vibe to me: we're supporting a broader knowledge ecosystem to
> develop areas that we know are underserved (which may well be an
> understatement), without always having a direct connection to how that will
> feed into our projects, into our activities or communities. There is little
> doubt in my mind though, that in the long run the ecosystem will benefit
> from it, and we depend on that ecosystem for our work in turn.
>
> So honestly, I don't see this program much in the context of 'we need to
> help society' but rather an indirect selfish attempt to help improve the
> ecosystem that we're operating in. The conversation 'what are donors
> donating for' is equally a tricky one: I like to believe that they donate
> to us to help achieve the mission and trust us to make the choices that
> best serve this big picture.
>
> We can have long discussions whether we're the organization or funder best
> situated to fund these activities - but given the large backlog that we're
> dealing with in knowledge equity, I'm not very afraid that we'll have to
> worry about overcrowding in this space for a while. I personally think we
> may be reasonably well located for this - maybe not to be the most
> important funder, but we will have the chance to make a difference. I am
> however convinced that where it comes to climate change there are many
> other organizations that are much better positioned. Of course, this is
> likely very subjective :)
>
> Warmly,
> Lodewijk
>
> On Thu, Aug 17, 2023 at 6:39 AM Christophe Henner <
> christophe.hen...@gmail.com> wrote:
>
>> That would be a great discussion indeed to set the line.
>>
>> But it?s the different from what you started the discussion with where
>> you were saying ?we all should want?.
>>
>> I want us to make things that move the needle regarding knowledge equity
>> and that probably require outside of the projects programs.
>>
>> As to where we draw the line, that would be a terrific strategic
>> discussion but I don?t find where we had it.
>>
>> Sent from my iPhone
>>
>> On Aug 16, 2023, at 7:07 PM, Steven Walling 
>> wrote:
>>
>> ?
>>
>> On Wed, Aug 16, 2023 at 12:34?AM Christophe Henner <
>> christophe.hen...@gmail.com> wrote:
>>
>>> Hi Steven,
>>>
>>> If I may, I have a different reading on the topic. Knowledge Equity is a
>>> topic because for centuries knowledges have been destroyed, banned, etc? as
>>> such, and with our current rules with written sources, funding any
>>> organisation empowering marginalised communities is critical.
>>>
>>> If we were funding on

[Wikimedia-l] Re: Sharing an update on the Wikimedia Foundation Knowledge Equity Fund’s grantees

[Steven Walling]

On Wed, Aug 16, 2023 at 12:34 AM Christophe Henner <
christophe.hen...@gmail.com> wrote:

> Hi Steven,
>
> If I may, I have a different reading on the topic. Knowledge Equity is a
> topic because for centuries knowledges have been destroyed, banned, etc? as
> such, and with our current rules with written sources, funding any
> organisation empowering marginalised communities is critical.
>
> If we were funding only direct integration of marginalised knowledges into
> the project we would actually be missing so much.
>
> I actually appreciate the Movement funding initiatives outside the
> Movement.
>
> As Nadee said in her email, and I get a feeling it also is partly your
> point, what would be critical here would be to ensure the grantees are
> supported and encouraged in working with local or thematic Wikimedia
> Organisations.
>
> @Nadee out of curiosity, is there any staff in the Knowledge Equity Fund
> project in charge of working with grantees to increase their relationships
> with us?
>
> Thanks a lot :)
>
> Christophe
>

Christophe,

Thanks for your thoughts. I think the problem with "I actually appreciate
the Movement funding initiatives outside the Movement." is where does the
boundary of acceptable initiatives end?

For instance, should we feel comfortable creating a grants program to fight
climate change? Extreme weather events obviously threaten the stability of
the projects, and might disrupt editors from volunteering their time.
Solving world hunger and global health issues would increase the pool of
potential volunteers. We could also fund a non-profit alternative to
Starlink, to increase global Internet access to make it possible for more
people to edit the projects.

The problem is that none of these things are what donors believe they are
funding when they give us $5 from a banner on Wikipedia asking them to
support the projects.


>
> On Aug 16, 2023, at 8:36 AM, Steven Walling 
> wrote:
>
> ?
> This is really really disappointing to see. The lessons noted in the blog
> post totally miss the point as to why the Wikimedia community has objected
> to Knowledge Equity Fund. The issue is not community oversight via
> committees or visibility into the work. It?s that the work had no
> demonstrable impact on Wikimedia projects whatsoever. We all should want
> the projects to be more equitable when it comes to representing
> knowledge?it's perfectly aligned with the Wikimedia mission. This program
> is doing absolutely nothing to accomplish that.
>
> If we want to impact knowledge equity, why not say, let people working on
> underserved languages and topics apply for expense reimbursement when
> they've bought access to sources or equipment to create media for Commons?
> Or fund a huge series of edit-a-thons on BIPOC topics?
>
> If we want free knowledge created by and for people with less systemic
> privilege in the world, direct grants (given to actual Wikimedians) is
> something that the Foundation is uniquely placed to do, as opposed to
> generic lump sum grants for addressing the root causes of social injustice
> and inequity. While those are laudable problems to solve, they are not in
> fact our organization?s mission and what donors think they are funding when
> they give us money.
>
> A second Knowledge Equity round that fails to specifically address how
> each grantee and their work is going to help Wikimedia projects accomplish
> our mission is a huge misstep and a violation of the trust that the
> community and donors place in the Foundation to disburse funds. I fully
> agree that we should find ways to correct for the fact that Wikimedia
> content tends to reflect the unjust past and present of the world. We want
> the sum of *all* knowledge, not just knowledge from/for people with money
> and privilege, but this is not the way.
>
> On Thu, Aug 3, 2023 at 9:25 AM Nadee Gunasena 
> wrote:
>
>> Hi all,
>>
>> As part of the Wikimedia Foundation?s Annual Plan goal around supporting
>> knowledge equity
>> <https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/Goals/Equity#Equity_Fund>
>> by supporting regional and thematic strategies, and helping close
>> knowledge gaps, I wanted to share an update on the Knowledge Equity Fund.
>> Earlier this year, the Foundation shared learnings from the first year
>> <https://diff.wikimedia.org/2023/04/12/what-weve-learned-from-the-equity-funds-first-round/>
>> of the Knowledge Equity Fund pilot, as well as reports from our first year
>> grantees. These learnings include how we can increase visibility into the
>> work of the grantees, and also connect the grantees with Wikimedians and
>> local communities to enable greater underst

[Wikimedia-l] Re: Sharing an update on the Wikimedia Foundation Knowledge Equity Fund’s grantees

[Steven Walling]

This is really really disappointing to see. The lessons noted in the blog
post totally miss the point as to why the Wikimedia community has objected
to Knowledge Equity Fund. The issue is not community oversight via
committees or visibility into the work. It’s that the work had no
demonstrable impact on Wikimedia projects whatsoever. We all should want
the projects to be more equitable when it comes to representing
knowledge—it's perfectly aligned with the Wikimedia mission. This program
is doing absolutely nothing to accomplish that.

If we want to impact knowledge equity, why not say, let people working on
underserved languages and topics apply for expense reimbursement when
they've bought access to sources or equipment to create media for Commons?
Or fund a huge series of edit-a-thons on BIPOC topics?

If we want free knowledge created by and for people with less systemic
privilege in the world, direct grants (given to actual Wikimedians) is
something that the Foundation is uniquely placed to do, as opposed to
generic lump sum grants for addressing the root causes of social injustice
and inequity. While those are laudable problems to solve, they are not in
fact our organization’s mission and what donors think they are funding when
they give us money.

A second Knowledge Equity round that fails to specifically address how each
grantee and their work is going to help Wikimedia projects accomplish our
mission is a huge misstep and a violation of the trust that the community
and donors place in the Foundation to disburse funds. I fully agree that we
should find ways to correct for the fact that Wikimedia content tends to
reflect the unjust past and present of the world. We want the sum of *all*
knowledge, not just knowledge from/for people with money and privilege, but
this is not the way.

On Thu, Aug 3, 2023 at 9:25 AM Nadee Gunasena 
wrote:

> Hi all,
>
> As part of the Wikimedia Foundation’s Annual Plan goal around supporting
> knowledge equity
> 
> by supporting regional and thematic strategies, and helping close
> knowledge gaps, I wanted to share an update on the Knowledge Equity Fund.
> Earlier this year, the Foundation shared learnings from the first year
> 
> of the Knowledge Equity Fund pilot, as well as reports from our first year
> grantees. These learnings include how we can increase visibility into the
> work of the grantees, and also connect the grantees with Wikimedians and
> local communities to enable greater understanding and more ties to the work
> of free knowledge on the Wikimedia projects.
>
> With these learnings in mind, today we are announcing the second round of
> grantees
> 
> from the Knowledge Equity Fund. This second round includes seven grantees
> that span five regions, including the Fund’s first-ever grantees in Asia.
> This diverse group of grantees was chosen from an initial pool of 42
> nominations, which were received from across the Wikimedia movement through
> an open survey in 2022 and 2023. Each grantee aligns with one of Fund’s five
> focus areas
> ,
> identified to address persistent structural barriers experienced by
> communities of color that prevent equitable access and participation in
> open knowledge. They are also recognized nonprofits with a proven track
> record of impact in their region. The grantees include:
>
> Aliansi Masyarakat Adat Nusantara, Indonesia: The Aliansi Masyarakat Adat
> Nusantara , or the Alliance of the Indigenous
> Peoples of the Archipelago (AMAN for short), is a non-profit organization
> based in Indonesia that works on human rights, journalism, and advocacy
> issues for indigenous people.
>
> Black Cultural Archives, United Kingdom: Black Cultural Archives
>  is a Black-led archive and heritage
> center that preserves and gives access to the histories of African and
> Caribbean people in the UK.
>
> Create Caribbean Research Institute, Commonwealth of Dominica: Create
> Caribbean Research Institute is the
> first digital humanities center in the Caribbean.
>
> Criola, Brazil: Criola  is a civil society
> organization, based in Rio de Janeiro, dedicated to advocating for the
> rights of Black women in Brazilian society.
>
> Data for Black Lives, United States: Data for Black Lives
>  is a movement of activists, organizers, and
> scientists committed to the mission of using data to create concrete and
> measurable change in the lives of Black people.
>
> Filipino American National Historical Society, 

[Wikimedia-l] Re: Wikianswers Proposal

[Steven Walling]

We don’t really need to test the idea that people want to ask
factual questions in natural language. The question is: what’s the best way
to serve people who want to ask a normal human question and get an answer?

The definitive truth is that people want to search this way in the same
place they search for everything else. This is why Google and ChatGPT are
so massive while dedicated Q platforms like Quora and Yahoo Answers
haven’t done so well. (Trust me, I actually wasted a couple years working
at Quora and was a Top Writer there along with Jimmy and some other
Wikipedians. As a Quora shareholder I wish it wasn’t true, but Q sites
will never be as big as Wikipedia.)

Starting an entirely new portal for natural language questions and answers
could be a good way to experiment with Wikipedia-backed natural language
search but our ultimate goal should be to integrate it directly in
Wikipedia as soon as it moves past beta testing. Otherwise it’s just going
to end up like projects basically no normal readers directly search. Even
Commons and Wikidata are arguably total failures in this regard given how
little direct search and browse activity happens there. Starting a separate
domain and wiki is pretty much a terrible idea.

On Mon, May 15, 2023 at 6:24 PM Risker  wrote:

> I note that there are discussions going on in the Technology stream that
> very definitely touch on this topic.
>
> The first I noticed is a discussion on Wikitech-L entitled "Word
> embeddings / vector search".  The second one is a discussion point on this
> week's Tech News:   There is a recently formed team at the Wikimedia
> Foundation which will be focusing on experimenting with new tools.
> Currently they are building a prototype ChatGPT plugin that allows
> information generated by ChatGPT to be properly attributed
> 
> to the Wikimedia projects.
>
> These may be good starting points to discover what is already happening
> within the technical space, and what the thinking is on the likelihood of
> it filling the need of the proposed project. Regardless, since the project
> being proposed will require a lot of technical/developer/engineer work, it
> would be very useful to talk to the people who already have been working
> and researching in this topic area to determine if the proposed project is
> viable.
>
> Risker/Anne
>
> On Mon, 15 May 2023 at 20:41, Adam Sobieski 
> wrote:
>
>> I would share that I don't fully understand the current WMF procedure for
>> project proposals. I noticed an April 14 email in this mailing list about
>> forming a new taskforce on these topics (
>> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/thread/ZRV7MGHF4IH6LCN3DF6FF6IFMHXJTXZO/).
>> So, when it comes to expectations for a project proposal, the current WMF
>> process, procedure, and related definitions of success for a proposal, I
>> have more questions than answers.
>>
>> James, thank you. I see your points and, as envisioned, teambuilding for
>> the Wikianswers project would welcome participants from both within and
>> outside of the WMF movement. I anticipate a considerable excitement with
>> respect to combinations of AI and Wiki platforms, infrastructure, and
>> search. Hopefully the Wikianswers proposal indicates some of the
>> possibilities and opportunities in these regards to interested researchers
>> and developers (https://meta.wikimedia.org/wiki/Wikianswers).
>>
>>
>> Best regards,
>> Adam
>>
>> P.S.: Thank you for the discussion thus far. I'm still considering the
>> epistemology of which AI-generated multimodal answers would be cacheable,
>> editable, and thus correctable by a community of editors.
>>
>> --
>> *From:* James Heilman 
>> *Sent:* Monday, May 15, 2023 6:28 PM
>> *To:* Wikimedia Mailing List 
>> *Subject:* [Wikimedia-l] Re: Wikianswers Proposal
>>
>> Setting up a project outside the WMF would be much easier to start with.
>> One can then trial the idea and if successful the movement may then be
>> willing to have the WMF take it on.
>>
>> WikiVoyage started outside the WMF by a small group in Germany (after
>> they split from WikiTravel). They had an active community and simply
>> migrated to WMF servers.
>>
>> Similarly we at Wiki Project Med have started NC Commons
>> https://nccommons.org/wiki/Main_Page Will the movement be interested in
>> this project at some point? I guess we will see.
>>
>> James
>>
>> On Tue, May 16, 2023 at 3:16 AM Risker  wrote:
>>
>> My plate is full at the moment, and project creation is not a specific
>> interest of mine.  I hope that Adam does not see things as demotivating;
>> creating a new project type *should* be a big challenge. I do think that
>> those standards need to be significantly revised.  They were all written at
>> a time when the WMF had no problems at all just raising the target for
>> fundraising, 

[Wikimedia-l] Re: Bing-ChatGPT

[Steven Walling]

On Sat, Mar 18, 2023 at 3:49 PM Erik Moeller  wrote:

> On Fri, Mar 17, 2023 at 7:05 PM Steven Walling 
> wrote:
>
> > IANAL of course, but to me this implies that responsibility for the
> *egregious* lack
> > of attribution in models that rely substantially on Wikipedia is
> violating the Attribution
> > requirements of CC licenses.
>
> Morally, I agree that companies like OpenAI would do well to recognize
> and nurture the sources they rely upon in training their models.
> Especially as the web becomes polluted with low quality AI-generated
> content, it would seem in everybody's best interest to sustain the
> communities and services that make and keep high quality information
> available. Not just Wikimedia, but also the Internet Archive, open
> access journals and preprint servers, etc.
>
> Legally, it seems a lot murkier. OpenAI in particular does not
> distribute any of its GPT models. You can feed them prompts by various
> means, and get responses back. Do those responses plagiarize
> Wikipedia?
>
> With image-generating models like Stable Diffusion, it's been found
> that the models sometimes generate output nearly indistinguishable
> from source material [1]. I don't know if similar studies have been
> undertaken for text-generating models yet. You can certainly ask GPT-4
> to generate something that looks like a Wikipedia article -- here are
> example results for generating a random Wikipedia article:
>
> Article: https://en.wikipedia.org/wiki/The_Talented_Mr._Ripley_(film)
> GPT-4 <https://en.wikipedia.org/wiki/The_Talented_Mr._Ripley_(film)GPT-4>
> run 1: https://en.wikipedia.org/wiki/User:Eloquence/GPT4_Example/1
> (cut off at the ChatGPT generation limit)
> GPT-4 run 2: https://en.wikipedia.org/wiki/User:Eloquence/GPT4_Example/2
> GPT-4 <https://en.wikipedia.org/wiki/User:Eloquence/GPT4_Example/2GPT-4>
> run 3: https://en.wikipedia.org/wiki/User:Eloquence/GPT4_Example/3
>
> It imitates the form of a Wikipedia article & mixes up / makes up
> assertions, but I don't know that any of its generations would meet
> the standard of infringing on the Wikipedia article's copyright. IANAL
> either, and as you say, the legal landscape is evolving rapidly.
>
> Warmly,
> Erik


The whole thing is definitely a hot mess. If the remixing/transformation by
the model is a derivative work, it means OpenAI is potentially violating
the ShareAlike requirement by not distributing the text output as CC. But
on other hand the nature of the model means they’re combining CC and non
free works freely / at random, unless a court would interpret whatever % of
training data comes from us as the direct degree to which the model output
is derived from Wikipedia. Either way it’s going to be up to some legal
representation of copyright holders to test the boundaries here.


> [1]
> https://arstechnica.com/information-technology/2023/02/researchers-extract-training-images-from-stable-diffusion-but-its-difficult/
> ___
> Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines
> at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/CO3IJWXGHTBP3YE7AKUHHKPAL5HA56IC/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/4BZ5B4DFK3HTWM6CHPZ4Q4RDZIGIN26V/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: Bing-ChatGPT

[Steven Walling]

requirements
>>
>>- Running LLaMA 7B and 13B on a 64GB M2 MacBook Pro with llama.cpp
>><https://til.simonwillison.net/llms/llama-7b-m2>
>>- Github: bloomz.cpp <https://github.com/NouamaneTazi/bloomz.cpp> &
>>llama.cpp <https://github.com/ggerganov/llama.cpp> (C++ only versions)
>>- Int-4 LLaMa is not enough - Int-3 and beyond
>><https://nolanoorg.substack.com/p/int-4-llama-is-not-enough-int-3-and>
>>- How is LLaMa.cpp possible?
>><https://finbarrtimbers.substack.com/p/how-is-llamacpp-possible>
>>
>>
>> 4.) Easy-to-use interfaces
>>
>>- Transformer.js <https://xenova.github.io/transformers.js/> (WebAssembly
>>libraries to run LLM models in the browser)
>>- Dalai <https://github.com/cocktailpeanut/dalai>  ( run LLaMA and
>>Alpaca in own computer as Node.js web service)
>>- web-stable-diffusion
>><https://github.com/mlc-ai/web-stable-diffusion> (stable diffusion
>>image generation in browser)
>>
>>
>> Br,
>> -- Kimmo Virtanen
>>
>> On Fri, Mar 17, 2023 at 1:53 PM Kimmo Virtanen 
>> wrote:
>>
>> Hi,
>>
>> The development of open-source large language models is going forward.
>> The GPT-4 was released and it seems that it passed the Bar exam and tried
>> to hire humans to solve catchpas which were too complex to it. However, the
>> development in open source and hacking side has been pretty fast and it
>> seems that there is all the pieces for running LLM models in personal
>> hardware (and in web browser). Biggest missing piece is fine tuning of
>> open source model such as Neox for english language. For multilingual and
>> multimodal (for example images+text) the model is also needed.
>>
>>
>> So this is kind of link dump for relevant things for creation of open
>> source LLM model and service and also recap where hacker community is now.
>>
>>
>> 1.) Creation of an initial unaligned model.
>>
>>- Possible models
>>   - 20b Neo(X) <https://github.com/EleutherAI/gpt-neox> by
>>   EleutherAI (Apache 2.0)
>>   - Fairseq Dense <https://huggingface.co/KoboldAI/fairseq-dense-13B> by
>>   Facebook (MIT-licence)
>>   - LLaMa
>>   <https://ai.facebook.com/blog/large-language-model-llama-meta-ai/> by
>>   Facebook (custom license, leaked research use only)
>>   - Bloom <https://huggingface.co/bigscience/bloom> by Bigscience (custom
>>   license <https://huggingface.co/spaces/bigscience/license>. open,
>>   non-commercial)
>>
>>
>> 2.) Fine-tuning or align
>>
>>- Example: Standford Alpaca is ChatGPT fine-tuned LLaMa
>>   - Alpaca: A Strong, Replicable Instruction-Following Model
>>   <https://crfm.stanford.edu/2023/03/13/alpaca.html>
>>   - Train and run Stanford Alpaca on your own machine
>>   <https://replicate.com/blog/replicate-alpaca>
>>   - Github: Alpaca-LoRA: Low-Rank LLaMA Instruct-Tuning
>>   <https://github.com/tloen/alpaca-lora>
>>
>>
>> 3.) 8,4,3 bit-quantization of model for reduced hardware requirements
>>
>>- Running LLaMA 7B and 13B on a 64GB M2 MacBook Pro with llama.cpp
>><https://til.simonwillison.net/llms/llama-7b-m2>
>>- Github: bloomz.cpp <https://github.com/NouamaneTazi/bloomz.cpp> &
>>llama.cpp <https://github.com/ggerganov/llama.cpp> (C++ only versions)
>>- Int-4 LLaMa is not enough - Int-3 and beyond
>><https://nolanoorg.substack.com/p/int-4-llama-is-not-enough-int-3-and>
>>- How is LLaMa.cpp possible?
>><https://finbarrtimbers.substack.com/p/how-is-llamacpp-possible>
>>
>>
>> 4.) Easy-to-use interfaces
>>
>>- Transformer.js <https://xenova.github.io/transformers.js/> (WebAssembly
>>libraries to run LLM models in the browser)
>>- Dalai <https://github.com/cocktailpeanut/dalai>  ( run LLaMA and
>>Alpaca in own computer as Node.js web service)
>>- web-stable-diffusion
>><https://github.com/mlc-ai/web-stable-diffusion> (stable diffusion
>>image generation in browser)
>>
>>
>> Br,
>> -- Kimmo Virtanen
>>
>> On Mon, Mar 6, 2023 at 6:50 AM Steven Walling 
>> wrote:
>>
>>
>>
>> On Sun, Mar 5, 2023 at 8:39 PM Luis (lu.is)  wrote:
>>
>> On Feb 22, 2023 at 9:28 AM -0800, Sage Ross ,
>> wrote:
>>
>> Luis,
>&

[Wikimedia-l] Re: Bing-ChatGPT

[Steven Walling]

On Sun, Mar 5, 2023 at 8:39 PM Luis (lu.is)  wrote:

> On Feb 22, 2023 at 9:28 AM -0800, Sage Ross ,
> wrote:
>
> Luis,
>
> OpenAI researchers have released some info about data sources that
> trained GPT-3 (and hence ChatGPT): https://arxiv.org/abs/2005.14165
>
> See section 2.2, starting on page 8 of the PDF.
>
> The full text of English Wikipedia is one of five sources, the others
> being CommonCrawl, a smaller subset of scraped websites based on
> upvoted reddit links, and two unrevealed datasets of scanned books.
> (I've read speculation that one of these datasets is basically the
> Library Genesis archive.) Wikipedia is much smaller than the other
> datasets, although they did weight it somewhat more heavily than any
> other dataset. With the extra weighting, they say Wikipedia accounts
> for 3% of the total training.
>
>
> Thanks, Sage. Facebook’s recently-released LLaMa also shares some of their
> training sources, it turns out, with similar weighting for Wikipedia - only
> 4.5% of training text, but more heavily weighted than most other sources:
>
> https://twitter.com/GuillaumeLample/status/1629151234597740550
>

Those stats are undercounting, since the top source (CommonCrawl) also
itself includes Wikipedia as its third largest source.

https://commoncrawl.github.io/cc-crawl-statistics/plots/domains


> ___
> Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines
> at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/W3HAFQIMQWBZDTZL6EYZKFG3D2KL7XDL/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/6UKCJWOUR2KVTS7QZYKPMKQGONXZ72QR/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikitech-l] Re: Book creation

[Steven Walling]

On Feb 15, 2023 at 3:45:23 PM, Samuel Klein  wrote:

> I ran across another reference to our lovely, important book creation
> tools of yore, on a global Open Education forum
> 
> .
>
> What is the best place to discuss the broad, important version of this?
>  * How we support conversion to standalone formats, for reading and
> printing
>  * Clarity for Dirk (M2L ),
> PediaPress, the PDF-feature
> team, and
> other maintainers
>
> This is important to a wide range of reuse, and the uncertainty around
> what is possible, what is planned, and what is desired by various audiences
> makes it hard to make progress even when it's obvious that is important.
>

Why is it important if virtually no one used it over the years it was
available? The forum itself points out that very few people ever used these
tools. (I was one of them back in the day, and it worked ok but the use
cases were super limited, and that was true even a decade ago when
smartphones were far less ubiquitous globally.)

Generating a series of print/PDF format articles from the browser is 80% as
good with far less effort. We should take all of the engineering resources
it would require to resurrect investment in the Book creator, and instead
apply them to things like a 10X better offline reader mode for Wikipedia
apps and making sure that our apps and mobile website work incredibly well
on lower end devices. Both of those things would be much higher impact for
reaching readers who might have limited connectivity and therefore find
utility in alternative ways to access content.


>
>
>
>
> ___
> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
>
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikimedia-l] Re: Chat GPT

[Steven Walling]

On Fri, Feb 3, 2023 at 9:47 PM Gergő Tisza  wrote:

> Just to give a sense of scale: OpenAI started with a $1 billion donation,
> got another $1B as investment, and is now getting a larger investment from
> Microsoft (undisclosed but rumored to be $10B). Assuming they spent most of
> their previous funding, which seems likely, their operational costs are in
> the ballpark of $300 million per year. The idea that the WMF could just
> choose to create conversational software of a similar quality if it wanted
> seems detached from reality to me.
>

Without spending billions on LLM development to aim for a
conversational chatbot trying to pass a Turing test, we could definitely
try to catch up to the state of the art in search results. Our search
currently does a pretty bad job (in terms of recall especially). Today's
featured article in English is the Hot Chip album "Made in the Dark", and
if I enter anything but the exact article title the typeahead results are
woefully incomplete or wrong. If I ask an actual question, good luck.

Google is feeling vulnerable to OpenAI here in part because everyone can
see that their results are often full of low quality junk created for SEO,
while ChatGPT just gives a concise answer right there.

https://en.wikipedia.org/wiki/The_Menu_(2022_film) is one of the top
viewed English articles. If I search "The Menu reviews" the Google results
are noisy and not so great. ChatGPT actually gives you nothing relevant
because it doesn't know anything from 2022. If we could just manage to
display the three sentence snippet of our article about the critical
response section of the article, it would be awesome. It's too bad that the
whole "knowledge engine" debacle poisoned the well when it comes to a
Wikipedia search engine, because we could definitely do a lot to learn from
what people like about ChatGPT and apply to Wikipedia search.

___
> Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines
> at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/6OBPB7WNHKJQXXIBCK73SDXLE3DMGNMY/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/2O5USM4UIGYO6Y4LAD26SGM5AFMHYQFP/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: Chat GPT

[Steven Walling]

On Thu, Dec 29, 2022 at 4:09 PM Victoria Coleman <
vstavridoucole...@gmail.com> wrote:

> Hi everyone. I have seen some of the reactions to the narratives generated
> by Chat GPT. There is an obvious question (to me at least) as to whether a
> Wikipedia chat bot would be a legitimate UI for some users. To that end, I
> would have hoped that it would have been developed by the WMF but the
> Foundation has historically massively underinvested in AI. That said, and
> assuming that GPT Open source licensing is compatible with the movement
> norms, should the WMF include that UI in the product?


This is a cool idea but what would the goals of developing a
Wikipedia-specific generative AI be? IMO it would be nice to have a natural
language search right in Wikipedia that could return factual answers not
just links to our (often too long) articles.

OpenAI models aren’t open source btw. Some of the products are free to use
right now, but their business model is to charge for API use etc. so
including it directly in Wikipedia is pretty much a non-starter.

My other question is around the corpus that Open AI is using to train the
> bot. It is creating very fluid narratives that are massively false in many
> cases. Are they training on Wikipedia? Something else?


They’re almost certainly using Wikipedia. The answer from ChatGPT is:

“ChatGPT is a chatbot model developed by OpenAI. It was trained on a
dataset of human-generated text, including data from a variety of sources
such as books, articles, and websites. It is possible that some of the data
used to train ChatGPT may have come from Wikipedia, as Wikipedia is a
widely-used source of information and is likely to be included in many
datasets of human-generated text.”

And to my earlier question, if GPT were to be trained on Wikipedia
> exclusively would that help abate the false narratives


Who knows but we would have to develop our own models to test this idea.

>
This is a significant matter for the  community and seeing us step to it
> would be very encouraging.
>
> Best regards,
>
> Victoria Coleman
> ___
> Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines
> at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/CYPO3PEMM4FIWPNL6MRTORHZXVTS2VNN/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
>
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/G57JUOQ5S5ZHXHWJN7LPYEBZMFVMJGVO/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: WMF financial statements for 2021-2022 published

[Steven Walling]

On Wed, Nov 9, 2022 at 10:37 AM Andreas Kolbe  wrote:

> Dear WMF Finance staff,
>
> I inquired over a week ago on Meta-Wiki why the WMF is reporting a
> negative investment income (–$12 million). There has been no answer to
> date.[1]
>
> I am a layperson, but how can an investment income be negative? Would you
> mind sharing what this is about?
>

You probably didn't get a prompt answer because "how can investment income
be negative" is something you could have Googled before asking the finance
team.

Investments can lose value.* The US stock market has lost a tremendous
amount of value over the last year, so it would not be surprising that most
investments would have a negative return recently.

* https://www.investopedia.com/terms/n/negative-return.asp
https://www.finra.org/investors/investing/investing-basics/risk

I was also surprised to find that the reported increase in net assets for
> the 2021–2022 financial year was "only" $8.2 million. The third-quarter F
> tuning session published in May (based on data as of March 31) forecast a
> far higher surplus, with an increase in net assets of $25.9 million.[2]
>
> Would you mind sharing what happened in the fourth quarter to reduce the
> surplus by so much?
>
> Best wishes,
> Andreas
>
> [1]
> https://meta.wikimedia.org/wiki/Talk:Wikimedia_Foundation_reports/Financial/Audits/2021-2022_-_frequently_asked_questions
> [2]
> https://commons.wikimedia.org/w/index.php?title=File%3AF%26A_Tuning_Session_FY21-22_Q3.pdf=5
>
> On Tue, Nov 1, 2022 at 3:45 PM Andreas Kolbe  wrote:
>
>> Dear all,
>>
>> The WMF's audited financial statements are now available here:
>>
>>
>> https://upload.wikimedia.org/wikipedia/foundation/2/26/Wikimedia_Foundation_FY2021-2022_Audit_Report.pdf
>>
>> Some key figures from the page numbered 4 (page 6 in the pdf):
>>
>> – Net invest income was negative: –$12M (down $16M)
>> – Total support and revenue was $155M (down $8M due to that negative
>> investment income)
>> – Total expenses were $146M (up $34M)
>> – Salaries and wages were $88M (up $20M)
>> – Net assets at end of year increased by $8M
>>
>> For reference, the end-of-year increase in net assets forecast in the
>> third-quarter Finance & Administration tuning session deck published in May
>> 2022 was $25.9M:
>>
>>
>> https://commons.wikimedia.org/w/index.php?title=File%3AF%26A_Tuning_Session_FY21-22_Q3.pdf=5
>>
>> Best,
>> Andreas
>>
>> ___
> Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines
> at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/5M36VZBWLE6P4XCDAVL7L3FEPGNSSQNX/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/QHIQDCPCDC2D7FQROP6ACC4C2JUBP5D5/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikipedia Library] Re: Edit requirements for access

[Steven Walling]

On Thu, Jul 28, 2022 at 7:25 PM Paul S. Wilson  wrote:

> Às Sam Walton wrote, "lowering the requirements would necessitate going to
> each publisher, having them agree, and then likely signing a new agreement".
>
> This is a fruitless discussion.
>

Negotiating (or renegotiating) contractual agreements with partners is why
we have staffed partnerships and legal teams at the Wikimedia Foundation.
There are people we pay with donor funds to do nothing but this.



> On Thu, Jul 28, 2022, 5:55 PM Steven Walling 
> wrote:
>
>>
>>
>> On Thu, Jul 28, 2022 at 1:50 PM Shane Murphy 
>> wrote:
>>
>>> I'm a TWL coordinator in charge of approving applications for Project
>>> MUSE. I don't have much for feedback or a strong opinion, but here is my
>>> experience. Almost all applications I get qualify (and are approved) and
>>> when I reject an applicant I try to include a message encouraging
>>> reapplication when the applicant has more experience. I do not think that I
>>> have ever seen a reapplication in those cases, although I could be wrong.
>>> To me, that implies that many editors who do not get access either found
>>> that they did not need access or decided not to continue editing Wikipedia
>>> (I just skimmed the applications I've rejected ~25 over 5 years or so, it
>>> looks like most are not active editors anymore but a few are). I'm not sure
>>> if rejected applicants stopping editing is a great outcome, but the high
>>> rate of accepted applications and the low rate of long-term participation
>>> of rejected applications makes me think the process is working well.
>>>
>>
>> What the current process doesn’t show is the hundreds of thousands of
>> potential editors who don’t even apply.
>>
>> As another example here: voting in the Board of Trustees elections
>> requires 300 total edits and 20 recent edits. Why is Wikipedia Library
>> access more restrictive than what counts as an active volunteer we trust to
>> elect our governing board?
>>
>>
>>> Shane Murphy
>>> smmurphy
>>>
>>> On Thu, Jul 28, 2022 at 4:24 PM Paul S. Wilson 
>>> wrote:
>>>
>>>> I concur with Sam Walton's expert  observation (not conclusion):
>>>> renegotiating current legal agreements with some 80 plus generous
>>>> publishers is a much higher bar than the already nominal requirements for
>>>> Wikipedia editors to access their resources, a low bar for some 57,000
>>>> editors.
>>>>
>>>> Paul
>>>>
>>>> On Thu, Jul 28, 2022, 11:48 AM Steven Walling 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Jul 28, 2022 at 3:37 AM Sam Walton 
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm the Product Manager for The Wikipedia Library, thanks for
>>>>>> starting this conversation! Let me start by providing some background
>>>>>> context around how and why the criteria are set this way.
>>>>>>
>>>>>> Way back when the library started, it was an uphill battle to get
>>>>>> publishers to agree to participate. While some were happy to jump right 
>>>>>> in,
>>>>>> others were very wary about making their paywalled materials free for a
>>>>>> nebulous group of folks from around the world. The editing requirements
>>>>>> were primarily designed to convince those publishers that the only people
>>>>>> who would be getting access to their materials were active Wikipedia
>>>>>> editors who would be using their access primarily to contribute to
>>>>>> Wikipedia. The initial requirements were actually even higher than they 
>>>>>> are
>>>>>> today, at 1000 edits and 12 months of activity. We lowered that to 500
>>>>>> edits and 6 months around 2015 because it was clearly excessive. Last 
>>>>>> year
>>>>>> we added the 10+ edits/month and no active blocks criteria as we shifted
>>>>>> ~half of the publishers to the instant-access model where no applications
>>>>>> are required. I think those two criteria are pretty minor compared to 
>>>>>> 500/6
>>>>>> (if you don't meet the 10 edits criteria you can make them all in the 
>>>>>> space
>>>>>> of an hour and get access again right away).
>&g

[Wikipedia Library] Re: Edit requirements for access

[Steven Walling]

On Thu, Jul 28, 2022 at 1:50 PM Shane Murphy  wrote:

> I'm a TWL coordinator in charge of approving applications for Project
> MUSE. I don't have much for feedback or a strong opinion, but here is my
> experience. Almost all applications I get qualify (and are approved) and
> when I reject an applicant I try to include a message encouraging
> reapplication when the applicant has more experience. I do not think that I
> have ever seen a reapplication in those cases, although I could be wrong.
> To me, that implies that many editors who do not get access either found
> that they did not need access or decided not to continue editing Wikipedia
> (I just skimmed the applications I've rejected ~25 over 5 years or so, it
> looks like most are not active editors anymore but a few are). I'm not sure
> if rejected applicants stopping editing is a great outcome, but the high
> rate of accepted applications and the low rate of long-term participation
> of rejected applications makes me think the process is working well.
>

What the current process doesn’t show is the hundreds of thousands of
potential editors who don’t even apply.

As another example here: voting in the Board of Trustees elections requires
300 total edits and 20 recent edits. Why is Wikipedia Library access more
restrictive than what counts as an active volunteer we trust to elect our
governing board?


> Shane Murphy
> smmurphy
>
> On Thu, Jul 28, 2022 at 4:24 PM Paul S. Wilson 
> wrote:
>
>> I concur with Sam Walton's expert  observation (not conclusion):
>> renegotiating current legal agreements with some 80 plus generous
>> publishers is a much higher bar than the already nominal requirements for
>> Wikipedia editors to access their resources, a low bar for some 57,000
>> editors.
>>
>> Paul
>>
>> On Thu, Jul 28, 2022, 11:48 AM Steven Walling 
>> wrote:
>>
>>>
>>>
>>> On Thu, Jul 28, 2022 at 3:37 AM Sam Walton 
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm the Product Manager for The Wikipedia Library, thanks for starting
>>>> this conversation! Let me start by providing some background context around
>>>> how and why the criteria are set this way.
>>>>
>>>> Way back when the library started, it was an uphill battle to get
>>>> publishers to agree to participate. While some were happy to jump right in,
>>>> others were very wary about making their paywalled materials free for a
>>>> nebulous group of folks from around the world. The editing requirements
>>>> were primarily designed to convince those publishers that the only people
>>>> who would be getting access to their materials were active Wikipedia
>>>> editors who would be using their access primarily to contribute to
>>>> Wikipedia. The initial requirements were actually even higher than they are
>>>> today, at 1000 edits and 12 months of activity. We lowered that to 500
>>>> edits and 6 months around 2015 because it was clearly excessive. Last year
>>>> we added the 10+ edits/month and no active blocks criteria as we shifted
>>>> ~half of the publishers to the instant-access model where no applications
>>>> are required. I think those two criteria are pretty minor compared to 500/6
>>>> (if you don't meet the 10 edits criteria you can make them all in the space
>>>> of an hour and get access again right away).
>>>>
>>>> Unfortunately, lowering the requirements isn't quite as easy as simply
>>>> making an internal/community decision. Almost all publishers who provide
>>>> access via the library sign an agreement with us. We don't pay for access,
>>>> so adding new publishers is entirely dependent on convincing them to join
>>>> the program. That agreement currently includes the editor activity
>>>> criteria. This means lowering the requirements would necessitate going to
>>>> each publisher, having them agree, and then likely signing a new agreement.
>>>> This was enough of a challenge when we made the 2015 change, but by now we
>>>> have something like 80 partnerships and the criteria need to be the same
>>>> for all publishers, so this would be quite the undertaking. That's not to
>>>> say it isn't worth the effort, I just want to clarify what's required.
>>>>
>>>> In terms of who qualifies under the current criteria, the figure is
>>>> somewhere around 57,000 active editors in total today, obviously with more
>>>> receiving the eligibility notification each day.
>>>>
>&g

[Wikipedia Library] Re: Edit requirements for access

[Steven Walling]

t of edits we are
>>> looking for or adjusting them per-resource though that might get
>>> messy. For example, people who are creating articles need to have a
>>> different, and one could possibly argue higher, level of Wikipedia
>>> literacy and familiarity than someone doing automated edits. They're
>>> both valuable! But may have different needs w/r/t the Library.
>>>
>>> As someone who approves people for a few different WL resources, I see
>>> basically two kinds of applicants
>>>
>>> - People who just apply for access to ALL WL resources and just are
>>> rolling the dice about whether they'll be accepted. What they apply
>>> for doesn't match their areas of interest or expertise or even editing
>>> areas, or their qualifying edits are all profile page edits
>>> - People who apply for a narrowly-tailored set of resources that match
>>> their editing expertise
>>>
>>> I guess the larger question is whether WL resource access is seen as a
>>> perq for longer time editors or if it's supposed to just be a tool to
>>> help people edit Wikipedia.
>>>
>>
>> Thanks for sharing that's valuable to hear. I would put money on the fact
>> that a lot of helpful new editors who don't yet qualify wouldn't even
>> bother to apply, for lack of awareness or just giving up after seeing the
>> requirements on the main landing page.
>>
>> Your larger question is definitely the right one. I would say that if our
>> mission is to give everyone on the planet free access to the sum of all
>> knowledge, we need to treat it like a resource that's available to anyone
>> who wants to make a good faith effort to create and edit articles. The bar
>> for access should be the minimum necessary to ensure that you've shown real
>> interest and ability to make use of the library. If there are limits on the
>> volume of editors who can participate, there are other tools we can use
>> like making access expire if you don't use it. (Do we do that already?
>> Pardon my ignorance here.)
>>
>>
>>>
>>> _
>>> Jessamyn West
>>> User:Jessamyn
>>> box 345, randolph vt 05060
>>>
>>> On Wed, Jul 27, 2022 at 4:26 PM Steven Walling 
>>> wrote:
>>> >
>>> > I wanted to start a discussion on lowering the threshold for access.
>>> Very very very few people qualify for the current requirements of 500+
>>> edits, 6+ months editing, 10+ edits in the last month, and no active
>>> blocks. In fact basically this excludes any new editor no matter how good
>>> faith and helpful they have been. Even just lowering one of the account age
>>> or edit count thresholds would go a long way.
>>> >
>>> > I recently was pretty shocked to discover this high of a bar for
>>> access, after recommending the library as a resource to a new editor who
>>> has been doing a great job and (as a young student) could use access to
>>> academic source material in creating science-related content. I won't name
>>> them, but as an example this editor has over 300 edits and has created just
>>> over 50 articles, mainly for missing plant species.
>>> >
>>> > Do the participating institutions require this level of exclusionary
>>> criteria? How can we gather data to show them that there are good content
>>> contributors being excluded here?
>>> >
>>> > These requirements seem pretty absurd especially since many of the
>>> largest resources in the Library, like JSTOR, give any random person with a
>>> Google account access to 100 free articles per month. The risk profile of a
>>> Wikipedia who say has,100 edits and 1 month of experience has got to be
>>> less than that? We should pilot a threshold like that.
>>> >
>>> > Steven
>>> > ___
>>> > Wikipedia-Library mailing list --
>>> wikipedia-library@lists.wikimedia.org
>>> > To unsubscribe send an email to
>>> wikipedia-library-le...@lists.wikimedia.org
>>> ___
>>> Wikipedia-Library mailing list -- wikipedia-library@lists.wikimedia.org
>>> To unsubscribe send an email to
>>> wikipedia-library-le...@lists.wikimedia.org
>>>
>> ___
>> Wikipedia-Library mailing list -- wikipedia-library@lists.wikimedia.org
>> To unsubscribe send an email to
>> wikipedia-library-le...@lists.wikimedia.org
>>
>
>
> --
> Sam Walton
> Senior Product Manager, Moderator Tools
>
> swal...@wikimedia.org
>
>
___
Wikipedia-Library mailing list -- wikipedia-library@lists.wikimedia.org
To unsubscribe send an email to wikipedia-library-le...@lists.wikimedia.org

[Wikipedia Library] Re: Edit requirements for access

[Steven Walling]

On Wed, Jul 27, 2022 at 1:38 PM J West  wrote:

> I can absolutely see lowering the number of edits required, but it
> might also be worth looking at or adjusting what sort of edits we are
> looking for or adjusting them per-resource though that might get
> messy. For example, people who are creating articles need to have a
> different, and one could possibly argue higher, level of Wikipedia
> literacy and familiarity than someone doing automated edits. They're
> both valuable! But may have different needs w/r/t the Library.
>
> As someone who approves people for a few different WL resources, I see
> basically two kinds of applicants
>
> - People who just apply for access to ALL WL resources and just are
> rolling the dice about whether they'll be accepted. What they apply
> for doesn't match their areas of interest or expertise or even editing
> areas, or their qualifying edits are all profile page edits
> - People who apply for a narrowly-tailored set of resources that match
> their editing expertise
>
> I guess the larger question is whether WL resource access is seen as a
> perq for longer time editors or if it's supposed to just be a tool to
> help people edit Wikipedia.
>

Thanks for sharing that's valuable to hear. I would put money on the fact
that a lot of helpful new editors who don't yet qualify wouldn't even
bother to apply, for lack of awareness or just giving up after seeing the
requirements on the main landing page.

Your larger question is definitely the right one. I would say that if our
mission is to give everyone on the planet free access to the sum of all
knowledge, we need to treat it like a resource that's available to anyone
who wants to make a good faith effort to create and edit articles. The bar
for access should be the minimum necessary to ensure that you've shown real
interest and ability to make use of the library. If there are limits on the
volume of editors who can participate, there are other tools we can use
like making access expire if you don't use it. (Do we do that already?
Pardon my ignorance here.)


>
> _
> Jessamyn West
> User:Jessamyn
> box 345, randolph vt 05060
>
> On Wed, Jul 27, 2022 at 4:26 PM Steven Walling 
> wrote:
> >
> > I wanted to start a discussion on lowering the threshold for access.
> Very very very few people qualify for the current requirements of 500+
> edits, 6+ months editing, 10+ edits in the last month, and no active
> blocks. In fact basically this excludes any new editor no matter how good
> faith and helpful they have been. Even just lowering one of the account age
> or edit count thresholds would go a long way.
> >
> > I recently was pretty shocked to discover this high of a bar for access,
> after recommending the library as a resource to a new editor who has been
> doing a great job and (as a young student) could use access to academic
> source material in creating science-related content. I won't name them, but
> as an example this editor has over 300 edits and has created just over 50
> articles, mainly for missing plant species.
> >
> > Do the participating institutions require this level of exclusionary
> criteria? How can we gather data to show them that there are good content
> contributors being excluded here?
> >
> > These requirements seem pretty absurd especially since many of the
> largest resources in the Library, like JSTOR, give any random person with a
> Google account access to 100 free articles per month. The risk profile of a
> Wikipedia who say has,100 edits and 1 month of experience has got to be
> less than that? We should pilot a threshold like that.
> >
> > Steven
> > ___
> > Wikipedia-Library mailing list -- wikipedia-library@lists.wikimedia.org
> > To unsubscribe send an email to
> wikipedia-library-le...@lists.wikimedia.org
> ___
> Wikipedia-Library mailing list -- wikipedia-library@lists.wikimedia.org
> To unsubscribe send an email to
> wikipedia-library-le...@lists.wikimedia.org
>
___
Wikipedia-Library mailing list -- wikipedia-library@lists.wikimedia.org
To unsubscribe send an email to wikipedia-library-le...@lists.wikimedia.org

[Wikipedia Library] Edit requirements for access

[Steven Walling]

I wanted to start a discussion on lowering the threshold for access. Very
very very few people qualify for the current requirements of 500+ edits, 6+
months editing, 10+ edits in the last month, and no active blocks. In fact
basically this excludes any new editor no matter how good faith and helpful
they have been. Even just lowering one of the account age or edit count
thresholds would go a long way.

I recently was pretty shocked to discover this high of a bar for access,
after recommending the library as a resource to a new editor who has been
doing a great job and (as a young student) could use access to academic
source material in creating science-related content. I won't name them, but
as an example this editor has over 300 edits and has created just over 50
articles, mainly for missing plant species.

Do the participating institutions require this level of exclusionary
criteria? How can we gather data to show them that there are good content
contributors being excluded here?

These requirements seem pretty absurd especially since many of the largest
resources in the Library, like JSTOR, give any random person with a Google
account access to 100 free articles per month. The risk profile of a
Wikipedia who say has,100 edits and 1 month of experience has got to be
less than that? We should pilot a threshold like that.

Steven
___
Wikipedia-Library mailing list -- wikipedia-library@lists.wikimedia.org
To unsubscribe send an email to wikipedia-library-le...@lists.wikimedia.org

[Wikimedia-l] Re: Simplifying governance processes

[Steven Walling]

On Thu, May 19, 2022 at 6:25 PM effe iets anders 
wrote:

> The proposals that you list are a bit double edged. It may be necessary,
> but they have downsides. For example, there are in a few cases very good
> reasons to go back to the drawing board when we're talking about
> foundational documents. It is annoying that it takes so long, but with time
> we also should see increased ownership and an increased support base.
> Having a single phase reduces the number of messages and time spent, but it
> also reduces the process to a single point of failure, making it much
> higher stakes. If you don't participate, you're too late. It would be nice
> if we can somehow still lower the stakes by making processes more
> iterative, and accepting that the outcome does not have to be the same for
> a long period of time. But there is a fundamental tension between speed and
> perceived pressure.
>

Do we really think that the dramatic increase in process has resulted in
commensurately better community participation and buy-in? Doesn’t seem like
it. Seems like we still get the same relatively tiny number voices who care
a lot about global governance structure, and everyone else in the community
mostly just votes when advertised to.

In any case, taking multiple years to do things like even outline what say,
a code of conduct committee or global council (I still have no clue WTF
that really is) will even look like and do is egregiously slow by any
standard.

I'm less concerned about elections, if only one of these rounds involves
> the community. If having an additional round of filtering helps to make the
> ballot easier to digest (reduced to six candidates for three positions
> sounds great to me!) that also means less mental effort for voters. The
> real question is: how much cumulative time are we spending on this process
> (or rather: should we be spending on this, if we want a good outcome). If
> 100 people spend an extra 2 hour to trim down from 30 to 6 candidates, that
> is worth it, because 10,000 people don't have to read 30 statements, bio's,
> Q's etc. If we go from 7 to 6 candidates, maybe less so.
> If doing another drafting round means 30 people spend an extra 10 hours
> drafting, that may be worth it, if it means that 1000 people don't have to
> be frustrated for a year because they constantly run into consequences of
> the policy and have to go through protests to get it changed. If the
> iteration for things that don't work is more lightweight, maybe we can just
> try it for a year, and evaluate after that.
>
> Maybe it's worth it to sometimes take a napkin and do the math: how much
> collective time are we going to spend on this?
>
> Best,
> Lodewijk
>
> On Thu, May 19, 2022 at 5:12 PM Steven Walling 
> wrote:
>
>>
>>
>> On Thu, May 19, 2022 at 4:35 PM Nathan  wrote:
>>
>>>
>>>
>>> On Thu, May 19, 2022 at 5:38 PM Steven Walling 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Thu, May 19, 2022 at 10:27 AM Evelin Heidel 
>>>> wrote:
>>>>
>>>>> +1 to this, my perception is that we're wasting a lot of volunteer's +
>>>>> staff time + resources into complex governance processes without clear
>>>>> results. In theory, the reason why you want this much transparency &
>>>>> process is to make sure decision making (and in turn resources) are
>>>>> allocated fairly, but in practice so much bureaucracy makes it very hard
>>>>> for people to participate, leading to even more inequality.
>>>>>
>>>>> It's a complex balance to strike but definitely the current
>>>>> initiatives are not even a good aim to begin with.
>>>>>
>>>>> cheers,
>>>>> scann
>>>>
>>>>
>>>> 100% this.
>>>>
>>>> The intentions behind the complex governance processes are good in that
>>>> they intend to increase inclusivity. But it’s easy to forget the most
>>>> limited resource we have is the attention of volunteers. The groups we
>>>> include the least today have the least free time and money. Longer,
>>>> multi-step processes to form and elect committees to set up committees to
>>>> review processes to inform a decision then has exactly the opposite of the
>>>> intended effect because it reduces participation to the slim group of
>>>> people who have the time and patience for such a process. The CIA wrote a
>>>> manual about how to sabotage organizations, and it’s like they wrote a
>>>> perfect description of exactly how things operate right now: "When
>>>

[Wikimedia-l] Re: Simplifying governance processes

[Steven Walling]

On Thu, May 19, 2022 at 4:35 PM Nathan  wrote:

>
>
> On Thu, May 19, 2022 at 5:38 PM Steven Walling 
> wrote:
>
>>
>>
>> On Thu, May 19, 2022 at 10:27 AM Evelin Heidel 
>> wrote:
>>
>>> +1 to this, my perception is that we're wasting a lot of volunteer's +
>>> staff time + resources into complex governance processes without clear
>>> results. In theory, the reason why you want this much transparency &
>>> process is to make sure decision making (and in turn resources) are
>>> allocated fairly, but in practice so much bureaucracy makes it very hard
>>> for people to participate, leading to even more inequality.
>>>
>>> It's a complex balance to strike but definitely the current initiatives
>>> are not even a good aim to begin with.
>>>
>>> cheers,
>>> scann
>>
>>
>> 100% this.
>>
>> The intentions behind the complex governance processes are good in that
>> they intend to increase inclusivity. But it’s easy to forget the most
>> limited resource we have is the attention of volunteers. The groups we
>> include the least today have the least free time and money. Longer,
>> multi-step processes to form and elect committees to set up committees to
>> review processes to inform a decision then has exactly the opposite of the
>> intended effect because it reduces participation to the slim group of
>> people who have the time and patience for such a process. The CIA wrote a
>> manual about how to sabotage organizations, and it’s like they wrote a
>> perfect description of exactly how things operate right now: "When
>> possible, refer all matters to committees for further study and
>> consideration. Attempt to make the committee as large as possible–never
>> less than five."[1]
>>
>> The other reason we ended up in this situation is simply a lack of strong
>> leadership. People feel like they don't have the permission or safety to do
>> things unless they've done the maximum amount of consultations possible.
>> This is why decisions flounder in limbo for a long time, with no one really
>> knowing if they are happening or not happening. We're stuck because we're
>> trying to reset our governance to solve the problem where it's unclear who
>> is able to decide what and when... but we're trying to solve that by
>> perpetually punting a decision to some other committee or council of
>> people. It's turtles all the way down.
>>
>> 1:
>> https://www.openculture.com/2022/01/read-the-cias-simple-sabotage-field-manual.html
>>
>>
> I think that means we need to acknowledge some culpability for this
> phenomena - in environments like this list, folks learn that no decision is
> too benign to spark controversy and any actually controversial decision is
> guaranteed to garner a vitriolic backlash.
>
> Combine that with the normal tendencies of bureaucracies, magnified by the
> special nature of the WMF, and the result is explosive growth in
> distributed decision-making organs.
>
> Accurate insights from SJ and others, if not necessarily new, but unlikely
> to lead to change because all the incentives that led to this place remain.
>

Yes completely true.

Some of the other bullet points in that guide to sabotage are things like
“argue over precise wordings of things” that are endemic to the culture of
the projects for reasons that may be  unfixable.

Coming back to SJ’s original point, the tangible immediate kind of changes
the Board and Maryana could enforce are:

- Set more aggressive deadlines for forming new governance bodies and
policies. None of these processes should take multiple years to get
running.
- Reduce the number of pre-planned stages of duplicative feedback /
drafting periods.
- Where elections are necessary just do a single round of ranked choice
voting after an open call for candidates.

What else?

___
> Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines
> at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/UKFPEJYU5HYLOGFMJFTPPLVG5LBAUVI4/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/OFOOIXKTBQDHIYT473MKR4UL35VHBFNW/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: Simplifying governance processes

[Steven Walling]

On Thu, May 19, 2022 at 10:27 AM Evelin Heidel 
wrote:

> +1 to this, my perception is that we're wasting a lot of volunteer's +
> staff time + resources into complex governance processes without clear
> results. In theory, the reason why you want this much transparency &
> process is to make sure decision making (and in turn resources) are
> allocated fairly, but in practice so much bureaucracy makes it very hard
> for people to participate, leading to even more inequality.
>
> It's a complex balance to strike but definitely the current initiatives
> are not even a good aim to begin with.
>
> cheers,
> scann


100% this.

The intentions behind the complex governance processes are good in that
they intend to increase inclusivity. But it’s easy to forget the most
limited resource we have is the attention of volunteers. The groups we
include the least today have the least free time and money. Longer,
multi-step processes to form and elect committees to set up committees to
review processes to inform a decision then has exactly the opposite of the
intended effect because it reduces participation to the slim group of
people who have the time and patience for such a process. The CIA wrote a
manual about how to sabotage organizations, and it’s like they wrote a
perfect description of exactly how things operate right now: "When
possible, refer all matters to committees for further study and
consideration. Attempt to make the committee as large as possible–never
less than five."[1]

The other reason we ended up in this situation is simply a lack of strong
leadership. People feel like they don't have the permission or safety to do
things unless they've done the maximum amount of consultations possible.
This is why decisions flounder in limbo for a long time, with no one really
knowing if they are happening or not happening. We're stuck because we're
trying to reset our governance to solve the problem where it's unclear who
is able to decide what and when... but we're trying to solve that by
perpetually punting a decision to some other committee or council of
people. It's turtles all the way down.

1:
https://www.openculture.com/2022/01/read-the-cias-simple-sabotage-field-manual.html



> ___
> Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines
> at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/4ZXLHIUOCI4BCCH4PC5DZT4W2ACIWF5L/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
>
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/I45LFY7H3BYBZXVH3GQAQGBPN4DTTRJN/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: Open proxies and IP blocking

[Steven Walling]

On Sat, Apr 30, 2022 at 12:37 AM effe iets anders 
wrote:

> Hi Danny,
>
> this is great thinking. There's one more angle that I'd like to offer, but
> it would come with plenty of risks and downsides, so I'm not sure if it is
> actually viable (I guess it falls in the 'mitigate harm' category). But
> just to put it out there:
>
> One of the main reasons that we block open proxies, is because of
> sockpuppets and block evaders. What if we would somehow expose to admins
> which edits are made by open proxy? That way they can consider the entire
> picture (including a history of good faith edits) before blocking their
> edits. Down the road, that flag could become more nuanced (open proxy vs
> shared connection) but obviously it would have to remain pretty broad
> categories. There are plenty of downsides (WMF would need to keep a
> database of open proxies for one, but it would also share a small piece of
> private information about the user - we could warn them about that as they
> are saving their edit).
>
> If we are afraid primarily for rapid open proxy edits, we could use a
> tactic that is used by some social media tech companies in other settings:
> slow them down when using an identified open proxy. If we build in a 30s
> throttle or even wait time before the edit can be saved, or a 5 minute
> delay before the edit can become visible, that would take the fun out of it
> possibly. Obvious downside is that this is still annoying as hell for good
> faith users, but at least they can now request exceptions on-wiki.
>
> This family of methods risks a two class community, but I'm not sure if
> that is worse than the current situation. I'm not sure what would be the
> 'right' path either.
>
> Lodewijk
>

A throttle plus flagging proxy edits to admins are really good ideas.
Creating visibility for functionaries and ways to dial down volume without
blocking everyone entirely are the right way to allow more openness
balanced with control.

Thanks for hopping in the conversation Danny, glad to know the team is
thinking on this. The poorly designed way that proxy blocks and requesting
IPBE are communicated feels like low hanging fruit that the Foundation
design and product teams could tackle here?

On Fri, Apr 29, 2022 at 5:03 PM  wrote:
>
>> (cross-posted from
>> https://meta.wikimedia.org/wiki/Talk:No_open_proxies/Unfair_blocking#Help_from_WMF
>> )
>>
>> Hi folks, I'm DannyH from the Wikimedia Foundation. I manage the product
>> teams that build Contributor Tools -- Community Tech, Campaigns, CheckUser
>> improvements and sockpuppet detection, moderator tools on mobile web, and
>> the new incident reporting system.
>>
>> I've been reading all of these conversations, and I'm concerned about the
>> people on both sides of the issue -- the admins working to keep the
>> projects safe from bad-faith people, and the good-faith people who are
>> being blocked because of someone else's rangeblock, or because they're
>> using default network proxy features that they're not aware of.
>>
>> This problem is getting attention within the WMF. Foundation folks are
>> really concerned about what we're hearing on Wikimedia-L and in this
>> discussion, especially because there seem to be systemic issues that are
>> specifically making things harder for new users in Africa. I've got the
>> opportunity right now to assign people to make software changes to help
>> solve this problem, which is great. But now I'm trying to figure out what
>> those software changes could be, and I don't have a clear answer yet for
>> what that should be.
>>
>> So if you don't mind, I'd like to run through what I think the main
>> points are, and a list of possible directions that a solution could take,
>> and then I would love it if you could help me figure this out.
>>
>> Here's what I understand about the problem:
>>
>> * Open proxies are a vector for harassment and vandalism. Bad-faith long
>> term abusers use them to disguise their IP and evade detection. The
>> projects automatically block open proxies that they know about, to
>> discourage the bad-faith vandals.
>>
>> * There's been a big increase in proxy blocks since July 2021 on English
>> Wikipedia (and Oct 2021 on Spanish WP), because ST47ProxyBot has been
>> getting trustworthy outside data to help identify open proxies.
>>
>> * The use of open proxies on the internet is rising, partly because
>> people are becoming more concerned about their privacy. Apple has
>> introduced iCloud Private Relay, which is disguising people's IP — this is
>> currently in beta, but will probably become the default. Google is working
>> on a similar project. Our system of using IPs to identify block vandals is
>> gradually breaking down, and there will probably be a point when IPs just
>> won't be useful anymore.
>>
>> * There are a lot of good-faith users, including first-time contributors,
>> who are getting caught in these blocks. For some people, that's an annoying
>> inconvenience; for many others, 

[Wikimedia-l] Re: Open proxies and IP blocking

[Steven Walling]

On Wed, Apr 20, 2022 at 5:24 PM Risker  wrote:

>
> I'm less concerned about the "protected page" issue raised by SJ.  There
> are generally good reasons why those pages are protected.  They have either
> been the long- or short-term target of repeated vandalism (e.g.,
> biographical articles of controversial people, pages where disruptive
> editing has required the application of Arbcom or other discretionary
> sanctions, articles about today's news or are being discussed in the dark
> corners of social media, articles that have been subject to significant
> disinformation).  In almost all cases, the person trying to edit is
> directed to the talk page.
>

Yes and also at this point, the problem is not that people are generally
unaware that Wikipedia is editable by anyone. Anyway this issue is solvable
by design changes that direct anonymous or new editors to how they can
contribute to protected pages (either by registering or the Talk page as
appropriate). Proxy blocking on the other hand is entirely in the hands of
the community to fix.


>
> Risker/Anne
>
>
> On Wed, 20 Apr 2022 at 18:53, Samuel Klein  wrote:
>
>> Thanks for mentioning this Florence.  It's affected me lately too.
>> I'm not sure the Wikipedia we love is still accessible as a project to
>> most of the world, including most of us.
>>
>> -- Blocking mobile users:  I was blocked from editing on mobile twice in
>> the past two weeks.  No solution I could find to make a new account and
>> leave a comment.  No way to contact the blocking admin w/o logging in,
>> either.
>> -- Permablocked IPs.  A friend told me they were permablocked from WP.
>> looking into it, they were covered by a small IP range that had
>> been blocked for a decade.
>> -- Blocking VPNs, with large unhelpful banners.  I was just on the phone
>> an hour ago w/ someone who maintains another online encyclopedia
>> , and their normal internet access [VPN] was
>> blocked.  It took them a minute to realize they could get access by turning
>> it off.  Then the first three pages they thought to visit were protected
>> against editing. (some time ago, 14%
>>  of
>> pageviews were to protected pages; may have increased since then)
>> -- Getting an IP block exemption for people trying to avoid surveillance
>> is not easy. in theory email-for-access could work, in practice most people
>> who reasonably an exemption may not end up getting one or even hearing
>> back. A softer-security approach would be better.
>>
>> Benjamin writes:
>> > We would do well to remember that it was the incredibly low barrier to
>> entry that was the key to Wikipedia's early success.
>>
>> +++.  We are raising these barriers to [apparently] try to stave off
>> vandalism and spam.  But hard security like this can put an end to the
>> projects, for good.  There is no more definitive end than one that seems
>> mandated from within.  We need better automation, MLl models, sandboxing,
>> and triage to help us *increase* the number of people who can edit, and
>> can propose edits to protected pages, while decreasing the amount of
>> vandalism and spam that is visible to the world.
>>
>>
>> On Wed, Apr 20, 2022 at 4:22 PM Benjamin Ikuta 
>> wrote:
>>
>>>
>>>
>>> Also relevant:
>>> 
>>> https://www.lesswrong.com/posts/reitXJgJXFzKpdKyd/beware-trivial-inconveniences
>>>
>>> We would do well to remember that it was the incredibly low barrier to
>>> entry that was the key to Wikipedia's early success.
>>>
>>> I expect that even IF there's some legitimate (perhaps not unreasonably
>>> difficult, even!) way around the block, it will still discourage editing to
>>> a significant, but hard to measure, degree.
>>>
>>>
>>>
>>> On Apr 20, 2022, at 3:59 PM, Bence Damokos  wrote:
>>>
>>> Beyond the mentioned countries, this is also affecting those who have
>>> opted in to Apple’s Private Relay, which I expect will be somewhat
>>> popular/default once out of beta status. I myself am unable to edit for
>>> example - and half the time I am not bothered to workaround the issue and
>>> just give up the edit.
>>>
>>> Also, annoyingly, the block message only shows up when I try to save the
>>> page (at least on mobile), not when I start the edit, again, leading to
>>> unnecessary frustration.
>>>
>>> Best regards,
>>> Bence
>>> On Wed, 20 Apr 2022 at 20:42, Alessandro Marchetti via Wikimedia-l <
>>> wikimedia-l@lists.wikimedia.org> wrote:
>>>
 Yes, it's getting frequent and not only from people in Africa.

 I ended up to trouble-shoot these problems by mails or direct messaging
 on Facebook more and and more frequently, maybe with simple users who just
 know me or have my contact. Sometimes it looks like sharing the duties of a
 sysop or a steward with no power.

 It's getting less and less clear how pros and cons are calculated

[Wikimedia-l] Re: Open proxies and IP blocking

[Steven Walling]

On Wed, Apr 20, 2022 at 1:04 PM Benjamin Ikuta 
wrote:

>
>
> I've always thought this justification fraught with bias.
>
> Vandalism is highly visible: you can point to it and say it's a problem.
> And it's true!
>
> But the *lack* of contributions is of course, by nature, invisible.
>

This 100%

Do we need to start an RFC on Meta to change the proxy policy globally?


>
>
> On Apr 20, 2022, at 2:33 PM, "Amir E. Aharoni" <
> amir.ahar...@mail.huji.ac.il> wrote:
>
> I don't have a solution, but I just wanted to confirm that I agree fully
> with the description of the problem. I hear that this happens to people
> from Nigeria, Ghana, Kenya and some other countries almost every day.
>
> The first time I heard about it was actually around 2018 or so, but during
> the last year it has become unbearably frequent.
>
> A smarter solution is needed. I tried talking to stewards about this
> several times, and they always say something like "we know that this
> affects certain countries badly, and we know that the technology has
> changed since the mid-2000s, but we absolutely cannot allow open proxies
> because it would immediately unleash horrible vandalism on all the wikis".
> I'm sure they mean well, but this is not sustainable.
>
> --
> Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
> http://aharoni.wordpress.com
> ‪“We're living in pieces,
> I want to live in peace.” – T. Moore‬
>
>
> ‫בתאריך יום ד׳, 20 באפר׳ 2022 ב-21:21 מאת ‪Florence Devouard‬‏ <‪
> fdevou...@gmail.com‬‏>:‬
>
>> Hello friends
>>
>> Short version : We need to find solutions to avoid so many africans being
>> globally IP blocked due to our No Open Proxies policy.
>> *
>> https://meta.wikimedia.org/wiki/No_open_proxies/Unfair_blocking
>> *
>>
>>
>> Long version :
>>
>> I'd like to raise attention on an issue, which has been getting worse in
>> the past couple of weeks/months.
>>
>> Increasing number of editors getting blocked due to the No Open Proxies
>> policy [1]
>> In particular africans.
>>
>> In February 2004, the decision was made to block open proxies on Meta and
>> all other Wikimedia projects.
>>
>> According to the no open proxies policy : Publicly available proxies
>> (including paid proxies) may be blocked for any period at any time. While
>> this may affect legitimate users, they are not the intended targets and may
>> freely use proxies until those are blocked [...]
>>
>> Non-static IP addresses or hosts that are otherwise not permanent proxies
>> should typically be blocked for a shorter period of time, as it is likely
>> the IP address will eventually be transferred or dynamically reassigned, or
>> the open proxy closed. Once closed, the IP address should be unblocked.
>>
>> According to the policy page, « the Editors can be permitted to edit by
>> way of an open proxy with the IP block exempt flag. This is granted on
>> local projects by administrators and globally by stewards. »
>>
>>
>> I repeat -> ... legitimate users... may freely use proxies until
>> those are blocked. the Editors can be permitted to edit by way of an open
>> proxy with the IP block exempt flag <-- it is not illegal to edit using
>> an open proxy
>>
>>
>> Most editors though... have no idea whatsoever what an open proxy is.
>> They do not understand well what to do when they are blocked.
>>
>> In the past few weeks, the number of African editors reporting being
>> blocked due to open proxy has been VERY significantly increasing.
>> New editors just as old timers.
>> Unexperienced editors but also staff members, president of usergroups,
>> organizers of edit-a-thons and various wikimedia initiatives.
>> At home, but also during events organized with usergroup members or
>> trainees, during edit-a-thons, photo uploads sessions etc.
>>
>> It is NOT the occasional highly unlikely situation. This has become a
>> regular occurence.
>> There are cases and complains every week. Not one complaint per week.
>> Several complaints per week.
>> *This is irritating. This is offending. This is stressful. This is
>> disrupting activities organized in good faith by good people, activities
>> set-up with our donors funds. **And the disruption** is primarlly taking
>> place in a geographical region supposingly to be nurtured (per our strategy
>> for diversity, equity, inclusion blahblahblah). *
>>
>>
>> The open proxy policy page suggests that, should a person be unfairly
>> blocked, it is recommended
>>
>>- * to privately email stewards[image: (_AT_)] 
>>wikimedia.org.
>>- * or alternatively, to post a request (if able to edit, if the
>>editor doesn't mind sharing their IP for global blocks or their reasons to
>>desire privacy (for Tor usage)).
>>- * the current message displayed to the blocked editor also suggest
>>contacting User:Tks4Fish. This editor 

[Wikimedia-l] Re: Give WMF feedback on model cards

[Steven Walling]

On Thu, Mar 17, 2022 at 3:50 PM Hal Triedman 
wrote:

> Hi all,
>
> The WMF Privacy and Machine Learning Platform teams are developing model
> cards to increase visibility, transparency, and accountability of
> algorithmic decision-making on WMF platforms. The broad goal is for every
> ML model hosted by WMF to have a model card for the community and public to
> understand, discuss, and govern that model.
>
> We would love for you to give some feedback on the talk page of our
> prototype:
> https://meta.wikimedia.org/wiki/User:HTriedman_(WMF)/Language_Agnostic_Link-Based_Article_Topic_Model_Card
>
> Thanks so much!
> Hal
>

This is awesome. With all of us living our digital lives subject to so many
invisible filter bubbles this is a great approach to ensuring a good
outcome for Wikimedia readers, editors, and developers. Thanks for the work
the team is doing here!

Steven

___
> Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines
> at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/VAJLYCQYTPELZS3DBFC7HHVPW6MTPRBC/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/SKA2CO5NP23UPT5NZWUIQYNN3ZWLYOIU/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: The Wikipedia Library: Accessing free reliable sources is now easier than ever

[Steven Walling]

+1 to The Cunctator, this is wonderful. I used it thanks to the invite
notification you sent to eligible users and it was super fast to get going.
Kudos!

On Wed, Jan 19, 2022 at 12:20 PM The Cunctator  wrote:

> This is really well done. One suggestion that's probably already been made
> and may have various reasons for not including would be to add some of the
> non-paywalled libraries (like HathiTrust and the Federal Register) as
> searchable options.
>
> On Wed, Jan 19, 2022 at 12:10 PM Sam Walton  wrote:
>
>> Hi all,
>>
>> We've just published a blog post summarising the new features and
>> functionality available to active Wikipedia editors in The Wikipedia
>> Library:
>> https://diff.wikimedia.org/2022/01/19/the-wikipedia-library-accessing-free-reliable-sources-is-now-easier-than-ever/
>>
>> The Wikipedia Library is a tool providing active Wikipedia editors with
>> free access to otherwise-paywalled resources, including journals, books,
>> newspapers, magazines, and databases. Over the past 5-10 years the library
>> has built up a large collection of content from a wide range of publishers.
>>
>> In the past couple of years we've been finalising the centralised
>> Wikipedia Library tool used for accessing all this content:
>> https://wikipedialibrary.wmflabs.org/. I'm really pleased to announce
>> that we've finished work on some long-requested and planned features which
>> make it really simple to use!
>>
>> The library now has:
>>
>>- Proxy-based authentication for direct access of resources without a
>>secondary login
>>- A centralised search feature for browsing multiple collections from
>>one place
>>- An on-wiki notification to let editors know about the library when
>>they have crossed the eligibility threshold (rolling out in stages
>>throughout January)
>>
>> As the project I first joined the Wikimedia Foundation to work on years
>> ago I'm personally thrilled that we've finally been able to deploy all
>> these features!
>>
>> If you're eligible to use the library (500+ edits, 6+ months editing) you
>> can jump in and start using the library straight away. We're now working on
>> expanding and diversifying the content available in the library, so let us
>> know on the suggestions page if there are collections you want us to make
>> available: https://wikipedialibrary.wmflabs.org/suggest/
>>
>> If the tool isn't currently localised into your language, you can
>> translate it on TranslateWiki:
>> https://translatewiki.net/wiki/Translating:Wikipedia_Library_Card_Platform
>>
>> We're planning to host some Office Hours, which will be a chance to get a
>> walkthrough of how to use the library, as well as discuss your research
>> needs and requests for new collections with the team. Look out for more on
>> that in the coming weeks.
>>
>> --
>> Sam Walton
>> Product Manager, The Wikipedia Library
>>
>> swal...@wikimedia.org
>>
>> ___
>> Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines
>> at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
>> https://meta.wikimedia.org/wiki/Wikimedia-l
>> Public archives at
>> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/XW32I7VHKR5HIVNY3VG5SFT6NB2QIYTU/
>> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
>
> ___
> Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines
> at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/CXGD7RC4UNADHJK37YDFBLCE4CKHDEAS/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/NVW2OUSP35L4G7Y4Y2QGGANOULBKWDRW/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: Luis Bitencourt-Emilio Joins Wikimedia Foundation Board of Trustees

[Steven Walling]

On Thu, Jan 13, 2022 at 7:40 AM Guettarda  wrote:

> Crypto + NFTs + {tech startup + disrupt + housing market} sounds like
> *just* the kind of person WMF needs on its board!
>
> Luis Bitencourt-Emilio might be a great person, and just who we need on
> the Board right now, but the optics seem terrible. Maybe I've been spending
> too much time in the wrong parts of the internet, but this collection of
> attributes seems like a cherry-picked collection of what's wrong with the
> world.
>
> Ian
>

This kind of community reaction to a board appointment from the tech sector
has happened before with Arnnon Geshuri. We should have looked at that
history and treaded more carefully.

The community has always been super skeptical of the tech industry and
people associated with it, and we should have been able to anticipate that,
and develop a communication plan to show everyone what a new board member’s
values and mindset are by having them, like… send an introductory email
immediately after their announcement? Otherwise all we have is their
twitter. Maryana’s  hiring as CEO was a good example of a positive
introductory approach that has helped the community assume good faith about
her, for instance.

If we are having trouble retaining CTOs and CPOs, the first people for the
Board and CEO to ask about why are *not* outside tech execs from
venture-backed companies. It’s the tech employees of the Foundation (those
past leaders in those roles and their entire reporting chain), community
software contributors, other leaders of influential projects like Mozilla
that have similar struggles, and potential candidates we liked for
leadership roles who declined their offers. If we need advisors with tech
skills for our incoming CEO, we have dozens of people (remember our long
defunct advisory board? Or perhaps the long-tenured technical staff who
have both expertise and Wikimedia values embedded in their bones?)

None of that work to strengthen our tech organization can be done by a
single Board member alone and it most certainly doesn’t require giving
someone a voting seat on our governing legal body. If we wanted someone so
high profile and crunched for time that they need the board seat to justify
the time spent on advising us, this guy is not it. You could find a lot of
people who—from looking at his LinkedIn—spent two years at Reddit or ran an
engineering team at MSFT who would gladly help us without being on the
board.

On Thu, Jan 13, 2022 at 10:05 AM GorillaWarfare <
> gorillawarfarewikipe...@gmail.com> wrote:
>
>> Thank you for the further details, Dariusz. What is his experience with
>> free software or open knowledge communities such as ours?
>>
>> I would also love to hear from him directly to know more about whether he
>> feels cryptocurrencies, NFTs, and such technologies have a place in the
>> Wikimedia mission. Do you know if he plans to join the conversation?
>>
>> Sincerely,
>> Molly White (User:GorillaWarfare)
>> https://en.wikipedia.org/wiki/User:GorillaWarfare
>> she/her
>>
>>
>> On Thu, Jan 13, 2022, 8:41 AM Dariusz Jemielniak 
>> wrote:
>>
>>> Dear Dan,
>>>
>>> Thank you for the feedback!
>>>
>>> The search for a trustee with an expertise in product and technology
>>> began a few months ago. One of the problems we identified was that the
>>> Wikimedia Foundation CTOs (Chief Technology Officer) are usually not
>>> staying for a long period of time, and then there was also a CPO (Chief
>>> Product Officer) transition. It was also important that the new CEO (Chief
>>> Executive Officer) would like to have a trustee with relevant experience
>>> and leadership in the tech world (as would the Board itself), but also with
>>> the understanding and experience of how technology and communities can work
>>> together, so, as you said, Reddit experience is very relevant.
>>>
>>> The other critical factor was diversity – the search was prioritizing
>>> candidates with experience outside of Silicon Valley, in non-English
>>> speaking countries, preferably from the Global South.
>>>
>>> And, of course, we also needed a commitment to spend enough time on the
>>> Board work – to be engaged and present. For example, Luis met online and
>>> offline with Wikimedia volunteers from Spanish and Portuguese-speaking
>>> communities, he is eager to help us with his knowledge and experience.
>>> Cryptocurrency and blockchains were not a factor here – the Governance
>>> Committee, and then the Board, were considering other things Luis brings to
>>> the table, the needed expertise, diversity and commitment.
>>>
>>> I personally am not particularly fond of cryptocurrencies, even though I
>>> appreciate blockchain as a technology, and support e.g. decentralized
>>> science (https://decentralized.science/). We as a movement have not had
>>> a uniform stand on this, and I’m not sure if we should, though.
>>>
>>> Best regards,
>>> Dariusz (chair of the BGC)
>>>
>>> On Thu, Jan 13, 2022 at 1:40 PM Dan Garry (Deskana) 
>>> wrote:
>>>

[Wikimedia-l] Re: Welcoming the new Wikimedia Foundation CEO

[Steven Walling]

On Tue, Sep 14, 2021 at 11:30 AM Andreas Kolbe  wrote:

> Hi Maryana,
>
> Welcome, great opening letter.
>
> You mention that you want to do some of your own volunteer editing in the
> months before you officially start, which is great.
>
> Here is an idea: between now and then, tell absolutely no one what your
> user account is called, and what articles, projects or language versions
> you are working on. I think you might find the experience invaluable.
>

This is a great suggestion. The average Wikipedia editor starts their
editing anonymously or pseudonymously with no reputation attached to their
contributions. Doing the same would give you an honest perspective on the
new contributor experience.

Good luck,
>
> Andreas
>
> On Tue, Sep 14, 2021 at 4:36 PM Maryana Iskander 
> wrote:
>
>> Dear All,
>>
>> Thank you for this opportunity to introduce myself to you.
>>
>> When I read the job position [1] for the next leader of Wikimedia
>> Foundation, I noticed that it opened with a seemingly simple statement:
>> “Knowledge belongs to all of us.” Does it, really? It’s a striking
>> statement. In an increasingly unequal and polarizing world, one in which
>> almost nothing belongs to all of us, the idea that knowledge *must *belong
>> to all is enough to capture anyone’s attention and imagination – certainly
>> mine.
>>
>> My story is shaped by a twin belief that knowledge can also set us free.
>> Shortly after I was born in Cairo, Egypt, my parents left for the United
>> States. During my time at university, graduate school, and law school, I
>> was consistently pulled towards some of society’s toughest issues – women’s
>> rights, civil rights, and the rights of prisoners. I was equally pulled by
>> the need to be effective in making change – seeking out leadership
>> positions and raising my hand and voice to change the institutions of
>> power, not just protest against them. I learned that the opportunity to
>> make meaningful impact often sits ‘in-between’ traditional spheres:
>> in-between research and teaching at Rice University, in-between healthcare
>> delivery and advocacy at Planned Parenthood, and in-between government and
>> the private sector at Harambee Youth Employment Accelerator. My time at all
>> of these organisations required listening to and learning from many diverse
>> stakeholders – including volunteers – and using my position of leadership
>> to champion often unheard voices.
>>
>>
>>
>> In 2012, I followed my heart to South Africa and its very complicated
>> society – a legacy of apartheid perpetuating deep inequality despite the
>> resilience of communities full of potential and hope, and a country with
>> one of the highest youth unemployment rates in the world. A new
>> organisation had just been formed with a big vision to close this
>> opportunity gap. I signed up, first as an unpaid volunteer, and then for
>> many years as the CEO. My job has been to cultivate a common space of trust
>> for the collective assets of the society – from government, the private
>> sector, civil society, and millions of young people – to work in a
>> coalition to tackle one of the most daunting challenges of our time. To do
>> this, we relied on an inclusive, multi-channel platform that leverages all
>> forms of technology as a way to serve communities still riddled by a basic
>> lack of access. Our successes came from the power of connection,
>> partnership, and a collective belief that young people are the solution,
>> not the problem. As I began my tenth year, I felt it was time to make space
>> for new leaders.
>>
>>
>>
>> Why am I joining the Wikimedia Foundation at this moment? There are many
>> reasons: (1) this collective of projects is growing what is perhaps the
>> most important commons infrastructure of our modern world. I am excited to
>> add my time and talents to this vision. What will it take to create – not
>> just imagine – a world in which every single human being can freely share
>> in the sum of all knowledge? (2) I have experienced first-hand that
>> distributed leadership models can usually achieve more than any group of
>> people can do on their own. I am eager to support processes that will make
>> this even more true for our movement; and (3) I am drawn to working with
>> people of integrity and commitment, who also appreciate humor and joy. I
>> can already see that I will meet new colleagues like this from all over the
>> world.
>>
>>
>>
>> My former colleagues will say that I believe progress is enabled by
>> culture: one that is founded on accountability, diversity and inclusion in
>> all its forms, and a way of working led by values. It has informed an
>> organisational humility in working with others and a relentless focus on
>> getting things done the right way – while doing the right thing.
>>
>>
>>
>> During the recruitment process, I met with a leading academic in the
>> United States named Rebecca. She told me a story of her primary school
>> teacher asking the 

[Wikimedia-l] Re: Paid editing dashboard and metrics?

[Steven Walling]

Given that it’s completely trivial to make new pseudonymous accounts how
would you propose even remotely accurate data collection to measure paid
editing?

If we are worried about the impact of paid editors on the integrity of
content, we are much better served investing even more in efforts to
dramatically strengthen our volunteer community’s ability to defend the
projects. That means better software to help each editor do more, making it
fun, easy and welcoming for new contributors, and fighting the attrition in
admins and other functionaries. If our volunteer community was larger and
healthier, the threat of paid interference would be less scary.

On Tue, Sep 7, 2021 at 7:20 PM Samuel Klein  wrote:

> Aha -- I was pointed to en:wp's List of paid editing companies
> .
> (thanks!)  This is a great resource and deserves to be better linked.   The
> page is semi-active - 4 additions in the last month, including the Olaf
> case. I've cleaned it up a bit and linked it to the German page. This
> really needs some automated scripting and tracking, at the scale of ORES...
>
> Is there any routine analysis / stats compiled of edits associated with
> these orgs, or of their activity online?
>
> On Tue, Sep 7, 2021 at 2:19 PM Samuel Klein  wrote:
>
>> Jan Böhmermann 
>> published an amazing expose on political WP editing in Germany; it gets
>> good around 15 minutes in
>> . In the video he
>> exposed the workings of a paid editing farm run (by Olaf Kosinsky (
>> Wikidata ; CheckUser discussion
>> 
>> ; archived PR-services site
>> ), an
>> excellent long-time editor with over 3 million edits.
>>
>> *We need to distinguish paid editing from general COI editing*.  Paid
>> editing is COI editing by professionals, who have strong external
>> incentives to persist, no leeway in the outcome they are aiming
>> for, experience in doing this in dozens of cases, and may have colleagues
>> who can drop in as 'uninvolved' editors to forge consensus or social
>> proof.[1]
>>
>> This is one of our great recurring challenges, siphoning off both our
>> reputation and our community.  There are many things we can do about paid
>> editing, starting with maintaining *paid-editing metrics and a dashboard*
>> of known and estimated paid editing.  We can estimate its prevalence by the
>> availabiity of services online[2]; and look for patterns of such editing on
>> wiki.  Even with large error margins, this would be a step above simply
>> waiting for outbreaks to be discovered and reacting to the visible bits of
>> the iceberg.
>>
>> What sort of metrics like this do we have already?  Who is working on
>> such things?
>> Since the above video came out, de:wp started a table of WP editing
>> services
>> .
>> It currently includes an initial dozen examples, with no estimate of
>> activity (the 1 account known to be associated with each is in most cases
>> blocked; but most have active websites soliciting work) This would be
>> useful in all languages.
>>
>> SJ
>>
>>  [1] as Melmann wrote
>> 
>>  recently:
>> "*in my experience, **all the most difficult edits are WP:PAID
>> **. Most non-paid COI
>> comes from a place of desire to make things better, and often can be
>> relatively easily guided towards a better place... [or] it is relatively
>> easy to use existing enforcement mechanisms to to correct and ultimately
>> control their behaviours. PR professionals, on the other hand, are subtle
>> and sometimes downright deceptive, and it takes lots of effort to check
>> their edits when most of the time you lack context and expertise and you
>> really have to research in depth to see their edits for what they really
>> are. I think that one of the fundamental mistakes of the current policy is
>> lumping paid editors with general COI editing as paid editors are
>> fundamentally playing on a different level in terms of PR expertise and
>> incentives*"
>>
>> [2] Just searching for this online led to ads from dozens of services.
>> The first 10 below seem to be clones of the same service (perhaps run by
>> the same farm)
>>  Elite Wiki Writers
>>  Wiki Curators
>>  Wiki Genies
>>  Wikipedia Legends
>>  Wiki Page Writing
>>  Wiki Page Creator
>>  WikiProfs
>>  Wiki Specialist LLC
>>  Wiki Writers Workshop
>>  Wikipedia Publisher
>>  Wikipedia Services
>>  360 

Re: [Wikimedia-l] Resolution about the upcoming Board elections

[Steven Walling]

On Sun, Apr 25, 2021 at 12:47 PM Erik Moeller  wrote:

> On Sun, Apr 25, 2021 at 10:35 AM Steven Walling
>  wrote:
> > So I don’t think your point is the highest priority item compared to
> deciding the
> > election / appointment for all the rest of the seats.
>
> I agree that's the more important question. Regarding the founder
> seat, I do think it would be good governance to eventually find a way
> to solve the problem it solves (preserving long term institutional
> memory & wisdom on the Board) in a manner that generalizes beyond
> Jimmy's involvement. Not only because Jimmy won't be around forever,
> but also to draw from a more diverse set of voices. That could be done
> through non-voting observers (for which there is precedent), advisors,
> the council, or some other mechanism.


Great point. This definitely makes me think about our underutilized
advisory board. There were a lot of smart people who’ve been on that board
who it seems like we never fully leveraged.

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,
> <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
>
___
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, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

Re: [Wikimedia-l] Resolution about the upcoming Board elections

[Steven Walling]

On Fri, Apr 23, 2021 at 4:24 PM Luis Villa  wrote:

> This looks like a very thoughtful start on a very thorny problem, well
> done.
>
> Given that we’re trying to diversify the board, and that Jimmy has
> recently criticized FSF for having lifetime board appointments for
> founders,* I was surprised not to see any mention in this document of
> sunsetting Jimmy’s founder seat. Making him a peer of the rest of the
> board, subject to the same terms, selection process, and requalification
> standards, rather than a first-among-equals, would potentially free up an
> additional seat to improve global board diversity and definitely be
> consistent with general best practices for non-profit governance.
>
> Has the board discussed that?
>
> Thanks-
> Luis
>
> P.S. the links on the last page of
> https://upload.wikimedia.org/wikipedia/foundation/8/83/BGC_Community_Trustee_Selection_Proposal_April_2021.pdf
> are broken.
>
> * well, he criticized them for _secretive_ board appointments, but from a
> governance perspective a lifetime founder seat is problematic regardless of
> whether it is secret/defacto (FSF) or public/de jure (WMF).
>

There’s one huge unspoken difference between the FSF and WMF that needs
acknowledgment. When you’re talking about a seat designated for a single
founder, their character, morals, and personality matters. Jimmy is not
Richard Stallman, whose bizarre behavior is more or less legendary.

I think a lot of editors look at the composition of the board (today and
historically) and are super uncomfortable with the number of expert board
members who have pretty much zero idea how the projects actually operate.
In theory the elected community seats are a check on this, but those people
are often very new to board governance.

Jimmy’s combination of deep trust with the community and his perpetual
tenure are a unique asset that far outweighs the risk he does crazy Richard
Stallman public gaffes like eat his foot cheese or defend rapists on
mailing lists. So I don’t think your point is the highest priority item
compared to deciding the election / appointment for all the rest of the
seats.

On Wed, Apr 21, 2021 at 1:45 PM Jackie Koerner 
> wrote:
>
>> Hi all,
>>
>> The Wikimedia Foundation Board of Trustees met last week to decide on a
>> plan for the 2021 Board elections. The Board Governance Committee created
>> this proposal, based on the Call for Feedback about Community Board
>> Seats.[1] Please check the related announcement for details.[2]
>>
>> The Board wants to thank the more than 800 volunteers that participated
>> in the Call for Feedback in one way or another.[3] There were almost a
>> hundred conversations in multiple languages and in multiple regions. There
>> was additional discussion on Meta, Telegram, and other channels used by
>> local communities. Three new ideas were presented by volunteers during the
>> Call. It has been very difficult to decide on every open question
>> considering the quantity and diversity of opinions received. We hope this
>> resolution feels sensible to everybody.
>>
>> In the upcoming days, the Board elections facilitation team will share
>> their ideas to support candidates and voters. Let's work together on
>> elections with high and very diverse participation!
>>
>> [1] Call for Feedback Community Board Seats
>>
>> https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Board_of_Trustees/Call_for_feedback:_Community_Board_seats/Main_report
>>
>> [2] Announcement of Board Governance Committee proposal
>>
>> https://meta.wikimedia.org/wiki/Special:MyLanguage/Wikimedia_Foundation_Board_noticeboard/2021-04-15_Resolution_about_the_upcoming_Board_elections
>>
>> [3] Call for Feedback Community Board seats metrics
>>
>> https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Board_of_Trustees/Call_for_feedback:_Community_Board_seats/Main_report#Metrics
>>
>>
>> --
>> *Jackie Koerner*
>>
>> *she/her*
>> Board Governance Facilitator
>> *English language and Meta-Wiki*
>> ___
>> 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,
>> 
>>
> ___
> 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,
> 
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages 

Re: [Wikimedia-l] Moving the technical infrastructure out of the US

[Steven Walling]

On Wed, Sep 30, 2020 at 12:22 PM Nathan  wrote:

> Well, to Steven's point that you might need a jurisdiction where corporate
> officers and employees aren't subject to extradition... I believe Germany
> does in fact have an extradition treaty with the United States.
>

The chapters do seem like the obvious potentially viable easy
solution here, if WMF set up that contingency plan.

For instance, if WMDE did take over in an emergency, then the critical
difference is that Germany doesn't extradite its own citizens to the US. So
there'd just have to be a complete handoff of primary hosting to outside
the US and some kind of agreement for WMDE (or pick your chapter) to take
over operational control. There's probably a lot that real lawyers, of
which I am not one, would know better here.


> So far the criteria I'm hearing from the comments here:
>
> 1) Politically stable
> 2) Liberal political environment
> 3) Strong protections against government interference in relevant
> operations
> 4) Section 230-like protection against liability for user content
> 5) No natural disasters like fires, floods, hurricanes, volcanoes, etc.
> 6) Strong technological sophistication - preferably a robust technology
> industry that can supply local talent for WMF needs
> 7) Protections in the law for data privacy
> 8) Availability of renewable energy sources and other resources that allow
> for operation of the WMF with a low climate impact
> 9) Tax exemption or beneficial tax structure for receiving international
> fundings by donation
> 10) Clear and reliable regulatory framework for a charitable organization
> 11) Safe - low crime, low-risk of violence for WMF stakeholders and
> community
> 12) Free from risk of extradition to the U.S. or other jurisdictions where
> criminal or civil law might be used against WMF officers or employees
>
> I would guess the list of countries that meet all of these criteria might
> be short. Norway might hit most of these except the last.
>

The only item that seems more or less impossible is preventing 5 in light
of the impacts of climate change. There is no locale on the planet that
won't suffer from severe weather and natural disasters, just some (like the
poorer countries and anywhere in the tropics) that will see worse impacts.
So the only nuance is aiming for more like "Prepared for the event of
severe weather and natural disasters" not "none".

On Wed, Sep 30, 2020 at 2:44 PM Michael Peel  wrote:
>
> > … hence the existence of Wikimedia chapters? I suspect at least WMDE
> could
> > take this on if it becomes necessary, although other chapters aren’t as
> > technologically developed as I’d have liked to have seen.
> >
> > Thanks,
> > Mike
> >
> > > On 30 Sep 2020, at 19:35, Steven Walling 
> > wrote:
> > >
> > > SJ hinted at a related problem which is that we'd also need a backup
> > > organizational structure to run things operationally and legally. If
> the
> > US
> > > becomes so politically unstable that hosting Wikimedia data is under
> > threat
> > > there, just moving the data would not be enough. You'd also have to
> > include
> > > a contingency plan that foresaw the need to legally operate the
> > Foundation
> > > (or an equivalent organization anyway) under a different jurisdiction
> > > with corporate officers not subject to US law or extradition. If the
> > > servers are hosted in the EU but the legally controlling body and its
> > > employees are within the US, you could still see them legally forced to
> > > comply with an order, just like companies are forced to do so in
> > > other countries with censorious regimes today.
> > >
> > > On Wed, Sep 30, 2020 at 8:59 AM Samuel Klein 
> wrote:
> > >
> > >> We should have technical partners in multiple other jurisdictions that
> > >> could help in a crisis, and load bearing infrastructure in at least
> one
> > of
> > >> them, and a plan for how and when to switch. (The walkthrough of what
> > would
> > >> be needed for a smooth transfer send most important, and useful for
> > general
> > >> reliability planning)
> > >>
> > >> We should also fully support and realize Wikimedia-on-ipfs, similar to
> > what
> > >> the internet archive had been doing. (Santhosh has some excellent
> ideas
> > >> there)
> > >>
> > >> 
> > >>
> > >> On Wed., Sep. 30, 2020, 5:35 a.m. Dan Garry (Deskana), <
> > djgw...@gmail.com>
> > >> wrote:
> > >>
> > >>> On Wed, 30 Sep 2020 at 09:49,

Re: [Wikimedia-l] Moving the technical infrastructure out of the US

[Steven Walling]

SJ hinted at a related problem which is that we'd also need a backup
organizational structure to run things operationally and legally. If the US
becomes so politically unstable that hosting Wikimedia data is under threat
there, just moving the data would not be enough. You'd also have to include
a contingency plan that foresaw the need to legally operate the Foundation
(or an equivalent organization anyway) under a different jurisdiction
with corporate officers not subject to US law or extradition. If the
servers are hosted in the EU but the legally controlling body and its
employees are within the US, you could still see them legally forced to
comply with an order, just like companies are forced to do so in
other countries with censorious regimes today.

On Wed, Sep 30, 2020 at 8:59 AM Samuel Klein  wrote:

> We should have technical partners in multiple other jurisdictions that
> could help in a crisis, and load bearing infrastructure in at least one of
> them, and a plan for how and when to switch. (The walkthrough of what would
> be needed for a smooth transfer send most important, and useful for general
> reliability planning)
>
> We should also fully support and realize Wikimedia-on-ipfs, similar to what
> the internet archive had been doing. (Santhosh has some excellent ideas
> there)
>
> 
>
> On Wed., Sep. 30, 2020, 5:35 a.m. Dan Garry (Deskana), 
> wrote:
>
> > On Wed, 30 Sep 2020 at 09:49, Erik Moeller  wrote:
> >
> > > I hope that some preliminary contingency plans exist or are being
> > > developed, and I'm sure that the movement-wide debate will widen if
> > > the US continues its downward slide into authoritarianism.
> > >
> >
> > I agree with Erik. Even under the Obama administration, there were
> threats
> > to the existence of the movement, such as SOPA [1] which lead to a
> blackout
> > [2]. One can extrapolate from current events that these threats could
> well
> > get larger and more frequent, rather than smaller and less frequent,
> should
> > someone in the US Government decide to focus their attention on attacking
> > Wikipedia and free knowledge. It would be prudent to create a contingency
> > plan which includes an exploration of other options for a location of
> > operation for the Wikimedia Foundation and/or its servers, with their
> > advantages and disadvantages. I personally wouldn't necessarily advocate
> > for making the plan public; that would be ideal, but I'd be comforted
> > merely to know it exists.
> >
> > On Tue, 29 Sep 2020 at 23:36, Joseph Seddon 
> > wrote:
> >
> > > I believe options are going to be explored for sustainability but right
> > now
> > > legally speaking the US is the best jurisdiction for hosting us now and
> > the
> > > foreseeable future.
> > >
> >
> > I agree with this too. For now, the United States remains the best place
> > for the organisation to operate out of, and a move should not be actively
> > considered.
> >
> > Dan
> >
> > [1]: https://en.wikipedia.org/wiki/Stop_Online_Piracy_Act
> > [2]:
> >
> >
> https://en.wikipedia.org/wiki/Protests_against_SOPA_and_PIPA#Wikimedia_community
> > ___
> > 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,
> > 
> >
> ___
> 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,
> 
>
___
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: [Wikitech-l] Logging everyone out

[Steven Walling]

Good to know it was so few people. Thanks for your diligence as always.

On Thu, Jun 25, 2020 at 10:57 PM Tim Starling 
wrote:

> On 26/6/20 3:26 pm, Steven Walling wrote:
> > Thanks Tim,
> >
> > 1. Does “saw the site” mean users actually had full or partial access to
> > the accounts of other users, or simply were viewing a cached version of
> the
> > site that appeared as if they were logged in as someone else?
>
> Users reportedly had full access to the accounts of other users.
>
> > How many users were impacted?
>
> We had three reports. We've added logging which should help to
> determine whether anyone else was affected. So far, the indications
> are that it is an extremely rare event.
>
> > 2. Does the WMF hold incident review meetings and publish reports about
> > what steps are taken to prevent repeat incidents with the same root
> cause?
>
> Incidents are documented at
> <https://wikitech.wikimedia.org/wiki/Incident_documentation>
>
> Action items are tagged with the Incident Prevention tag in Phabricator:
> <https://phabricator.wikimedia.org/project/view/4758/>
>
> Whether there is an incident review meeting depends on the nature of
> the incident.
>
> -- Tim Starling
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-ambassadors] [Wikitech-l] Logging everyone out

[Steven Walling]

Thanks Tim,

1. Does “saw the site” mean users actually had full or partial access to
the accounts of other users, or simply were viewing a cached version of the
site that appeared as if they were logged in as someone else? How many
users were impacted?

2. Does the WMF hold incident review meetings and publish reports about
what steps are taken to prevent repeat incidents with the same root cause?

On Thu, Jun 25, 2020 at 7:44 PM Tim Starling 
wrote:

> Everyone on Wikimedia wikis will shortly be logged out and will have
> to log back in again.
>
> We are resetting all sessions because we believe that, due to a
> configuration error, session cookies may have been sent in cacheable
> responses. Some users reported that they saw the site as if they were
> logged in as someone else. We believe that the number of affected
> users was very small. However, we believe that resetting all sessions
> is a prudent measure to ensure that the impact is limited.
>
> There are several layers of protection against something like this
> happening, and we don't yet know how all of them failed, but we have
> made a configuration change which should be sufficient to prevent it
> from happening again.
>
> -- Tim Starling
>
>
> ___
> Wikitech-l mailing list
> wikitec...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-ambassadors mailing list
Wikitech-ambassadors@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors

Re: [Wikitech-l] Logging everyone out

[Steven Walling]

Thanks Tim,

1. Does “saw the site” mean users actually had full or partial access to
the accounts of other users, or simply were viewing a cached version of the
site that appeared as if they were logged in as someone else? How many
users were impacted?

2. Does the WMF hold incident review meetings and publish reports about
what steps are taken to prevent repeat incidents with the same root cause?

On Thu, Jun 25, 2020 at 7:44 PM Tim Starling 
wrote:

> Everyone on Wikimedia wikis will shortly be logged out and will have
> to log back in again.
>
> We are resetting all sessions because we believe that, due to a
> configuration error, session cookies may have been sent in cacheable
> responses. Some users reported that they saw the site as if they were
> logged in as someone else. We believe that the number of affected
> users was very small. However, we believe that resetting all sessions
> is a prudent measure to ensure that the impact is limited.
>
> There are several layers of protection against something like this
> happening, and we don't yet know how all of them failed, but we have
> made a configuration change which should be sufficient to prevent it
> from happening again.
>
> -- Tim Starling
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikimedia-l] Summary of the Brand Project presentation

[Steven Walling]

I can't believe I'm saying this but I agree with Fæ as well.

Having been on the inside at some companies that underwent controversial
rebrands, I can see how this might be a very early stage thing to help
guide and shape thinking about how to approach a rebrand by unifying around
a high level concept. I can see how in the name of transparency the team
might be sharing very early stage work like that with the community, but if
that's truly what it is (early exploratory thinking, not finished work) it
would probably help to explain that this is not anywhere close to finalized
work. People who don't do brand design tend to have little patience or
interest in hand-wavy concepts without a concrete expression, Wikipedians
maybe least of all.

On Wed, Apr 22, 2020 at 2:30 AM Chris Gates via Wikimedia-l <
wikimedia-l@lists.wikimedia.org> wrote:

> As it appears my earlier email was not approved by the moderators:
>
> I'm in agreement with Fæ on this.
>
> The text and videos given on the subject of the new "interconnection" focus
> is all extremely vague. I don't see how this is a change from previous
> branding, or how the idea of "interconnection" will change anything.
> Specifically in regard to the video, I was surprised by the vagueness.
> Obviously, everything is connected. We are all humans with a majority of
> similar characteristics and a high potential for similar experiences.
> Putting together a few videos of people from different cultures
> collaborating and some videos of nature doesn't make a branding strategy.
>
> I am very happy that, in the presentation, a timeline was addressed and
> that there will be ample time for feedback on the proposed naming
> conventions. I am looking forward to that; this project has been quite
> vague for a while, and I hope there's some great ideas we can, as a
> community, discuss.
>
> Best regards,
> Chris Gates
> (User:Vermont)
>
> On Sat, Apr 18, 2020 at 1:44 PM Anders Wennersten <
> m...@anderswennersten.se>
> wrote:
>
> > I have a background in a telecom supplier, and we were proud to talk of
> > us "connecting people" and with 5G (where things also gets connected)
> > "interconenctivity" would be a great brand concept for that company.
> >
> > But for Wikimedia I have never felt this as a relevant brandconcept. To
> > "share and spread knowledge"is the core word as far as I see it and have
> > been all the time.
> >
> > Anders
> >
> >
> > Den 2020-04-18 kl. 18:44, skrev Peter Southwood:
> > > I agree. It did not seem to say anything much.
> > > Cheers,
> > > Peter
> > >
> > > -Original Message-
> > > From: Wikimedia-l [mailto:wikimedia-l-boun...@lists.wikimedia.org] On
> > Behalf Of Fæ
> > > Sent: Saturday, April 18, 2020 3:06 PM
> > > To: Wikimedia Mailing List
> > > Subject: Re: [Wikimedia-l] Summary of the Brand Project presentation
> > >
> > > Have now watched "interconnection". It did not seem to say anything
> > > tangible apart from stuff like you find 'interconnection in nature' in
> > > the 2 minutes. It was produced to a good standard.
> > >
> > > Sorry, it was not encouraging. The question remains of how much this
> > > is costing the movement in WMF funding and valuable Wikimedia
> > > community time without any clear outcomes being defined that the
> > > Wikimedia community wants or could use to benefit the core value of
> > > adding to the sum of human knowledge. Why the "rebranding" project
> > > continues at this time remains an enigma.
> > >
> > > We have gone ahead and added the video to Commons. If superseded it
> > > will remain useful as a snapshot as of 16 April.
> > >
> >
> https://commons.wikimedia.org/wiki/File:Our_unified_concept_interconnection.webm
> > >
> > > Thanks,
> > > Fae
> > >
> > > On Fri, 17 Apr 2020 at 09:57, Samir Elsharbaty
> > >  wrote:
> > >> Hi everyone,
> > >>
> > >>
> > >> Yesterday, the 2030 Brand Movement Project presented the unified
> concept
> > >> that will guide the upcoming branding proposals. Thanks to the 224
> > >> attendees who watched the presentation live! Participants brought a
> > great
> > >> stream of comments and questions (averaging 8 per minute!) that helped
> > >> clarify important points.
> > >>
> > >> The unified concept, “interconnection”, was arrived at after many
> > community
> > >> workshops, exercises, and conversations. “Interconnection” distills
> the
> > 23
> > >> distinct concepts generated in workshops into a single word that links
> > >> together the insights and definitions from the participants, and at
> the
> > >> same time adds more meaning to the answer to the question who are we?
> > This
> > >> concept will not be a public or visible part of branding, but rather a
> > >> guiding idea.
> > >>
> > >> Take a look at the video explaining interconnection as a unified
> concept
> > >> [1].
> > >>
> > >> You can watch the full presentation video, together with the lively
> > >> discussion that accompanied it [2]. Most of the questions were
> answered
> > >> during the 

Re: [Wikimedia-l] Partial blocks update

[Steven Walling]

On Thu, Sep 19, 2019 at 5:09 PM Sydney Poore  wrote:

> Hello all,
>
> The Wikimedia Foundation Anti-Harassment Tools team is wrapping up
> improvements
> to Special:Block that added the ability to set a Partial block
> <
> https://meta.wikimedia.org/wiki/Community_health_initiative/Per_user_page,_namespace,_category,_and_upload_blocking
> >
> .
>
> While no functionality has changed for sitewide blocks, Special:Block now
> allows for the ability to block a named user account or ip address from:
>
>1.
>
>Editing one or more specific page(s)
>2.
>
>Editing all pages within one or more namespace(s)
>3.
>
>Emailing other users
>
>
> Administrators on all Wikimedia projects are invited to test this new way
> of doing blocks on testwiki. Admins can reply off list to this email to
> request access to test.
>
> Administrators on wikis where partial blocks are deployed are invited to
> share with other Wikimedia administrators examples of the way that partial
> blocks are being used.
>

This is so great. Kudos to the team for adding tools to prevent abuse and
harassment that allow for more targeted policy enforcement.

How do we see which wikis have partial blocks deployed already / are
planning to have it deployed? And is there any way administrators can
request deployment?


>
>-
>
>Share on meta
>
>-
>
>Share in google form
><
> https://docs.google.com/forms/d/1PTGNGhYvMgXMdR5gfle67ojzK23EabV3Ch0FRmaNejs/edit
> >
>
> Other feedback can be left on Meta
> <
> https://meta.wikimedia.org/wiki/Community_health_initiative/Partial_blocks/Feedback
> >
> or
> by email .
>
> For the Anti-Harassment Tools team.
> Sydney
> --
> Sydney Poore (she/her)
> Strategist, socio-technical
> Wikimedia Foundation
> Trust and Safety team;
> Anti-harassment tools team
> ___
> 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,
> 
___
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] America may go bizarro, but Wikipedia has a choice to make

[Steven Walling]

Great question to think about for our long term sustainability. I think we
already have a universal "plan B" however? It's providing all content under
free licenses and regularly distributing complete dumps of our content.

Many larger and more well-funded technology organizations (Google,
Facebook, etc.) regularly do disaster recovery scenarios that account for
not just governmental disruption or civil unrest but events such as a major
earthquake in the San Francisco Bay Area. The movement doesn't really have
the resources to do this effectively in the same manner.

It seems like decentralizing our ability to recover from a disruption is
the most effective defense we have, *especially *in the scenario involving
government intervention because the Foundation's infrastructural and legal
presence in the United States is actually one of the more brittle pieces
within our movement.

On Tue, Jan 8, 2019 at 9:18 AM Fæ  wrote:

> Dear fellow Wikimedians, please sit back for a moment and ponder the
> following,
>
> For those of us not resident in the US, it has been genuinely alarming
> to see highly respected US government archives vanish overnight,
> reference websites go down, and US legislation appear to drift to
> whatever commercial interests have the loudest current political
> voices. Sadly "populism" is happening now, and dominates American
> politics, driving changes of all sorts in response to politically
> inflated and vague rhetoric about "security" and "fakenews". It is not
> inconceivable that a popularist current or future US Government could
> decide to introduce emergency controls over websites like Wikipedia,
> virtually overnight.[1][2][3][4]
>
> The question of whether the Wikimedia Foundation should have a hot
> switch option, so that if a "disaster" strikes in America, we could
> continue running Wikipedia and Wikimedia Commons from other countries
> has been raised on this list several times over many years. The WMF
> and its employees are heavily invested in staying in Silicon Valley,
> and that will stay true unless external risks become extreme.
>
> However, there has never been a rationale to avoid investing in a Plan
> B. A robust plan, where the WMF can switch operations over to a
> hosting country with a sufficiently welcoming with stable national
> government and legislation, that our projects could continue to meet
> our open knowledge goals virtually uninterrupted and without risk of
> political control. A Plan B would ensure that if the US Government
> started to discuss controlling Wikipedia, then at least that published
> plan would be a realistic response. If they tried doing it, we could
> simply power off our servers in the USA, rather than compromise our
> content.
>
> If anyone knows of committed investment in a practical WMF Plan B, it
> would be reassuring to share it more widely at this time. If not, more
> of us should be asking about it, politely, persistently but perhaps
> less patiently than indefinitely. :-)
>
> Links:
> 1. https://www.bbc.co.uk/news/world-us-canada-46739180
> 2. http://www.lse.ac.uk/ideas/research/updates/populism
> 3.
> https://www.cnet.com/news/obama-signs-order-outlining-emergency-internet-control
> "... this order was designed to empower certain governmental agencies
> with control over telecommunications and the Web during natural
> disasters and security emergencies."
> 4.
> https://www.theatlantic.com/magazine/archive/2019/01/presidential-emergency-powers/576418
> "The president could seize control of U.S. internet traffic, impeding
> access to certain websites and ensuring that internet searches return
> pro-Trump content as the top results."
> 5. Bizarro, as used in the title of this email:
> https://en.wikipedia.org/wiki/Bizarro_World
>
> Thanks,
> Fae
> --
> fae...@gmail.com https://commons.wikimedia.org/wiki/User:Fae
>
> ___
> 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,
> 
___
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: [Wikitech-l] Please comment on the draft consultation for splitting the admin role

[Steven Walling]

I'm definitely supportive of greater security for sitewide JS/CSS, but
Bart's proposal is an interesting one. (Sorry for top posting, on mobile)

What if we required review of edits to JS/CSS in the MediaWiki namespace
(not in other namespaces), ala pending changes or something similar? We
require code review in Gerrit, so why not sitewide code in the wiki?

I propose this because if we split code editing rights into a separate
userright, this entails increased process bloat for managing who and who
doesn't get the right, the criteria for deciding that, and so on. Requiring
code review would allow for more flexibility while increasing security. It
would require less process bloat too because the community already has
mechanisms for requesting edits be confirmed via talk pages and such.

On Mon, Jun 11, 2018 at 8:15 AM Bart Humphries 
wrote:

> " I remember a situation when I posted a fix for a script in the
> MediaWiki namespace
> as an {{edit request}}, and a well-meaning administrator tried to "improve"
> my line of code and forgot a comma, breaking all JavaScript for all
> logged-in as well as not logged-in Wikipedia editors and readers for some
> painful minutes"
>
> Everyone makes mistakes.  I presume that under this revised proposal, that
> administrator would still have had JS edit permission, and might have still
> made the mistake.  I mean, they apparently knew JS well enough to have been
> able to pass whatever test would have been required to get that permission
> added to their account.
>
> Perhaps we need a real test environment of some sort, so that changes like
> that must be run on the test server for X [time period] before being pushed
> to live?  Changes can't happen on live until there's some sort of consensus
> that the test code actually works as run -- any additional changes reset
> the test time period counter before it can be pushed to live.
>
> Bart Humphries
> bart.humphr...@gmail.com
> (909)529-BART(2278)
>
> On Mon, Jun 11, 2018 at 7:40 AM, Thiemo Kreuz 
> wrote:
>
> > > Is there any historical evidence that sysops being able to edit JS /
> CSS
> > caused some serious issues?
> >
> > Oh yes, this happens more often than I feel it needs to. I remember a
> > situation when I posted a fix for a script in the MediaWiki:…
> > namespace as an {{edit request}}, and a well-meaning administrator
> > tried to "improve" my line of code and forgot a comma, breaking all
> > JavaScript for all logged-in as well as not logged-in Wikipedia
> > editors and readers for some painful minutes.
> >
> > I believe such can be avoided with more clear roles that are visible
> > for everybody. A separate "tech admin" role would also allow
> > volunteers to apply for exactly that, and not be asked why they don't
> > do enough "administrator actions" with their privileges.
> >
> > Sure, this is anecdotal evidence. Please forgive me, but I currently
> > don't have the time to find the pages documenting these situation.
> >
> > Best
> > Thiemo
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikistats gets a facelift - Alpha Launch of Wikistats 2

[Steven Walling]

This is an amazing improvement. Great work!

On Thu, Dec 14, 2017 at 12:41 PM zppix e  wrote:

> Great Work I love the design. Can't wait for finished product!
>
> --
> Zppix
> Volunteer Wikimedia Developer
> Volunteer Wikimedia GCI2017 Mentor
> enwp.org/User:Zppix
> **Note: I do not work for Wikimedia Foundation, or any of its chapters.**
>
> > On Dec 14, 2017, at 1:17 PM, Jonathan Morgan 
> wrote:
> >
> > This is fabulous! Thank you, Erik Zachte, Analytics team, and everyone
> else
> > involved in this project for giving us the powerful, usable stats
> dashboard
> > we deserve :)
> >
> > - J
> >
> > On Thu, Dec 14, 2017 at 5:10 AM, Niharika Kohli 
> > wrote:
> >
> >> This is awesome. Great job A-team!
> >>
> >> On Thu, Dec 14, 2017 at 12:12 PM, Victoria Coleman <
> vcole...@wikimedia.org
> >>>
> >> wrote:
> >>
> >>> Nuria and team, fabulous work!  Wikistats 2 is such a huge improvement!
> >>> Thank you!
> >>>
> >>>
> >>> Best wishes,
> >>>
> >>> Victoria Coleman
> >>>
> >>> Chief Technology Officer
> >>> Wikimedia Foundation
> >>> 1 Montgomery Street, Suite 1600
> >>> San Francisco, CA 94104
> >>>
> >>> +1-650-703-8112 <(650)%20703-8112>
> >>>
> >>> vcole...@wikimedia.org
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
>  On Dec 13, 2017, at 8:26 PM, Nuria Ruiz  wrote:
> 
>  Hello from Analytics Team!
> 
>  We are happy to announce the Alpha release of Wikistats 2. Wikistats
> >> has
>  been redesigned for architectural simplicity, faster data processing,
> >>> and a
>  more dynamic and interactive user experience. First goal is to match
> >> the
>  numbers of the current system, and to provide the most important
> >> reports,
>  as decided by the Wikistats community (see survey) [1].  Over time, we
> >>> will
>  continue to migrate reports and add new ones that you find useful. We
> >> can
>  also analyze the data in new and interesting ways, and look forward to
>  hearing your feedback and suggestions. [2]
> 
>  You can go directly to Spanish Wikipedia
>  https://stats.wikimedia.org/v2/#/es.wikipedia.org
> 
>  or browse all projects
>  https://stats.wikimedia.org/v2/#/all-projects
> 
>  The new site comes with a whole new set of APIs, similar to our
> >> existing
>  Pageview API but with edit data. You can start using them today, they
> >> are
>  documented here:
> 
>  https://wikitech.wikimedia.org/wiki/Analytics/AQS/Wikistats
> 
> 
>  FAQ:
> 
>  Why is this an alpha?
>  There are features that we feel a full-fledged product should have
> that
> >>> are
>  still missing, such as localization. The data-processing pipeline for
> >> the
>  new Wikistats has been rebuilt from scratch (it uses
> >>> distributed-computing
>  tools such as Hadoop) and we want to see how it is used before calling
> >> it
>  final. Also while we aim to update data monthly, it will happen a few
> >>> days
>  after the month rolls because of the amount of data to move and
> >> compute.
> 
>  How about comparing data between two wikis?
>  You can do it with two tabs but we are aware this UI might not solve
> >> all
>  use cases for the most advanced Wikistats users. We aim to tackle
> those
> >>> in
>  the future.
> 
>  How do I file bugs?
>  Use the handy link in the footer:
>  https://phabricator.wikimedia.org/maniphest/task/edit/?
> >>> title=Wikistats%20Bug=Analytics-Wikistats,Analytics
> 
>  How do I comment on design?
>  The consultation on design already happened but we are still watching
> >> the
>  talk page:
>  https://www.mediawiki.org/wiki/Wikistats_2.0_Design_
> >>> Project/RequestforFeedback/Round2
> 
> 
>  [1]
>  https://www.mediawiki.org/wiki/Analytics/Wikistats/
> >>> DumpReports/Future_per_report
>  [2] https://wikitech.wikimedia.org/wiki/Talk:Analytics/
> >> Systems/Wikistats
>  ___
>  Wikitech-l mailing list
>  Wikitech-l@lists.wikimedia.org
>  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >>>
> >>> ___
> >>> Wikitech-l mailing list
> >>> Wikitech-l@lists.wikimedia.org
> >>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >>>
> >>
> >>
> >>
> >> --
> >> Niharika
> >> Software Engineer
> >> Community Tech
> >> Wikimedia Foundation
> >> ___
> >> Wikitech-l mailing list
> >> Wikitech-l@lists.wikimedia.org
> >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >>
> >
> >
> >
> > --
> > Jonathan T. Morgan
> > Senior Design Researcher
> > Wikimedia Foundation
> > User:Jmorgan (WMF) 
> > ___
> > Wikitech-l mailing list
> > 

Re: [Wikitech-l] ResistanceManual.org looking for co-maintainers

[Steven Walling]

Dear Brad,

Yes.

On Mon, Jan 30, 2017 at 6:42 AM Brad Jorsch (Anomie) 
wrote:

> On Sun, Jan 29, 2017 at 6:38 PM, Ori Livneh  wrote:
>
> > Resistance Manual <
> https://www.resistancemanual.org/Resistance_Manual_Home
> > >
> > is a guide for organizing resistance to the policies of the Trump
> > administration in the United States. The site is running MediaWiki 1.28,
> > and its admins are looking for help maintaining the site. The main page
> > says to reach out to i...@staywoke.org if interested.
> >
>
> Is "some random wiki needs sysadmins" really on-topic for this list?
>
>
> --
> Brad Jorsch (Anomie)
> Senior Software Engineer
> Wikimedia Foundation
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Changes in colors of user interface

[Steven Walling]

Pine, please chill for once.
On Fri, Dec 9, 2016 at 5:40 PM Legoktm  wrote:

> Hi,
>
> On 12/09/2016 05:25 PM, Pine W wrote:
> > While I appreciate the attempt to be funny, I am not amused in this case.
> > Surprise UI changes could, for example, result in thousands of dollars'
> > worth of instructional videos becoming instantly out of sync with the
> > real-world user experience. Also, users who may have spent considerable
> > time perfecting their templates may be surprised to find that they need
> to
> > make changes to keep the templates in sync with other changes to the UI.
> > The problem isn't so much that the UI was changed, as that it was changed
> > without notice and consultation. This isn't funny.
>
> Well, I was specifically responding to Strainu's comment that "No change
> is to small to be disliked by one or more people!" which seemed to be in
> jest too.
>
> But I think you're significantly over-exaggerating the costs of this UI
> change, and changes in general. MediaWiki's UI changes literally every
> day when localization messages are updated, reworded, or added. Special
> pages are re-organized to be made more intuitive, toolbars re-arranged,
> etc. If you're making instructional videos, colors *barely* changing
> seem like the least of your problems in terms of becoming out of date.
> The VisualEditor project has a script that automatically generates
> localized screenshots of the user interface so the user manual stays up
> to date, I don't know if any solution has been worked out for videos yet.
>
> -- Legoktm
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikimedia-l] Apple Pay donations

[Steven Walling]

Thanks Lisa!
On Tue, Nov 15, 2016 at 7:57 AM Lisa Gruwell <lgruw...@wikimedia.org> wrote:

> Hi Steven-
>
> Yes, we are excited about Apple Pay's new ability to accept donations. It
> is on our product roadmap, but we are not certain yet when we will be
> rolling it out.
>
> And thanks, Amir, for selecting us for Amazon Smile!
>
> Best,
>
> Lisa Gruwell
>
> On Tue, Nov 15, 2016 at 4:06 AM, Antoine Musso <hashar+...@free.fr> wrote:
>
> > On 15/11/16 02:12, Steven Walling wrote:
> > 
> >
> >>  Given that payments on mobile are such a huge headache and
> >> declining desktop traffic to Wikimedia properties, it might be an
> >> interesting pilot to explore nonetheless.
> >>
> >
> > Hello,
> >
> > Going out of topic sorry. Regarding mobile and desktop traffic declining,
> > according to https://reportcard.wmflabs.org/
> >
> > * Overall page views is about the same since 2013.
> > * Mobile traffic quickly raised until reaching a plateau in 2015.
> >
> > Surely one can say that traffic shifted to mobile, but for the last two
> > years the desktop/mobile ratio seems fairly stable.
> >
> >
> > The Fundraising team might have some data regarding donations made
> through
> > desktop vs mobile and their evolution though.  Maybe mobile has a better
> > engagement rate, then the mobile app is only a drop of our traffic.
> >
> > --
> > Antoine "hashar" Musso
> >
> >
> >
> > ___
> > Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wik
> > i/Mailing_lists/Guidelines
> > New messages to: Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
> >
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

[Wikimedia-l] Apple Pay donations

[Steven Walling]

Hey all,

Today Apple announced a bunch of 501(c)3 partners which now can use Apple
Pay to make instant donations. Announcement at:
http://www.apple.com/newsroom/2016/11/a-touch-of-giving-with-apple-pay.html

Does WMF fundraising have plans to integrate with Apple Pay, especially on
mobile devices? I understand that right now it's limited to the US and the
team has been focusing a ton on international payment providers (which is
great). Given that payments on mobile are such a huge headache and
declining desktop traffic to Wikimedia properties, it might be an
interesting pilot to explore nonetheless.
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikitech-l] [Wikitech-ambassadors] Opening the door to a new look...a Wikipedia.org Portal Page Update

[Steven Walling]

On Tue, Aug 16, 2016 at 9:39 AM Anne Gomez  wrote:

> Congrats portal team! Very cool to look at both the new and the old side by
> side - the visual design is much cleaner, but more than that the
> improvements to clarifying flows for the user is remarkable.
>
> I particularly like the language detection from the user's browser
> settings. That should help people get what they're looking for so much more
> easily, while still giving them access to other languages if they'd like to
> browse that way.
>

Big +1. Doing automatic language detection is a big step forward. Awesome
work!


> Congrats again :)
>
>
>
>
>
> On Tue, Aug 16, 2016 at 9:25 AM, Deborah Tankersley <
> dtankers...@wikimedia.org> wrote:
>
> > Everyone who uses the wikipedia.org  [1]
> > portal is familar with the look of the page: a beautiful puzzle globe
> > encirled by the top ten viewed languages; a long list with Wikipedias in
> > hundreds of languages that can all be read and explored; the search box
> > that can make queries in nearly any language; and a compilation of
> related
> > Wikimedia projects.
> >
> >
> > Over the last eight months, the Wikimedia Foundation's Portal team
> >  [2], part of the
> Discovery
> > department  [3], has
> > been busy improving the discoverability of information within the portal
> to
> > make it more contemporary and easier to use.
> >
> > To start, we’ve updated the search box. When you are entering a query,
> you
> > will now see images and metadata that correspond to your search
> > <
> https://commons.wikimedia.org/wiki/File:Wikipedia,org-searchbox_highlight-Aug2016_screenshot.png
> >
> > [4], and you're also free change the search language without leaving the
> > page.
> >
> > We’ve also optimized the portal site, making it load faster by utilizing
> > smaller sized images and streamlining the page code.
> >
> > A fairly inconspicuous change to the page will immediately detect your
> > browser’s preferred (or default) language and rearrange the top ten links
> > to display those languages first, along with the remaining top ten viewed
> > wiki’s by language, around the globe.
> >
> > In this example
> > <
> https://commons.wikimedia.org/wiki/File%3AWikipedia.org-globe-sorted-languages_screenshot.png
> >
> > [5], The Free Encyclopedia is displayed in Portuguese, since it is the
> > browser’s first preferred language and English is the second.
> >
> > Here is a helpful site
> >  [6] that
> > explains how to change your preferred language on various browsers.
> >
> > We’ve also added sister project descriptions
> > <
> https://commons.wikimedia.org/wiki/File:Wikipedia.org-sister-projects-text_screenshot.png
> >
> > [7], located in the page’s footer, which will hopefully spark curiosity
> > as to what a person might find when they visit those individual projects.
> >
> > The look and feel of the long list of every available language wiki
> > (sorted by article count) has been modernized and placed inside an
> > elegant drop down
> > <
> https://commons.wikimedia.org/wiki/File:Wikipedia.org-language-dropdown_screenshot.png
> >
> > [8]. This new feature makes finding your language wiki a bit easier on
> > the eyes as well as providing easy access on any device.
> >
> > We hope you enjoy using the new portal page! You can view a short video
> > <
> https://upload.wikimedia.org/wikipedia/commons/8/8c/Wikipedia.org-new-layout_movie-Aug2016.ogg
> >
> > [9] that shows some of these new features.
> >
> > *And, if you don’t quite remember what the old Wikipedia portal site
> > looked like before we made any changes, here’s a reminder
> >  *
> > [10].
> >
> > Cheers from the Discovery Portal Team!
> >
> > [1] https://www.wikipedia.org/
> > [2] https://www.mediawiki.org/wiki/Wikipedia.org_Portal
> > [3] https://www.mediawiki.org/wiki/Wikimedia_Discovery
> > [4] https://commons.wikimedia.org/wiki/File:Wikipedia,org-search
> > box_highlight-Aug2016_screenshot.png
> > [5] https://commons.wikimedia.org/wiki/File%3AWikipedia.org-glob
> > e-sorted-languages_screenshot.png
> > [6] https://www.w3.org/International/questions/qa-lang-priorities
> > [7] https://commons.wikimedia.org/wiki/File:Wikipedia.org-sister
> > -projects-text_screenshot.png
> > [8] https://commons.wikimedia.org/wiki/File:Wikipedia.org-langua
> > ge-dropdown_screenshot.png
> > [9] https://upload.wikimedia.org/wikipedia/commons/8/8c/Wikipedi
> > a.org-new-layout_movie-Aug2016.ogg
> > [10] https://commons.wikimedia.org/wiki/File:Wikipedia.org-01Jan2016.png
> >
> >
> > --
> > Deb Tankersley
> > Product Manager, Discovery
> > IRC: debt
> > Wikimedia Foundation
> >
> > ___
> > Wikitech-ambassadors mailing list
> > 

Re: [Wikimedia-l] With my thanks to everyone ...

[Steven Walling]

Congrats on the new role Geoff, and thank you so much for your leadership
over the last half-decade. You have been a huge asset to the movement, and
will be sorely missed.
On Wed, Jul 13, 2016 at 3:29 PM Olatunde Isaac 
wrote:

> Thanks for your impeccable service,  Geoff. Wishing you all the best in
> your future endeavors.
>
> Isaac
> Sent from my BlackBerry® wireless handheld from Glo Mobile.
>
> -Original Message-
> From: Pine W 
> Sender: "Wikimedia-l" Date: Wed,
> 13 Jul 2016 14:32:29
> To: Wikimedia Mailing List
> Reply-To: Wikimedia Mailing List 
> Subject: Re: [Wikimedia-l] With my thanks to everyone ...
>
> Thank you for your service, Geoff. I hope that we will still see you
> around. Good luck with the new gig. :)
>
> Regards,
>
> Pine
>
> On Wed, Jul 13, 2016 at 2:25 PM, Geoff Brigham 
> wrote:
>
> > Hi all,
> >
> > Over the past five years, I’ve been honored to serve as the General
> Counsel
> > and Secretary of the Wikimedia Foundation. This job has been amazing, and
> > I’m grateful to everyone who has made it so rewarding. It's now time for
> my
> > next step, so, in the coming days, I will be leaving the Foundation to
> > pursue a new career opportunity.
> >
> > I depart with such love for the mission, the Foundation, the Wikimedia
> > communities, and my colleagues at work. I thank my past and present
> bosses
> > as well as the Board for their support and guidance. I stand in awe of
> the
> > volunteer writers, editors, and photographers who contribute every day to
> > the Wikimedia projects. And I will hold special to my heart my past and
> > current teams, including legal and community advocacy. :) You have
> taught,
> > given, and enriched me so much.
> >
> > After my departure, Michelle Paulson will serve as interim head of Legal,
> > and, subject to Board approval, Stephen LaPorte will serve as interim
> > Secretary to the Board. I can happily report that they have the
> experience
> > and expertise to ensure a smooth and professional transition.
> >
> > The future of the Foundation under Katherine's leadership is exciting.
> > Having had the pleasure of working for her, I know Katherine will take
> the
> > Foundation to its next level in promoting and defending the outstanding
> > mission and values of the Wikimedia movement. Although I'm delighted
> about
> > my next opportunity, I will miss this new chapter in the Foundation's
> > story.
> >
> > My last day at the Foundation will be July 18th. After that, I will take
> a
> > month off to recharge my batteries, and then I start my new gig at
> YouTube
> > in the Bay Area. There, I will serve as Director of YouTube Trust &
> Safety,
> > managing global teams for policy, legal, and anti-abuse operations. As
> with
> > Wikimedia, I look forward to learning from those teams and tackling
> > together a new set of exciting, novel challenges.
> >
> > For those who want to stay in touch, please do! My personal email is:
> > geoffrey.r.brig...@gmail.com.
> >
> > With respect, admiration, and gratitude,
> >
> > Geoff
> > ___
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > New messages to: Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > 
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikitech-l] Campaigns extension / ServerSideAccountCreation log - does anyone still use it?

[Steven Walling]

Hey Brad,

That sounds fine to me.

We previously used the loginCTA campaign to measure the value of that
secondary button on the login page (
ee-dashboard.wmflabs.org/graphs/enwiki_campaigns) but it doesn't need to
happen on an ongoing basis.

On Tue, May 31, 2016 at 11:31 AM Brad Jorsch (Anomie) 
wrote:

> On Thu, May 26, 2016 at 2:56 PM, Brad Jorsch (Anomie) <
> bjor...@wikimedia.org
> > wrote:
>
> > Question 1: Would anyone care if we kill the "loginCTA" campaign, which
> > tracks when people use the link at the bottom of Special:UserLogin to get
> > to the account creation page?
> >
> > Question 2: Would anyone care if we remove the extension entirely from
> > Wikimedia wikis? Wikiapiary seems to show only one user outside of
> > Wikimedia.
> >
>
> Following up on this: Since the answer to Question 2 was yes, we've done
> the necessary update to Campaigns so it will continue working with
> AuthManager.[1] Since no one answered Question 1, the loginCTA campaign has
> been removed. It will stop showing up in 1.28.0-wmf.4, which rolls out this
> week.
>
>  [1]: https://gerrit.wikimedia.org/r/#/c/291280/
>
>
> --
> Brad Jorsch (Anomie)
> Senior Software Engineer
> Wikimedia Foundation
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikimedia-l] [Wikitech-l] Campaigns extension / ServerSideAccountCreation log - does anyone still use it?

[Steven Walling]

Hey Brad,

That sounds fine to me.

We previously used the loginCTA campaign to measure the value of that
secondary button on the login page (
ee-dashboard.wmflabs.org/graphs/enwiki_campaigns) but it doesn't need to
happen on an ongoing basis.

On Tue, May 31, 2016 at 11:31 AM Brad Jorsch (Anomie) 
wrote:

> On Thu, May 26, 2016 at 2:56 PM, Brad Jorsch (Anomie) <
> bjor...@wikimedia.org
> > wrote:
>
> > Question 1: Would anyone care if we kill the "loginCTA" campaign, which
> > tracks when people use the link at the bottom of Special:UserLogin to get
> > to the account creation page?
> >
> > Question 2: Would anyone care if we remove the extension entirely from
> > Wikimedia wikis? Wikiapiary seems to show only one user outside of
> > Wikimedia.
> >
>
> Following up on this: Since the answer to Question 2 was yes, we've done
> the necessary update to Campaigns so it will continue working with
> AuthManager.[1] Since no one answered Question 1, the loginCTA campaign has
> been removed. It will stop showing up in 1.28.0-wmf.4, which rolls out this
> week.
>
>  [1]: https://gerrit.wikimedia.org/r/#/c/291280/
>
>
> --
> Brad Jorsch (Anomie)
> Senior Software Engineer
> Wikimedia Foundation
> ___
> Wikitech-l mailing list
> wikitec...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Fwd: [WikimediaMobile] "Among mobile sites, Wikipedia reigns in terms of popularity"

[Steven Walling]

It's really great to see Wikipedia highlighted as a source for news and
current events. It's rare that people fully recognize the degree to which
the "encyclopedia" is actually very good at trending news information. That
said, the report paints a rosy picture that, strategically speaking, may
not be cause for celebration.

Remember that, when looking at pageviews, we're a little over 40% mobile.
Most other major Internet properties are now primarily mobile, and that's
where most media consumption is even in once desktop-centric markets like
the US.(1)

Has Dario or anyone done an update on the traffic analysis from 2014,(2)
where we concluded that declining desktop traffic in mature markets like
the US was not being offset by mobile web? What's the current state of the
world when it comes to Wikipedia mobile traffic, overall and broken down by
app vs. mobile web?

It seems obvious that part of the reason Wikipedia is so popular on mobile
web is because we're an odd duck -- Wikimedia is one of the only top media
orgs not doing any kind of app upsell at all on mobile web. The vast
majority of major Internet properties heavily push app installs and usage
to varying degrees of aggressiveness. This directly sacrifices mobile web
traffic for a longterm gain in reader retention.

The linked report shows that Wikipedia app users are much more engaged --
avg time spent per person in the Wikipedia app is more than double that of
mobile web, according to their data -- but the number of app users is
ridiculously tiny, relatively speaking.(3) In commercial apps, prioritizing
long term retention of app users is good for a business. They can then be
converted to subscribers, purchase in-app upgrades, or click on ads. In the
Wikimedia context, greater mobile retention and time spent could be used to
teach people to contribute, and to facilitate less aggressive forms of
mobile fundraising than we've previously had to do. Not to mention
providing readers with faster direct access to knowledge, and doing a
better job of teaching mobile-first US in emerging markets what Wikipedia
is.

Neglecting to show people the value of the apps will help grow mobile web
traffic in the short term, but in the long run may leave us entirely
dependent on search (i.e. Google) or simply not growing readers, despite
millions of people still coming online via mobile. In the report data you
can see that most of the US news sites mentioned are dependent on Facebook,
even if they have an app. Unlike them, Wikipedia has an opportunity to get
away from being dependent on another source for readers, and be one of the
primary apps that every person on the planet uses, alongside Facebook,
messaging tools, and similar. Right now, we're squandering that
opportunity, and it's going to get harder to change as time goes on.

1.
http://techcrunch.com/2014/08/21/majority-of-digital-media-consumption-now-takes-place-in-mobile-apps/
2.
https://meta.wikimedia.org/wiki/File:2014_Readership_Update,_WMF_Metrics_Meeting,_December.pdf
3.
https://medium.com/mobile-first-news-how-people-use-smartphones-to/news-goes-mobile-how-people-use-smartphones-to-access-information-53ccb850d80a#.ofpb8txup

On Wed, May 11, 2016 at 12:50 PM Michael Peel  wrote:

> Isn't it time to start moving to responsive mediawiki templates (
> https://en.wikipedia.org/wiki/Responsive_web_design), rather than having
> a separate mobile interface/URL?
>
> For a practical example, see the BBC News website (
> http://www.bbc.co.uk/news), which is the same website on all devices, it
> just rescales the content/navigation/layout to suit the device. (Try
> resizing your web browser on your computer to the size of a mobile web
> browser to see what I mean.)
>
> Thanks,
> Mike
>
> > On 11 May 2016, at 20:36, Gerard Meijssen 
> wrote:
> >
> > Hoi,
> > It is wonderful to see how we have evolved.. Does anyone remember the
> good
> > old days when it was an application totally and utterly outside of
> > MediaWiki?
> > Thanks,
> > GerardM
> >
> > On 11 May 2016 at 20:33, Pine W  wrote:
> >
> >> Forwarding since this may be of general interest regarding Wikipedia
> >> readership.
> >>
> >> Thanks Tilman!
> >>
> >> Pine
> >>
> >> -- Forwarded message --
> >> From: Tilman Bayer 
> >> Date: Wed, May 11, 2016 at 10:23 AM
> >> Subject: [WikimediaMobile] "Among mobile sites, Wikipedia reigns in
> terms
> >> of popularity"
> >> To: mobile-l 
> >> Cc: Wikimedia developers , Analytics
> Team
> >> -
> >> Internal 
> >>
> >>
> >> New study (US only) by the Knight Foundation:
> >> https://medium.com/mobile-first-news-how-people-use-smartphones-to ,
> >> summarized here:
> >>
> >>
> http://www.theatlantic.com/technology/archive/2016/05/people-love-wikipedia/482268/
> >>
> >> "People spent more time on Wikipedia’s 

Re: [Wikimedia-l] Thank you, Jan-Bart and Stu

[Steven Walling]

Thanks for starting this thread Lodewijk.

Jan-Bart and Stu: Wikimedia has been lucky to have your participation over
these years.

Stu, thank you in particular for helping steer the financial governance of
the Wikimedia movement. Your expertise and professionalism have been deeply
important to making sure Wikimedia is a good steward of the money entrusted
to us by donors.

Jan-Bart, my friend, you are a force to be reckoned with. It is difficult
to sum up the total impact of your leadership in the movement. I find
myself falling back on memories not just of your formal role on the board,
but of your warmth and generosity of spirit. I hope leaving the board (this
time) doesn't mean your Wikimania streak will be broken. ;-)

On Tue, Jan 5, 2016 at 11:11 PM Lodewijk 
wrote:

> While we have long discussions on this list about board composition, we
> seem to almost ignore the fact that two long time veterans are leaving the
> Wikimedia Foundation board, as scheduled. Jan-Bart de Vreede and Stu West
> have been around longer than many regular editors nowadays, and I think
> there are not many people who can recall the days that the board didn't
> have them on it. I have never had the pleasure to serve on the board with
> them, but a little thank-you from our community side, would seem in place.
>
> Stu joined the board already in 2008 (filling Michael Davis' seat), and has
> been a solid power on the board's audit responsibilities (I believe he
> chaired the audit committee for quite a while) and was a force behind the
> accountability of movement affiliates. While we often strongly disagreed on
> affiliate issues, I appreciate the fact that he always remained
> constructive and wanted to think about solutions rather than problems. He
> served both as treasurer and vice chair.
>
> Jan-Bart was on the board even longer, since early 2007, and I recall
> already working with him through Kennisnet (a Dutch foundation for
> education and IT) before that. Jan-Bart is one of those rare people who
> went to ALL wikimania conferences, and can be easily recognised there with
> his big smile. I can't remember a theme Jan-Bart didn't work on in the past
> years (Affiliates, HR, searching a new Executive Director) and he served
> the board in many positions, including as chair.
>
> I'm sure that the WMF communications staff and/or board has a nice thankyou
> coming up - with a more accurate description of the awesome work they did,
> that I now made up from the top of my head. But in the mean time, I'd like
> to do it myself: Thank you Jan-Bart and Stu for all the time, energy and
> effort that you poured into our movement. I know that not all of us
> appreciate this as much as we perhaps should, and sometimes you may even
> have perceived us as hostile. I do sincerely hope that you had fun with us
> though, and I'm confident that you made a big dent in our impossible
> mission of sharing the sum of all knowledge with everyone.
>
> I hope to meet you again soon, at least in Italy at Wikimania, and I hope
> to see you around in our movement in many different ways.
>
> Best,
>
> Lodewijk
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Announcement about changes to the Board

[Steven Walling]

Pine,

Given that the way James and the Board should relate to staff was one issue
that lead to his removal, the situation in the wider WMF as an organization
is highly relevant here.

Under normal, smoothly-functioning circumstances (and most of my 4 year
tenure at WMF) there was little reason for non-executive staff to interact
with the Board in a professional capacity. If that isn't the case and staff
are trying to communicate with the Board directly a lot, it is smoke
pointing to a burning fire somewhere.

On Sun, Jan 3, 2016 at 10:57 PM Pine W  wrote:

> I agree that the turnover issue is a matter that needs some consideration.
> But I think that issue is more relevant to the ED rather than the Board. I
> would appreciate it if we could keep that issue separate from the murky
> circumstances of James' departure and the conflicting testimony that has
> been given in public, the *possible* official misconduct with regards to
> improper withholding of financial information from James, the community's
> desire for significantly more transparency and openness from the Board, and
> the credibility of the Board's leadership.
>
> Pine
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Revision scoring as a service launched

[Steven Walling]

This is really cool! Congrats to everyone who worked on this.
On Mon, Nov 30, 2015 at 7:51 PM Dario Taraborelli <
dtarabore...@wikimedia.org> wrote:

> (cross-posting from wikitech-l)
>
> Today we published an announcement on the Wikimedia blog marking the
> official launch of revision scoring as a service <
> https://meta.wikimedia.org/wiki/Research:Revision_scoring_as_a_service>
> and I wanted to say a few words about this project:
>
> Blog post:
> https://blog.wikimedia.org/2015/11/30/artificial-intelligence-x-ray-specs/
> <
> https://blog.wikimedia.org/2015/11/30/artificial-intelligence-x-ray-specs/
> >
> Docs on Meta: https://meta.wikimedia.org/wiki/ORES <
> https://meta.wikimedia.org/wiki/ORES>
>
> First off: what’s revision scoring <
> https://meta.wikimedia.org/wiki/Research:Revision_scoring_as_a_service#Rationale>?
> On the surface, it’s a set of open APIs allowing you to automatically
> “score” any edit and measure their probability of being damaging or
> good-faith contributions. The real goal behind this project, though, is to
> fix the damage indirectly caused by vandal-fighting bots and tools on
> good-faith contributors and to bring back a collaborative dimension to how
> we do quality control on Wikipedia. I invite you to read the whole blog
> post <
> https://blog.wikimedia.org/2015/11/30/artificial-intelligence-x-ray-specs/>
> if you want to know more about the motivations and expected outcome of this
> project.
>
> I am thrilled this project is coming to fruition and I’d like to
> congratulate Aaron Halfaker <
> https://wikimediafoundation.org/wiki/User:Ahalfaker> and all the project
> contributors <
> https://meta.wikimedia.org/wiki/Research:Revision_scoring_as_a_service#Team>
> on hitting this big milestone: revision scoring started as Aaron’s side
> project well over a year ago and it has been co-designed (as in – literally
> – conceived, implemented, tested, improved and finally adopted) by a
> distributed team of volunteer developers, editors, and researchers. We
> worked with volunteers in 14 different Wikipedia language editions and as
> of today revision scores are integrated <
> https://meta.wikimedia.org/wiki/Research:Revision_scoring_as_a_service#Tools_that_use_ORES>
> in the workflow of several quality control interfaces, WikiProjects and 3rd
> party tools. The project would not have seen the light without the
> technical support provided by the TechOps team (Yuvi in particular) and
> seminal funding provided by the WMF IEG program and Wikimedia Germany.
>
> So, here you go: the next time someone tells you that LLAMAS GROW ON TREES
>  you can
> confidently tell them they should stop damaging <
> http://ores.wmflabs.org/scores/enwiki/damaging/642215410/> Wikipedia.
>
> Dario
>
>
> Dario Taraborelli  Head of Research, Wikimedia Foundation
> wikimediafoundation.org  • nitens.org <
> http://nitens.org/> • @readermeter 
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> 
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] internet-in-a-boxs to the refugee camps?

[Steven Walling]

Offline access is a nice idea, but the logistics of delivery seem daunting.
Thankfully, a large number of refugees and migrants have smartphones.[1]

Probably the biggest ways we could help refugees are really to:

A) make Wikipedia super performant on mobile, particularly for low-end
Android devices

B) make Wikipedia free via mobile programs like Zero or SMS gateways, so
people who can't pay for data can access it

C) get more relevant, updated content in Arabic. Articles on relevant
subjects are much shorter than in English, etc.[2]

1.
http://mobile.nytimes.com/2015/08/26/world/europe/a-21st-century-migrants-checklist-water-shelter-smartphone.html
2.
https://ar.wikipedia.org/wiki/%D8%A3%D8%B2%D9%85%D8%A9_%D8%A7%D9%84%D9%85%D9%87%D8%A7%D8%AC%D8%B1%D9%8A%D9%86_%D8%A5%D9%84%D9%89_%D8%A3%D9%88%D8%B1%D9%88%D8%A8%D8%A7

On Tue, Sep 8, 2015 at 11:00 PM Neil P. Quinn  wrote:

> This reminds me of several conversations I had with Barbara Schack of
> Libraries Without Borders [1] at the Lyon hackathon (I've copied her on
> this email).
>
> They've developed the Ideas Box [2], a portable media center intended for
> locations like refugee camps. It's similar to the Internet-in-a-Box,
> although it takes the concept further by including client devices, toys,
> and furniture as well as an offline content server (it's really quite
> cool). As you'd imagine, the Ideas Box includes read access to downloaded
> Wikipedia content; however, Barbara told me she wanted Ideas Box users to
> have the opportunity to contribute as well as simply read, and asked us
> what it would take to make that possible.
>
> We talked about it a good deal and had a brainstorming workshop on the
> subject; I recorded many of the ideas in Phabricator [3]. The technical
> challenges are significant, so I don't think anybody has pursued the
> project since then. However, if anyone out there wants to work on bridging
> this aspect of the digital divide, I'm sure Barbara would be excited to
> work with you!
>
> [1]: http://www.librarieswithoutborders.org/
> [2]: http://www.ideas-box.org/en/
> [3]: https://phabricator.wikimedia.org/T100154
>
> On Mon, Sep 7, 2015 at 3:36 PM, Comet styles  wrote
>
> > contrary to the name, it doesn't actually have 'internet access'
> > ..they can read, but not contribute..
> >
> > On 9/8/15, Jane Darnell  wrote:
> > > Good idea. I watched a report on TV where they said some refugees have
> > been
> > > waiting for years for processing. It would be nice for them to be able
> to
> > > use and maybe contribute to Wikipedia while they are waiting. Maybe we
> > > should set up edit-a-thons and wikiclasses about life in Europe and the
> > > politics of the crisis, for the refugees and the Europeans both!
> > >
> > > On Mon, Sep 7, 2015 at 9:45 PM, Leinonen Teemu <
> teemu.leino...@aalto.fi>
> > > wrote:
> > >
> > >> Hello people,
> > >>
> > >> Just an idea. Number of Syrian refugees is over 4,000,000 people,
> mostly
> > >> residing in Turkey, Lebanon, Jordan and Iraq.[1] Refugee camps are set
> > in
> > >> all in these countries.[2]
> > >>
> > >> Internet-in-a-Box[3] is a a WiFI-device with "Wikipedia in 37
> > languages, a
> > >> library of 40,000 e-books, most of the world's open source software
> and
> > >> source code, hundreds of hours of instructional videos, and world-wide
> > >> mapping down to street level.”
> > >>
> > >> Could we as a movement get the internet-in-a-box to the refugee camps?
> > >>
> > >> - Teemu
> > >>
> > >> [1] https://en.wikipedia.org/wiki/Refugees_of_the_Syrian_Civil_War
> > >> [2] https://en.wikipedia.org/wiki/Syrian_refugee_camps
> > >> [3] http://internet-in-a-box.org
> > >>
> > >> --
> > >> Teemu Leinonen
> > >> http://teemuleinonen.fi
> > >> ___
> > >> Wikimedia-l mailing list, guidelines at:
> > >> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > >> Wikimedia-l@lists.wikimedia.org
> > >> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
> ,
> > >> 
> > > ___
> > > Wikimedia-l mailing list, guidelines at:
> > > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > > Wikimedia-l@lists.wikimedia.org
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > 
> >
> >
> > --
> > Cometstyles
> >
> > ___
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l@lists.wikimedia.org
> > <
> https://meta.wikimedia.org/wiki/Mailing_lists/guidelineswikimedi...@lists.wikimedia.org
> >
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > 

Re: [Wikitech-l] QA: Holding our code to better standards.

[Steven Walling]

Just to hop on the bandwagon here: this seems like the only sane path going
forward. One unmentioned benefit is that this is a step toward continuous
deployment. Having integration tests run on every commit and then block
when there are failures is pretty much a requirement if Wikimedia ever
wants to get there.

On Thu, Sep 3, 2015 at 1:43 PM Pine W  wrote:

> I just want to say that I appreciate this overview.
>
> Pine
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Code of conduct

[Steven Walling]

On Fri, Aug 7, 2015 at 7:32 AM MZMcBride z...@mzmcbride.com wrote:

 Matthew Flaschen wrote:
 We're in the process of developing a code of conduct for technical
 spaces.  This will be binding, and apply to all Wikimedia-related
 technical spaces (including but not limited to MediaWiki.org,
 Phabricator, Gerrit, technical IRC channels, and Etherpad).

 Who's we? This seems to be a pet issue of yours. I'm curious who else is
 supportive of this initiative to enact a binding policy.

 MZMcBride


What kind of standards for behavior we want and think are acceptable is a
core concern of everyone in the Wikimedia and MediaWiki technical
communities.

This kind of personally-directed and demeaning feedback (This seems to be
a pet issue of yours) is, perhaps ironically, precisely an example of why
it would improve interaction in technical spaces to have some clearer
ground rules.




 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Design] Winter

[Steven Walling]

Having been away from WMF engineering and design for almost a year, I'd
like to reiterate how what Ryan is outlining is not some bold outlandish
idea. In fact, it's standard operating procedure for how the top tier of
product development is done at every non-enterprise software company worth
a damn.

At Quora, we basically follow a version of this philosophy, though we
certainly consult a ton directly with our community before, during and
after the product development process. We just do this in a consultative
way—not a consensus driven one.

I would say the one unintentionally misleading part of what Ryan is saying
is that it makes it sound like a zero sum game where the company wins and
the community loses.

It's actually the opposite. Wikimedians today, wanting things to be perfect
according to their standards and for consensus among all to be arrived at,
dramatically slow things down and increasing the time/cost of development.
When you have a much more rapid pace of change enabled by data and by the
ability to ignore vocal minorities, it means more stuff gets done. This
would free up huge amounts of design and development hours to focus on
fixing tools near and dear to said vocal minorities, ultimately making
everyone happier.

On Fri, Jul 24, 2015 at 4:54 PM Ryan Lane rlan...@gmail.com wrote:

 Nihiltres nihiltres@... writes:

   An example: Make search more discoverable. Add a feature or make an
   interface change to test this. A/B test it. See if the frequency of
 search
   usage increased. See if it adversely affected other metrics. If it
 helped
   search usage and didn't negatively affect other metrics, adopt the
 change.
  
   The issue is that there will be a vocal minority of people who
 absolutely
   hate this change, no matter what it is. These people should be ignored.
 
  This is *exactly* the sort of issue that leads to conflict. Some parts
 emphasized:
 
   The editor community should have little to no say in the process
 
  or
 
a vocal minority
 
  or, worst,
 
   These people should be ignored.
 
  A/B testing is one thing, but our problems are *social*, are *political*,
 and that's precisely what I see
  above. This is not a productive approach, because it pits stakeholders
 against one another. Wikipedia is
  not a *competition*, it's supposed to be a *collaboration*. It's even
 worse when it's framed in the
  otherwise reasonable context of A/B testing, because that conceals the
 part of it that has one particular
  subset of stakeholders decide what metrics (e.g. search) are important.
 While I do disagree, I don't mean
  to argue specifically against Ryan Lane's position here—I'm just using it
 as an example of positions
  that exacerbate the social problems. It doesn't matter in what ways he or
 I are right or wrong on the
  approach if it's going to lead to another conflict.
 

 The idea is to remove the social or political problems from the process.
 Define the goals and feature sets (this is the part of the process that
 requires community interaction), implement and test the changes, review the
 results. The data is the voice of the community. It's what proves if an
 idea
 is good or bad.

 As I said before, though, there's always some vocal minority that will hate
 change, even when it's presented with data proving it to be good. These
 people should be ignored at this stage of the process. They can continue to
 provide input to future changes, but the data should be authoritative.

  If we ignore people, or worse, specifically disenfranchise them, that's
 sure to lead to conflict when the
  interested stakeholders pursue their interests and thus become that
 vocal
 minority. Rather, we need
  an obvious process, backed by principles that most of everyone can agree
 on, so that we don't hit catches
  like one-sided priorities. Yes, we do need to figure out how to make sure
 that reader interests are
  represented in those principles. If the shared process and shared
 principles lead us to something that
  some people don't agree with, *then* there might be a justification to
 tell that minority to stuff it in the
  name of progress.
 
  I'll leave off there, because the next thing I intuitively want to go
 onto
 involve my personal views, and
  those aren't relevant to this point (they can wait for later). Instead: a
 question: what *principles*
  ought to underpin designs moving forward from Vector? If we can't work
 through disagreements there,
  we're going to see objections once an unbalanced set of principles are
 implemented in design patterns.
 

 There's not really a lack of principles, there's a lack of reasonable
 process. What's wrong with change guided by data science? We know the
 scientific process works. The current process is design by a committee
 that's comprised mostly of people untrained in the field, with no data
 proving anyone's case. Even when there is data it's often ignored in favor
 of consensus of the editor community.

 - Ryan
 

Re: [Wikitech-l] Search engine indexing of userspace - has something changed?

[Steven Walling]

FWIW I have also seen many cases of userspace drafts being indexed. Perhaps
something to do with the fact that they are always subpages?

On Mon, Jul 6, 2015 at 10:35 AM Jon Robson jdlrob...@gmail.com wrote:

 Looks like a bug

 Looking closely this meta tag is present in user pages:
 meta name=robots content=noindex,follow

 but not present in that particular sub page [1].
 I haven't had time to investigate further but please raise a phabricator
 task.

 [1]
 https://en.m.wikipedia.org/wiki/User:Nobleeagle/India_as_an_emerging_superpower

 On Mon, Jul 6, 2015 at 10:32 AM, Dan Garry dga...@wikimedia.org wrote:
  Hello!
 
  In this thread
  
 https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#Userpage_drafts_shown_in_search_engines
 ,
  there was a discussion about indexing of user space by search engines.
 In a
  nutshell, user space pages are not subject to content policies so that
  users can write drafts freely, and having those pages indexed by search
  engines like Google is viewed as problematic since those pages can seem
  fairly official.
 
  I seem to recall that it was not the default in the past that user pages
  were indexed by search engines. I'm trying to figure out if there's some
  other cause for this that's happened recently, because I'd prefer to
 avoid
  piling hacks on and not address the root issue.
 
  Does anyone know of anything that's changed recently that might've
 changed
  the way that search engines index user space?
 
  Thanks,
  Dan
 
  --
  Dan Garry
  Product Manager, Discovery
  Wikimedia Foundation
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l



 --
 Jon Robson
 * http://jonrobson.me.uk
 * https://www.facebook.com/jonrobson
 * @rakugojon

 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] MediaWiki, as seen on TV

[Steven Walling]

There's a pretty hilarious American police procedural TV show in 2015
called CSI: Cyber, featuring mostly cybercrime. Obviously they have to
dredge up snippets of code from places for screenshots on the show.

Episode 4 happened to include a tidbit from MediaWiki 1.25/wmf3. Supposedly
the code was a hack to make your printer blow up.

Original lulz and screenshots via
http://moviecode.tumblr.com/post/114815574587/this-is-from-csi-cyber-s01e04-according-the-the
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Analytics] [EE] Facebook edit button for Wikipedia

[Steven Walling]

The edit link has been there for a long time.
On Fri, May 8, 2015 at 6:11 PM Pine W wiki.p...@gmail.com wrote:

 Quite possibly. I'm only on Facebook occasionally. Still, I haven't heard
 of WMF tracking FB content views or edits that come through FB. Perhaps
 there are opportunities here.

 Pine


 On Fri, May 8, 2015 at 6:06 PM, Alex Monk kren...@gmail.com wrote:

 I think that link has been there for several years...

 Alex

 On 9 May 2015 at 02:05, Pine W wiki.p...@gmail.com wrote:

 Hi EE and and analytics,

 I searched for Seattle on Facebook and am surprised to see that Facebook
 says below the page lede, From Wikipedia, the free enclopedia. Edit on
 Wikipedia. I don't recall seeing an edit link there before. Does Analytics
 have a way of tracking Wikipedia content views on FB and edits that were
 from FB viewers? Are there any plans for FB readership, text editing or
 image upload editor engagement work?

 Thanks,
 Pine

 ___
 EE mailing list
 e...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/ee



 ___
 EE mailing list
 e...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/ee


 ___
 EE mailing list
 e...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/ee

___
Analytics mailing list
Analytics@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/analytics

Re: [Mediawiki-i18n] [Wikimedia-l] ContentTranslation gets to 2000

[Steven Walling]

-Wikimedia-l

Amir, this is awesome. Glad to see it's taking off.

On Thu, Apr 30, 2015 at 6:24 AM Amir E. Aharoni 
amir.ahar...@mail.huji.ac.il wrote:

 * In all the Wikipedias in which ContentTranslation is deployed, it is
 currently defined as a Beta feature, which means that it is only available
 to logged-in users who opted into it in the preferences.


Regarding Beta feature status: what would it take to enable this as a
default? You mentioned this in plans for the coming months.

That deletion rate (60 out of 2000 = 3%?) looks actually a lot better than
pretty OK. According to historical stats, it's basically equivalent to
deletion rates for article creators with more than a month of experience.[1]

It seems like the only risk in taking this out of beta status as moving to
a default is UI clutter for monolingual users who can't ever make use of
the feature? Maybe it's unobtrusive enough that you don't need to do this,
but perhaps you could enable as a default for only those users who have
substantively edited more than one language edition of Wikipedia? Either
that, or we could consider adding a languages I edit in section to
the Internationalisation section of user preferences?

I'm sure you've thought about this before, but I'd love to hear more about
the rollout plan.

1. http://meta.wikimedia.org/wiki/Research:Wikipedia_article_creation
___
Mediawiki-i18n mailing list
Mediawiki-i18n@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n

Re: [Wikitech-l] [Wikimedia-l] ContentTranslation gets to 2000

[Steven Walling]

-Wikimedia-l

Amir, this is awesome. Glad to see it's taking off.

On Thu, Apr 30, 2015 at 6:24 AM Amir E. Aharoni 
amir.ahar...@mail.huji.ac.il wrote:

 * In all the Wikipedias in which ContentTranslation is deployed, it is
 currently defined as a Beta feature, which means that it is only available
 to logged-in users who opted into it in the preferences.


Regarding Beta feature status: what would it take to enable this as a
default? You mentioned this in plans for the coming months.

That deletion rate (60 out of 2000 = 3%?) looks actually a lot better than
pretty OK. According to historical stats, it's basically equivalent to
deletion rates for article creators with more than a month of experience.[1]

It seems like the only risk in taking this out of beta status as moving to
a default is UI clutter for monolingual users who can't ever make use of
the feature? Maybe it's unobtrusive enough that you don't need to do this,
but perhaps you could enable as a default for only those users who have
substantively edited more than one language edition of Wikipedia? Either
that, or we could consider adding a languages I edit in section to
the Internationalisation section of user preferences?

I'm sure you've thought about this before, but I'd love to hear more about
the rollout plan.

1. http://meta.wikimedia.org/wiki/Research:Wikipedia_article_creation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikimedia-l] WMF office location and remodel

[Steven Walling]

On Tue, Apr 7, 2015 at 9:58 PM Pine W wiki.p...@gmail.com wrote:

 Questions:

 What happens to the remodel expenses that WMF is paying for at its current
 location? If WMF vacates the premesis, will it be compensated for the
 remodel by the building owner?

 I hope that WMF is contemplating fully exiting the San Francisco market
 area in order to economize, get better value for our donors' funds, have
 less competition for talent, and lower costs of living for staff. Is this
 being considered?


Keep in mind that the WMF already mitigates the cost and competition of the
San Francisco Bay Area market by recruiting remote employees.

According to the recent report (
https://commons.wikimedia.org/wiki/File:State_of_the_Wikimedia_Foundation.pdf)
a large number are based either in other U.S. states or internationally.
Out of 202 employees, 77% are US-based in 19 states and 23% are based
abroad in 19 countries.

Combine the remote employees in the U.S. and abroad, I wouldn't be
surprised if close to half of staff are based remotely. On engineering
teams especially, it's not uncommon for a majority of employees to be
remote.
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikitech-l] Extension:Gather launching on beta for English WP mobile users.

[Steven Walling]

Thanks for the link Jon.

It seems only fair that people actually try the feature before ripping it
to shreds. Right? We've had extensions to create alternative content
curation features in the past, such as books, and this is hardly the first
time an experimental feature was launched on mobile first. So hardly seems
like time to grab the pitchforks before you even give it a fair shot.


On Thu, Mar 26, 2015 at 8:00 AM Jon Robson jrob...@wikimedia.org wrote:

 I should add you can opt into mobile beta using this link:
 http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:MobileOptions

 The design still has kinks and the extension still needs work before.
 Releasing to mobile beta will get us an audience to identify those issues
 and fix them. I'd be keen to get this as a desktop beta feature too if
 anyone is willing to help me.
 On 26 Mar 2015 7:41 am, Jon Robson jrob...@wikimedia.org wrote:

  A few notes:
  * lists are public in the first version but there is APIs to make them
  private. Public lists is something that will have moderation problems and
  interesting to explore.
  * the feature is _launching_ on mobile. It's built to work on desktop and
  with a tiny bit of work I can turn it on as a beta feature on desktop
 (the
  issue is how to replace the existing watchstar on desktop).
  * We considered doing it straight in core based on the watchlist code but
  we figured it would be more responsible to experiment in an extension,
 fine
  tune it against a completely different use case to watchlist and then
 make
  a proposal to move the good parts/all parts into core. I'm still
 personally
  dedicated to resolving the RFC [1]. We have worked hard so that the api
 to
  gather is backwards compatible with watchlist methods.
  * you can play with it on betalabs:
  ** http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:
 Gather/by/Jdlrobson
  ** http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:Gather
  * I'm personally excited to make multiple watchlists a reality using this
  extension at Lyon if anyone is keen to help me there. The infrastructure
  required is all in Gather.
 
  [1]
  https://m.mediawiki.org/wiki/Requests_for_comment/Support_
 for_user-specific_page_lists_in_core
  On 26 Mar 2015 7:20 am, Brian Wolff bawo...@gmail.com wrote:
 
  On Mar 26, 2015 11:04 AM, Brian Wolff bawo...@gmail.com wrote:
  
  
   On Mar 26, 2015 9:58 AM, MZMcBride z...@mzmcbride.com wrote:
   
Hi.
   
Moushira Elamrawy wrote:
The Extension will keep the name Gather and internally the team was
  more
inclined to name the feature Stacks. However, a survey study has
  been
carried out by the design research team and Collections, as a name
  for
  a
feature, scored far better than the other suggested alternatives.
  Full
survey information and results are documented here

  https://www.mediawiki.org/wiki/Extension%CB%90Gather/renaming_survey.
   
Right... in the January 2015 thread you linked, it was quickly
 pointed
  out
that Extension:Collection already exists. The mobile team, in
 typical
form, decided to ignore any previous work and instead make its own
project. At least we were able to shout loudly enough to stop this
functionality from being part of the MobileFrontend extension.
   
  
   Hey, count your blessings its not called collections with just an s
 at
  the end to distinguish it...
  
This is a new experiment in content curation, which hopefully helps
  with
learning new users behavior on mobile web. We are looking forward
 to
learning awesome lessons from this beta launch.
   
As was also previously pointed out, we've had curation support for a
  long
time in the form of categories (another feature that could have been
improved rather than making a new extension). Or making a list of
  pages
using wikilinks. Or tagging pages with templates, which
 auto-generates
  an
index. Perhaps you can explain why this new feature is limited to
  mobile?
   
  
   I dont know if this criticism is fair. Many users have been asking for
  multiple watchlist type functionality for years despite the option of
  creating a subpage or category and throwing special:recentchangeslinked.
  Categories dont really have per user namespace, and i think its
 important
  to have interfaces that encourage users to do this sort of thing rather
  then making them figure out that they are physically able to and allowed
  to.
  
   I do agree that its odd that this isnt developed in core for all
 users.
  The faq entry is unconvincing.
  
   --bawolff
 
  Actually after reading the extension page, I'm a little confused. If the
  goal is to create private personal lists why are the lists public? I can
  understand the use case for private lists (watchlist). I understand the
  use
  case for public lists (categories). What is the use case for
  pseudo-private
  lists?
 
  Maybe it will make more sense to me when the extension is deployed and I
  see 

Re: [Wikitech-l] [Wmfall] VisualEditor on Wikipedia now faster with RESTBase

[Steven Walling]

Nice work! This is big.
On Thu, Mar 19, 2015 at 3:08 PM Erik Moeller e...@wikimedia.org wrote:

 Fantastic work! :) VisualEditor is becoming really zippy -- which had been
 one of the top concerns in user feedback in the past. Congratulations to
 everyone involved.

 Erik
 --
 Erik Möller
 VP of Product  Strategy, Wikimedia Foundation
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Design] a new free font project

[Steven Walling]

Yes, the people working on Flow have mastered wiki text talk pages. One of
the engineers is User:Superm401, an admin on enwiki, and the product
manager is Danny Horn, who has been a regular MediaWiki user for years.

As a meta point, you don't actually need to be a hardcore power user of any
particular product to understand user needs. It helps, but it can also
actually hurt when you're trying to design something new that doesn't have
the same flaws. The field of user experience design and usability testing
has a host of techniques to enable a skilled person to investigate and
understand user needs that don't yet know through direct experience. That
is why Wikimedia hires people with academic and professional experience in
these fields.
On Thu, Mar 19, 2015 at 6:06 AM MZMcBride z...@mzmcbride.com wrote:

 Vibha Bamba wrote:
  I tried to get into that conversation and leave a message for Kevin
 Song. I could not use the regular talk page after using flow for
 Hovercards for the last 12 months. This is what millions of readers
 getting into the system feel like.

 Click edit.

  I hope flow ships this year.
  Concerned sighs.

 Just curious, what's the concern? Wikipedia's SEO? Have you read comments
 on other sites (e.g., YouTube) and compared to comments on Wikimedia
 wikis? There's a real cost to reducing barrier to entry. And, for what
 it's worth, tens of thousands of people engage in lengthy, sometimes
 multi-year, conversations using wikitext. Perhaps you're the outlier. :-)

 I hope people working directly on Flow have mastered wikitext talk pages.
 As we've previously discussed on this mailing list, it's incredibly
 difficult to build a better solution without first fully understanding the
 use-cases, requirements, and intricacies of the current system.

 MZMcBride



 ___
 Design mailing list
 Design@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/design

___
Design mailing list
Design@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

Re: [Wikimedia-l] Announcement: WMF to file suit against the NSA

[Steven Walling]

On Fri, Mar 13, 2015 at 7:00 AM Andreas Kolbe jayen...@gmail.com wrote:

 Steven Walling has written an interesting answer on Quora about one aspect
 of the New York Times op-ed, i.e. the threat NSA surveillance supposedly
 poses to Wikipedians living under oppressive regimes:

 https://www.quora.com/Would-stopping-NSA-surveillance-
 really-make-Wikipedia-editors-living-under-repressive-
 governments-safer/answer/Steven-Walling


Chiming in since this is my answer... Keep in mind questions on Quora are
pretty tightly scoped, i.e. this isn't necessarily an indictment of the
rationale for suing NSA overall. It's an answer to a specific aspect of the
arguments. If we want to argue about whether NSA dragnet surveillance is
overall a threat to Wikipedia as an educational project, there's a whole
other set of arguments that I think potentially support this action,
including the fact that a complete lack of privacy has a chilling effect on
editing regardless of what country you reside in, and that we promise
readers that their reading activity isn't tracked.**

The big tradeoff for me as a Wikipedian is whether this suit takes time,
attention, and funds away from tackling core challenges like the decline in
readership, editor recruitment/retention, and modernizing our software
platform. I think the fact that this is being led by ACLU, and that the
main cost to WMF seems to be in some time/attention of legal, comms, etc.
makes me feel a bit more comfortable. I do worry about dragging away Lila's
attention from these deep intractable problems with the ecosystem, but I'm
not really comfortable standing up to say this whole endeavor is a waste of
time or a bad use of the brand. We also don't really know how this is
dominating her or any other staffer's time, because we're not their bosses.
(Thankfully for them.)

** If anyone here wants to add their 2 cents, please do. There's also a
question at
https://www.quora.com/Wikimedia-Lawsuit-Against-the-NSA-2015/How-do-Wikipedia-editors-feel-about-the-lawsuit-against-NSA
which is relevant.



 ___
 Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
 wiki/Mailing_lists/Guidelines
 Wikimedia-l@lists.wikimedia.org
 https://meta.wikimedia.org/wiki/Mailing_lists/guidelineswikimedi...@lists.wikimedia.org
 Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
 mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

[Design] Wikiwand iOS app released

[Steven Walling]

The CEO announced on Quora ;-)

http://qr.ae/jFd21
___
Design mailing list
Design@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

Re: [Wikitech-l] S Page debuts as Technical Writer

[Steven Walling]

Congrats S! You'll do great at this and MediaWiki sure needs your help.
On Mon, Jan 5, 2015 at 3:59 PM Subramanya Sastry ssas...@wikimedia.org
wrote:

 On 01/05/2015 04:06 PM, Quim Gil wrote:
  It is an honor to announce that S Page[1] has moved from the
 Collaboration
  (Flow) team to join the WMF Engineering Community team as a Technical
  Writer[2]. We were really lucky to find such a great combination of
 English
  communication skills, awareness of MediaWiki documentation pain points,
  more-than-basic MediaWiki development experience, and Wikimedia community
  mileage.
  
  Welcome S to your new role and to the Engineering Community team!
  ...

 Congrats, S! :-)

 Subbu.

 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikimedia-l] Commons copyright extremism

[Steven Walling]

I just noticed a disturbing trend on Commons that highlights a general
issue with its use as the media repository for our projects.

I recently had an image nominated for deletion under Commons policy against
photos of packaging: https://commons.wikimedia.org/wiki/Commons:PACKAGING.
It was of some Japanese candy that someone brought back.

The first issue here is one of demotivating contributors. I took a photo of
an object I owned, and gave it away to be used in Wikipedia. The only
interaction I ever get on Commons about my photos is a notification of when
some fussy neckbeard wants to delete them. No thanks for thousands of
uploads. No notification of how many views they produce for our projects.
No message about downloads for free reuse.

The second issue is what this policy implicates for the scope of Commons. A
huge part of modern life includes things that have logos, artwork, jingles,
etc. This policy seems to imply to me that not just food packaging, but any
photo of a physical or digital product cannot be freely licensed even if
you own it. This covers a huge swath of knowledge to share which by
definition can't be on Commons anymore because we decided to take a very
conservative position on licensing. We are taking away useful photos from
our readers, which basically every other media repository that allows
CC/public domain licensing would allow.

We currently push users to upload to Commons when they want to give photos
to Wikipedia, and I have long done the same. I also used to be a Commons
admin. But this makes me think twice about ever uploading anything to
Commons, since even what seems like photos I own get subjected to an
extremely hardline copyright regime that no other site (say like Flickr)
would ever reasonably enforce on contributors. I'm also not going to bother
uploading to Wikipedia a simple photo of food products if I have to fill
out a form for fair use rationales.

In the long run, I think this kind of thing is yet more evidence that it
was a huge mistake to create a sub-community within Wikimedia that cares
more about strict free licensing than it does about utility to people who
need knowledge. Commons should really just have stayed a database shared
among projects, not been made into a wiki where all our more important
projects are subject to the rules mongering of a tiny broken community.
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Commons copyright extremism

[Steven Walling]

This kind of response is case in point on why people find Commons toxic.
On Thu, Dec 11, 2014 at 8:44 AM Russavia russavia.wikipe...@gmail.com
wrote:

 Steven,

 Quite seriously, if you can't understand the concept of copyright and
 derivative works, then perhaps this is not the project for you.

 There's nothing more to say.

 Russavia


 On Fri, Dec 12, 2014 at 12:40 AM, Steven Walling
 steven.wall...@gmail.com wrote:
  I just noticed a disturbing trend on Commons that highlights a general
  issue with its use as the media repository for our projects.
 
  I recently had an image nominated for deletion under Commons policy
 against
  photos of packaging: https://commons.wikimedia.org/
 wiki/Commons:PACKAGING.
  It was of some Japanese candy that someone brought back.
 
  The first issue here is one of demotivating contributors. I took a photo
 of
  an object I owned, and gave it away to be used in Wikipedia. The only
  interaction I ever get on Commons about my photos is a notification of
 when
  some fussy neckbeard wants to delete them. No thanks for thousands of
  uploads. No notification of how many views they produce for our projects.
  No message about downloads for free reuse.
 
  The second issue is what this policy implicates for the scope of
 Commons. A
  huge part of modern life includes things that have logos, artwork,
 jingles,
  etc. This policy seems to imply to me that not just food packaging, but
 any
  photo of a physical or digital product cannot be freely licensed even if
  you own it. This covers a huge swath of knowledge to share which by
  definition can't be on Commons anymore because we decided to take a very
  conservative position on licensing. We are taking away useful photos from
  our readers, which basically every other media repository that allows
  CC/public domain licensing would allow.
 
  We currently push users to upload to Commons when they want to give
 photos
  to Wikipedia, and I have long done the same. I also used to be a Commons
  admin. But this makes me think twice about ever uploading anything to
  Commons, since even what seems like photos I own get subjected to an
  extremely hardline copyright regime that no other site (say like Flickr)
  would ever reasonably enforce on contributors. I'm also not going to
 bother
  uploading to Wikipedia a simple photo of food products if I have to fill
  out a form for fair use rationales.
 
  In the long run, I think this kind of thing is yet more evidence that it
  was a huge mistake to create a sub-community within Wikimedia that cares
  more about strict free licensing than it does about utility to people who
  need knowledge. Commons should really just have stayed a database shared
  among projects, not been made into a wiki where all our more important
  projects are subject to the rules mongering of a tiny broken community.
  ___
  Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
 wiki/Mailing_lists/Guidelines
  Wikimedia-l@lists.wikimedia.org
  Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
 mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

 ___
 Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
 wiki/Mailing_lists/Guidelines
 Wikimedia-l@lists.wikimedia.org
 https://meta.wikimedia.org/wiki/Mailing_lists/guidelineswikimedi...@lists.wikimedia.org
 Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
 mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Commons copyright extremism

[Steven Walling]

On Thu Dec 11 2014 at 12:40:09 PM Pipo Le Clown plecl...@gmail.com wrote:

 I'm on the road every two weekends, and processing pictures the rest of the
 time on my free time. I've provided around 8000 pictures to Commons, and
 helped to have pictures for articles like Cristiano Ronaldo, Roy Hogdson or
 Greig Laidlaw...

 Just to read that I'm a fascist and an anal retentive because someone
 proposed a fucking picture of KitKat for deletion ? It was not even
 deleted, the discussion is still going on. And even if it was, the right
 place to go would have been COM:UDR, with a strong rationale, where people
 would have discuss it in a civilised manner. Not in this echo chamber...

 So yes, one could say that the thread was accusatory from the start, and
 quickly went to vicious. One could also say that this is a fucking
 disgrace.

 Pleclown


To be crystal clear: I didn't link to the DR or mention the nominator
because I don't actually care much about the individual instance.
Commons is going to do what it's going to do, and whomever nominated it or
comments in support of deletion is just doing what the policies of Commons
is telling them to do.

The problem is a general one with the goals of Commons, what the community
focuses (and doesn't focus on), as I said. I think it should be clear that
the purpose of discussing it on Wikimedia-l as opposed to Commons is talk
about whether Commons is doing a good job of serving as the media
repository for other projects. Not about whether the nominator was correct
in this individual case or something like that.



 On Thu, Dec 11, 2014 at 7:51 PM, Austin Hair adh...@gmail.com wrote:

  Okay, guys, let's all take a step back and remember [[WP:Civility]].
  (Yeah, I know that's a Wikipedia pillar, but can't we all at least get
  on board with that one?)
 
  The tone of this thread was accusatory from the start, and quickly
  went to vicious. Maybe everyone can try it again with a bit of AGF.
 
  Austin
 
 
  On Thu, Dec 11, 2014 at 7:30 PM, James Alexander jameso...@gmail.com
  wrote:
   On Thu, Dec 11, 2014 at 10:14 AM, Fæ fae...@gmail.com wrote:
  
   P.S. Stephen, you are young and handsome, in fact rather dishy to my
   ageing eyes. Good for you. Keep in mind that your fellow volunteers
   might not have been born so lucky, and that being young and pretty all
   too soon passes into memory, sigh.
  
  
   Fæ, this is not acceptable for the list (or for that matter on wiki).
   Stephen's neckbeard comment certainly wasn't helpful either but it's no
   excuse.
  
   James
   ___
   Wikimedia-l mailing list, guidelines at:
  https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
   Wikimedia-l@lists.wikimedia.org
   Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
  mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
 
  ___
  Wikimedia-l mailing list, guidelines at:
  https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
  Wikimedia-l@lists.wikimedia.org
  Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
  mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
 
 ___
 Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
 wiki/Mailing_lists/Guidelines
 Wikimedia-l@lists.wikimedia.org
 https://meta.wikimedia.org/wiki/Mailing_lists/guidelineswikimedi...@lists.wikimedia.org
 Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
 mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikitech-l] Our CAPTCHA is very unfriendly

[Steven Walling]

MZ: you mean removing just for account creation right? There is also a
CAPTCHA delivered on external link addition for some editors–I think IPs
and users not autoconfirmed. This is probably a lot more important for
combating spam.

(Sorry for top posting. On my phone.)
On Wed, Dec 3, 2014 at 8:03 PM MZMcBride z...@mzmcbride.com wrote:

 svetlana wrote:
 I like how my message to try abandoning captcha entirely came up with a
 myriad of complaints how we can be smart, enable new captcha which is
 unique, etc.
 
 Let's measure the impact.

 We disabled the CAPTCHA entirely on test.wikipedia.org a few weeks ago.
 The wiki seems to be about the same. It probably makes sense to continue
 slowly disabling the CAPTCHA on wikis until users start to shout. Perhaps
 we'll disable the CAPTCHA on the rest of the phase 0 wikis next?

 MZMcBride



 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Our CAPTCHA is very unfriendly

[Steven Walling]

On Wed Dec 03 2014 at 8:57:38 PM MZMcBride z...@mzmcbride.com wrote:

 Steven Walling wrote:
 MZ: you mean removing just for account creation right? There is also a
 CAPTCHA delivered on external link addition for some editors–I think IPs
 and users not autoconfirmed. This is probably a lot more important for
 combating spam.

 For testwiki, we actually set $wmgEnableCaptcha to false, which disabled
 both ConfirmEdit and FancyCaptcha entirely. My suspicion is that we need
 enhanced spam protection only on larger wikis and on a few smaller wikis
 that happen to be the target of spammers for whatever reason. Even on
 sites that are frequent spam targets, smarter heuristics, as Robert
 suggests, and existing tools such as AbuseFilter may be sufficient.


Yeah I agree it doesn't matter on testwiki to turn it off 100%. I'd suggest
we not do that for larger wikis though.

There are about a million IP edits a month on English Wikipedia alone, last
time we checked.[1] If we increased anonymous bot spam by even only 1/10th
of the total number of edits before we managed to put IP blocks in place,
that's still 100k edits worth of spam. And we might not want to use
something like Special:Nuke on an IP, since it may be shared with legit
edits. However, for account creation, there were only ~21,000 registrations
last month and it's automatically rate limited by IP even without CAPTCHA,
so experimenting in that area is much safer.

1.
https://meta.wikimedia.org/wiki/Research:Anonymous_editor_acquisition/Volume_and_impact




 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikimedia-SF] WikiCheese California

[Steven Walling]

I'm definitely in.
On Mon, Dec 1, 2014 at 9:49 PM Stephen LaPorte stephen.lapo...@gmail.com
wrote:

 Hey Frank,

 This is an awesome idea! I'm interested.

 On Mon, Dec 1, 2014 at 6:30 PM, Frank Schulenburg 
 fr...@wikiphotographer.net wrote:

 Hi all,

 I was wondering whether anyone here would be interested in helping me to
 improve Wikipedia's coverage on cheese.

 Cheese? Yes. Background is that the French chapter recently started a
 project called WikiCheese.[1] Wikipedia's coverage of food-related topics
 is patchy and articles about cheese are not an exception. So, French
 community members started WikiCheese, which aims at systematically filling
 content gaps.[2]

 Now, Northern California has an incredibly rich and interesting artisan
 cheesemaker scene.[3] Cowgirl Creamery (Point Reyes Station), Epicurean
 Connection (Sonoma), Vella Cheese Company (Sonoma)… just to name a few.

 Last weekend, I went on a tour and started photographing a couple of
 cheeses as well as cheese production at Cowgirl Creamery:

 https://commons.wikimedia.org/wiki/Category:WikiCheese_California

 I'm wondering whether any of you on this list would like to join me on my
 next excursion (date and time tbd.) You

 * don't need to be a cheese expert (I'm not)
 * don't need a fancy camera (actually, text contributions would be highly
 welcome as well)
 * don't necessarily need to own a car (I do)

 All you need is some time and enthusiasm :-)

 I haven't yet started a project page on Wikipedia – so in case you're
 interested, please send a reply to this list. Once a few people show their
 interest, we'll plan the next steps.

 Thanks,

 Frank

 [1]
 http://www.telegraph.co.uk/news/worldnews/europe/france/11254146/Wikipedia-asks-French-help-to-explain-cheese-with-WikiCheese.html
 [2] Some image results:
 https://commons.wikimedia.org/wiki/Category:Wikicheeses/0
 [3] http://cheesetrail.org

 ___
 Wikimedia-SF mailing list
 Wikimedia-SF@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikimedia-sf


 ___
 Wikimedia-SF mailing list
 Wikimedia-SF@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikimedia-sf

___
Wikimedia-SF mailing list
Wikimedia-SF@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikimedia-sf

Re: [Wikitech-l] Our CAPTCHA is very unfriendly

[Steven Walling]

On Fri, Nov 7, 2014 at 2:19 PM, MZMcBride z...@mzmcbride.com wrote:

 I think that's unfair.

 Wikis have a serious spam problem. People associate CAPTCHAs with spam
 prevention. On the English Wikipedia, one of the actions that results in
 the user being required to successfully enter a CAPTCHA is adding an(y?)
 external link to a page as a newly registered user. This, of course, in
 addition to the CAPTCHA presented when registering an account (consider
 that many new account creations only come about as the result of the
 requirement for an account to make a new page on the English Wikipedia).

 Why not disable the extension for a week and see what happens? If you're
 wrong and there's a marked increase in wiki spam (account creations and
 edits), then you can help devise a better solution than a CAPTCHA.
 CAPTCHAs are clearly not a sustainable fix to the underlying problems they
 were implemented to address, or so I think you're saying. If you're right
 and the CAPTCHA is simply ineffective and unneeded, we've eliminated some
 code from production and we can move on. In other words: what exactly is
 stopping you from disabling the extension?


When we did usability tests of the new version and the old version, it was
exceedingly clear that what Jon has said is true: the CAPTCHA is by far the
most painful part of our signup form. Results and videos of those tests at:
https://www.mediawiki.org/wiki/Account_creation_user_experience/User_testing

Back in the day, when we did the last redesign of the signup form, we
considered running an A/B test of removing the CAPTCHA. Docs for that are
at https://meta.wikimedia.org/wiki/Research:Account_creation_UX/CAPTCHA

The turn it off for a week and see what happens with spam test is the
easiest implementation of the above, and even though normally it's a great
way to produce garbage data (not being a controlled experiment) I'd be in
favor of trying it. Every indication we have is that we'd get marked
increases in signup conversion rates (ours are not great -- only 30% of
visitors complete the form successfully IIRC).

For some more background, when we proposed something like that to Chris
Steipp he was pretty iffy about it, and he's not wrong. At other sites that
don't have a CAPTCHA on signup (like Facebook, Quora, others) they avoid a
spam problem in part because they require an email address and
confirmation. For some irrational reason, even in the era of throwaway
email accounts from web services, not requiring email is some kind of
sacred cow among Wikimedians, even if it would make it an easy choice to
throw away our wretched CAPTCHA.

If we want to avoid spam bots signing up, there is going to be a hit in
ease of use somewhere. Our network of sites is just too large to avoid
being a target. It's just a matter of testing to see how much we can reduce
that hit, and which method might be less easy.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikimedia-l] thank vs. like

[Steven Walling]

On Sun Oct 26 2014 at 12:45:55 PM Amir E. Aharoni 
amir.ahar...@mail.huji.ac.il wrote:

 In the Hebrew Wikipedia there's a discussion about the Thanks feature,
 which raises the following confusion among other things: Why does the
 person who is sending the thank-you gets a message saying $1 was notified
 that you liked his/her edit., and the person who receives the thank-you
 notification sees a message that uses the verb thank?


So this message, called thanks-thanked-notice in the code, appears to
have been added awhile back without sufficient design review or
input.[1][2] It's not part of the original design requirements for Thanks.

It's unclear from the bug or commit that added it exactly why we need this
message, or where it appears. Do you get this via your notifications tray?

I'd support simply removing this notification. The UI already makes clear
in-line when a thanks was sent. Unless people really requested a read
status notification and find it valuable, we should just defer to keeping
notifications volume low.

1.
https://git.wikimedia.org/commitdiff/mediawiki%2Fextensions%2FThanks/ab8b7847c36bf0b053a397ec5689c6a9b9615bd5
2. https://bugzilla.wikimedia.org/show_bug.cgi?id=63509
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikitech-l] Looking for project status updates

[Steven Walling]

On Thu, Oct 23, 2014 at 12:27 AM, Erik Moeller e...@wikimedia.org wrote:

 Yes, the Growth team was disbanded, and the engineers working on this
 team are now supporting Mobile (Rob Moen, Sam Smith) and Flow (Matt
 Flaschen). We'll be updating wiki pages as we go, but help is welcome.


Meta, MediaWiki.org, and English Wikipedia docs are all updated to mark
appropriate documentation hubs as historical. Sorry for any confusion Pine.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Analytics] LinkedIn Samza Use

[Steven Walling]

On Thu, Sep 18, 2014 at 11:37 AM, Andrew Otto aco...@gmail.com wrote:


 http://engineering.linkedin.com/samza/real-time-insights-linkedins-performance-using-apache-samza


You can play with this after we figure out how to do basic shit like count
pageviews and run an A/B test without rebuilding the wheel.

/troll


-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
___
Analytics mailing list
Analytics@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/analytics

Re: [Wikitech-ambassadors] Task recommendations for new editors

[Steven Walling]

On Fri, Sep 12, 2014 at 5:32 AM, Jérémie Roquet arkano...@gmail.com wrote:


 It seems that not-so-newly-registered editors are concerned as well,
 and some of them are wondering how to disable this new feature¹. Any
 tip that doesn't involve dirty hacking with JavaScript and CSS?

 Thanks!

 ¹
 https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Le_Bistro/12_septembre_2014#Recommandations


Hi Jeremie,

This is https://bugzilla.wikimedia.org/70759 which strangely seem to be
present on German and French Wikipedias, but not English.

We'll be addressing this bug as our top priority today. However, we don't
normally deploy code on Fridays (to avoid any further mess on the weekend)
so it may have to wait till Monday. Either way, we will either fix the
issue or disable the test temporarily while we debug. I can also give
editors CSS to remove recommendations for themselves, if it's really
bugging them.

Thanks for your email,

-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
___
Wikitech-ambassadors mailing list
Wikitech-ambassadors@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors

Re: [Translators-l] GettingStarted extension

[Steven Walling]

On Thu, Sep 11, 2014 at 3:34 PM, Jon Harald Søby jhs...@gmail.com wrote:

 How about a link to where the rest of us can translate it?

Sure. It's a part of the GettingStarted extension on translatewiki, and you
can find your language at
https://translatewiki.net/w/i.php?title=Special%3AMessageGroupStatsx=Dgroup=ext-gettingstartedsuppressempty=1language=


-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
___
Translators-l mailing list
Translators-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/translators-l

Re: [Wikitech-ambassadors] Task recommendations for new editors

[Steven Walling]

On Thu, Sep 4, 2014 at 6:12 PM, Steven Walling swall...@wikimedia.org
wrote:

 This is a quick notice and a call for help from translators: likely next
 week, we'll be launching a new experiment aimed at helping newly-registered
 editors, called task recommendations. You can check out the UI by looking
 at the design specification (
 https://www.mediawiki.org/wiki/Task_recommendations) and our research
 documentation (
 https://meta.wikimedia.org/wiki/Research:Task_recommendations/Experiment_one
 )

 The good news: the main interfaces are well translated enough for us to
 launch our A/B test in 12 languages...

 - English
 - German
 - French
 - Spanish
 - Italian
 - Russian
 - Chinese
 - Ukrainian
 - Swedish
 - Dutch
 - Hebrew

 The bad news: we needed to add some error messages for the rare occasion
 that something goes wrong. These are *almost* merged and will ideally
 also get translated too.

 If you speak these languages and/or know someone who is a translator on
 Translatewiki, then it would be great to keep an eye out for untranslated
 strings coming soon in the GettingStarted extension.


Heads up that the error messages and other changes have been finished, so
we are deploying these tests today. German and Hebrew are finished with
100% of translation, but rest of the list above needs to do the error
messages as well.

Thanks again for all the speedy help from translators. You're all amazing.


-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
___
Wikitech-ambassadors mailing list
Wikitech-ambassadors@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors

Re: [Design] Getting $wgUseMediaWikiUIEverywhere = true to be the default

[Steven Walling]

On Mon, Sep 8, 2014 at 8:04 PM, Jon Robson jdlrob...@gmail.com wrote:

 We already seem very stretched and code review is slow. I would like us to
 exercise caution on adding new things to the styleguide. Most of the work
 so far has been moving existing components from repositories into core so
 that other teams can share their work.

 I don't think we should be adding new components without delivering user
 value. We should be looking to build new components first as and when
 needed in our projects whether it be mobile, VE, Flow, Multimedia work etc..

 I really would encourage us to focus on forms and the bare minimum needed
 to get this out into production.


I 100% agree with the above Jon.

Erik is right that the new checkboxes look weird next to the old style
controls, such as on Preferences. Since we don't want to add new controls
that teams don't yet need, why don't we just remove the checkboxes for now,
and just focus on getting text input + button styles out the door?


 Radio buttons and select menus seem like the missing pieces of the
 puzzle right now that will make the LSG seem more complete and help us push
 through these form designs. I'd really encourage us to focus on getting
 those through - are there any teams currently needing these or is this
 likely to be a 20% type project?


Rather than restyle more elements, let's just reduce scope rather than
cause creep.

-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
___
Design mailing list
Design@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

Re: [Wikimedia-l] Endless drama around solutions to non-problems as misdirection

[Steven Walling]

On Sat, Sep 6, 2014 at 1:54 AM, James Salsman jsals...@gmail.com wrote:

 Steven Walling wrote:
 ...
  We practically can't and don't take on initiatives that directly
  try to provide more free time or money to editors

 That is absolutely false. Individual Engagement Grants have recently
 been proven to be substantially more cost-effective in achieving the
 Foundation's stated goals than any other form of grant spending, on a
 per-dollar basis. Is there any evidence that any Foundation
 engineering effort of the past five years has done as well? I haven't
 seen any.


Individual engagement grants are not a monetary reward for contributing
content. They are, just like larger programs internally at WMF or in a
chapter, intended to produce another outcome which has a wider and more
sustainable impact. Suggesting that the success of IEG is evidence we
should/could just pay editors directly in some way is quite the stretch.

Providing cash on a large scale to motivate contributors has diminishing
returns as an alternative strategy to usability improvements, when you
consider that the software platform which enables content creation will
continue to show its age. Even if we lived in a parallel universe where
every editor of Wikipedia was paid for their work, we'd still need to
continually improve the platform they used to make the encyclopedia.

It's interesting you bring up IEG though. If you're not talking about 1:1
alternatives to software improvements, but instead you want us to consider
potentially complementary new ideas to motivate people to edit... go for
it. No one can deny the positive impact of initiatives like The Core
Contest on English Wikipedia (I've been a contestant myself).[1] Piloting a
larger scale set of contests where there are rewards or prizes for winners
might be a pretty cool IEG project that could prove your theory.

1. https://en.wikipedia.org/wiki/Wikipedia:The_Core_Contest
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Design] Getting $wgUseMediaWikiUIEverywhere = true to be the default

[Steven Walling]

On Fri, Sep 5, 2014 at 2:08 PM, Erik Moeller e...@wikimedia.org wrote:

 The appearance/size change for e.g. checkboxes is very noticeable, and
 right now it's inconsistent with other controls that are nearby, like
 radiobuttons and dropdowns. The first thing is to actually finish the style
 guide and consistently apply it.
 http://tools.wmflabs.org/styleguide/desktop/index.html is very incomplete
 right now, when can we expect an updated version, or is there another one I
 should be looking at?


This is a situation that's partially a consequence of how we've decided to
generate the living style guide. It only reflects what is in the codebase
now really, so it doesn't (and really can't) contain style guidelines for
future iterations on other controls.

The best place to see proposed designs is the Trello board for mediawiki.ui
(https://trello.com/b/EXtVTJxJ). When things are finalized enough on the UX
side to more seriously request Jared is pushing them to Bugzilla.


-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
___
Design mailing list
Design@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments

[Steven Walling]

On Fri, Sep 5, 2014 at 1:48 PM, John Mark Vandenberg jay...@gmail.com
wrote:

 IMO the WMF should stop focusing on English Wikipedia as a target
 deploy site, and stop allowing its product management team and WMF
 staff in general to be salesman for it - it is scaring the community
 that all WMF staff seem to be so heavily vested in this 'product' as
 the salvation of the wikis.


This is rank hyperbole.

The MediaWiki deployment train delivers new software to all projects every
week. One stage is to non-Wikipedia projects, which actually get new
software *first.* Then in a second stage is for all Wikipedias
simultaneously. So the default behavior for rollouts, if all you do is
merge your code and wait, is that English Wikipedia gets basically no
special treatment..[1]

Now, for larger feature rollouts like VisualEditor or MediaViewer, the
testing stage and eventual launch set their own special schedule. We have
used English Wikipedia as a testing ground a lot in the past, which is
natural when you consider a variety of factors.[2] That doesn't mean we
haven't worked hard to test things out with non-English projects. Some
examples:

-- MediaViewer spent a long time being tested outside English Wikipedia
before it ever touched that project. It started with pilots in non-English
Wikipedias and English Wikivoyage.[3]
-- Flow is currently soliciting editors on non-English projects to test it
out voluntarily on a sub-set of pages. Any projects that want to help shape
the future of this software should pick a discussion space they want to use
for testing and speak up.
-- My team (Growth) has begun waiting for translations of experimental
interfaces, so we can A/B test in many languages simultaneously. We're
about to do this again in this month, by testing task recommendations in 12
languages right from the start.[4] We've done with other projects as well,
like A/B testing changes aimed at anonymous editors in four languages.
-- The Content Translation project is starting with Spanish and Catalan
Wikipedias.[5]

After we get past the testing stage, none of this erases the fact that
English Wikipedia is still the largest project by far, and is a major
problem spot to be dealt with regarding issues related to new editor
acquisition and retention. The data clearly suggests that it's a project we
should be focusing on if we want to fix these problems, but we're certainly
not ignoring others.

1). wikitech.wikimedia.org/view/Deployments
2). All technical staff and community contributors share English as their
working language. Software gets built in English first obviously, so we
don't have to wait on translations as a blocker for deployment. English
Wikipedia is also our largest project, so we can get larger randomized
samples during A/B tests. Making A/B tests shorter while also retaining
accuracy is good.
3). https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Release_Plan
4).
https://meta.wikimedia.org/wiki/Research:Task_recommendations/Experiment_one
5). https://www.mediawiki.org/wiki/Content_translation/Roadmap
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

[Wikitech-ambassadors] Task recommendations for new editors

[Steven Walling]

Hi everyone,

This is a quick notice and a call for help from translators: likely next
week, we'll be launching a new experiment aimed at helping newly-registered
editors, called task recommendations. You can check out the UI by looking
at the design specification (
https://www.mediawiki.org/wiki/Task_recommendations) and our research
documentation (
https://meta.wikimedia.org/wiki/Research:Task_recommendations/Experiment_one
)

The good news: the main interfaces are well translated enough for us to
launch our A/B test in 12 languages...

- English
- German
- French
- Spanish
- Italian
- Russian
- Chinese
- Ukrainian
- Swedish
- Dutch
- Hebrew

The bad news: we needed to add some error messages for the rare occasion
that something goes wrong. These are *almost* merged and will ideally also
get translated too.

If you speak these languages and/or know someone who is a translator on
Translatewiki, then it would be great to keep an eye out for untranslated
strings coming soon in the GettingStarted extension.

If you're curious about how the recommendations are generated or anything
else, let me know. :)

Thanks,

-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
___
Wikitech-ambassadors mailing list
Wikitech-ambassadors@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors

Re: [Design] Praise for the mobile site

[Steven Walling]

On Monday, September 1, 2014, Sarah slimvir...@gmail.com wrote:

 One thing I've noticed about the mobile site, and that I see is being
 discussed in various places, is that there's no obvious way to get to
 article talk pages. Am I just missing it?

 Sarah


No, there is not an obvious way for now, though you can of course still use
Search to get to any page.




 On Thu, Aug 28, 2014 at 3:37 PM, Jon Robson jdlrob...@gmail.com
 javascript:_e(%7B%7D,'cvml','jdlrob...@gmail.com'); wrote:

 I created a bug to capture these issues
 https://bugzilla.wikimedia.org/show_bug.cgi?id=70142

 The DJ where are you seeing this exception being thrown? I had thought
 that the desktop skin forced the mobile target to avoid these issues
 but maybe I am wrong...

 On Wed, Aug 27, 2014 at 2:02 AM, Derk-Jan Hartman
 d.j.hartman+wmf...@gmail.com
 javascript:_e(%7B%7D,'cvml','d.j.hartman%2bwmf...@gmail.com'); wrote:
  I do note that due to the mobile vs desktop targets of resource loader
  behavior, the desktop site seems to have a few problems when using
  minerva. I get ReferenceError: Can't find variable: importScript
  global code (index.php, line 14) when I used the useskin=minerva
 approach.
 
  DJ
 
  On Wed, Aug 27, 2014 at 1:53 AM, Jon Robson jdlrob...@gmail.com
 javascript:_e(%7B%7D,'cvml','jdlrob...@gmail.com'); wrote:
  I forgot to add if we set $wgMFEnableMinervaBetaFeature = true it also
  registers it as a beta feature. Another option at our disposal...
 
 
  On Tue, Aug 26, 2014 at 4:53 PM, Jon Robson jdlrob...@gmail.com
 javascript:_e(%7B%7D,'cvml','jdlrob...@gmail.com'); wrote:
  Only because of a single line of code. We can surface it in
  Special:Preferences easily but I suspect we'll want to fix some of the
  caveats first... we just have to remove the code here [1]
 
  [1]
 https://gerrit.wikimedia.org/r/#/c/118037/7/includes/MobileFrontend.hooks.php
 
  On Tue, Aug 26, 2014 at 4:46 PM, Steven Walling 
 swall...@wikimedia.org
 javascript:_e(%7B%7D,'cvml','swall...@wikimedia.org'); wrote:
 
  On Tue, Aug 26, 2014 at 4:41 PM, Jon Robson jdlrob...@gmail.com
 javascript:_e(%7B%7D,'cvml','jdlrob...@gmail.com'); wrote:
 
  It's actually very trivial to enable Minerva on desktop. Currently
 you
  can do so appending useskin=minerva e.g.
  https://en.wikipedia.org/wiki/Franklin_D._Roosevelt?useskin=minerva
  but we purposely hide it from the preferences. This is easy to
 rectify
  though if you wanted us to.
 
 
  Yeah but that's not persistent across views right?
 
  Tomasz: thanks for the tip. I'll give it a spin. ;)
 
 
 
  --
  Steven Walling,
  Product Manager
  https://wikimediafoundation.org/
 
  ___
  Design mailing list
  Design@lists.wikimedia.org
 javascript:_e(%7B%7D,'cvml','Design@lists.wikimedia.org');
  https://lists.wikimedia.org/mailman/listinfo/design
 
 
 
 
  --
  Jon Robson
  * http://jonrobson.me.uk
  * https://www.facebook.com/jonrobson
  * @rakugojon
 
 
 
  --
  Jon Robson
  * http://jonrobson.me.uk
  * https://www.facebook.com/jonrobson
  * @rakugojon
 
  ___
  Design mailing list
  Design@lists.wikimedia.org
 javascript:_e(%7B%7D,'cvml','Design@lists.wikimedia.org');
  https://lists.wikimedia.org/mailman/listinfo/design
 
  ___
  Design mailing list
  Design@lists.wikimedia.org
 javascript:_e(%7B%7D,'cvml','Design@lists.wikimedia.org');
  https://lists.wikimedia.org/mailman/listinfo/design



 --
 Jon Robson
 * http://jonrobson.me.uk
 * https://www.facebook.com/jonrobson
 * @rakugojon

 ___
 Design mailing list
 Design@lists.wikimedia.org
 javascript:_e(%7B%7D,'cvml','Design@lists.wikimedia.org');
 https://lists.wikimedia.org/mailman/listinfo/design




-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
___
Design mailing list
Design@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

Re: [Design] MediaWiki UI Forms

[Steven Walling]

On Thu, Aug 28, 2014 at 1:40 PM, Jon Robson jrob...@wikimedia.org wrote:

 On bug 65317 [1] it is suggested that the preferences page should have
 buttons aligned to the right and should be ordered so constructive is
 the last. I've written a fix for this and I would appreciate some code
 review.

 This had me wondering, should this apply to all forms? e.g. the editing
 form

 If so I think we probably need to get this into the style guide in
 some form, detailing how buttons should be ordered. We may want to
 introduce mw-ui-button-group or mw-ui-form-button-group.

 [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=65317


I think before we make a decision we need to think this through, by asking
two questions:

1. What do most users expect here, in terms of ordering? If we don't know,
how can we learn what they do expect?
2. If users expect the primary action to be on the right, how would this
change core forms other than Preferences, such as signup, login, editing
(in wikitext and VE)?

In the mean time, the simplest thing to do is not to rewrite Preferences to
make a new divergent standard, but just update the button classes without
mucking with the ordering. That's the minimum viable release for updating
Preferences to match mw.ui styles. This will provide the most benefit with
the least effort.

-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
___
Design mailing list
Design@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

Re: [Design] MediaWiki UI Forms

[Steven Walling]

On Thu, Aug 28, 2014 at 4:53 PM, Jared Zimmerman 
jared.zimmer...@wikimedia.org wrote:

 1) yes, the primary action will be rightmost, this could mean
 progressive, in the case of a multi-step form form, destructive in the case
 of process where the primary function is to delete something and
 constructive in the case of the final step in a single or multi-step
 process that creates something or finalizes a  non destructive process.

 2) they should be ordered from right to left in order of importance and
 frequency of use, there should only be one primary action. secondary
 actions should have neutral or quiet appearance.

 We will capture as many patterns and best practices in the mediawiki.ui
 living style guide as possible, however they will be a guide and set of
 best practices, and there will likely be exceptions, and places where the
 patterns break down.


 Without completely redesigning the bottom of the wikitext editor, the
 minimal mediawiki.ui version of the WTE bottom could go from

 [ Save Page ] [ Show Preview ] [ Show Changes ] Cancel

 to…

 *Cancel/Discard* (mw.destructive.quiet) *Show changes*
 (mw.progressive.quiet)  *Preview* (mw.progressive.quiet) *[ Save ]*
  (mw.constructive.normal)


Whether we change to follow this pattern needs to validated with users
before we attempt to standardize on it. If we're going to completely flip
the order of our actions on forms then we need to demonstrate that it's
worth it.


-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
___
Design mailing list
Design@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

Re: [Analytics] pitching the Gender Edit Dashboard

[Steven Walling]

On Thu, Aug 28, 2014 at 1:25 PM, Andrew Gray andrew.g...@dunelm.org.uk
wrote:

 I believe we did a one-question gender microsurvey before (linked to
 one of the new-user features?). I don't know whether the data was
 useful or not, but I do remember the act of asking the question itself
 got some pushback as being invasive/unwelcoming/weirdly
 communicated/etc. (and I can certainly symapthise with this)

 So as well as the value of the data, we should consider whether the
 act/method of asking is going to have knock-on effects on what we're
 trying to measure.


Yes, we've tried this once. It's documented at
https://meta.wikimedia.org/wiki/Research:Gender_micro-survey

Frankly this was pretty hackish and limited. The data is not garbage but
it's not the most elegant approach to a one question survey.

-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
___
Analytics mailing list
Analytics@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/analytics

[Design] Praise for the mobile site

[Steven Walling]

Wikipedia already looks great ... just add .m (on desktop)
https://news.layervault.com/stories/31897-wikipedia-already-looks-great--just-add-m-on-desktop

For those unfamiliar, this is a designer's equivalent to Hacker News.
Interesting to see professional UX designers be less forgiving towards the
WikiWand design, in addition to the warm fuzzies from the love for the
mobile site.

This kind of feedback makes me wish you could set your desktop skin to use
mobile (aka Minerva). Or may e have clicking the mobile view link set a
cookie for my session to auto-redirect to mobile. Otherwise, it's hard to
evaluate how the mobile view stands up over sustained use on desktop.

-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
___
Design mailing list
Design@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

Re: [Design] Praise for the mobile site

[Steven Walling]

On Tue, Aug 26, 2014 at 4:41 PM, Jon Robson jdlrob...@gmail.com wrote:

 It's actually very trivial to enable Minerva on desktop. Currently you
 can do so appending useskin=minerva e.g.
 https://en.wikipedia.org/wiki/Franklin_D._Roosevelt?useskin=minerva
 but we purposely hide it from the preferences. This is easy to rectify
 though if you wanted us to.


Yeah but that's not persistent across views right?

Tomasz: thanks for the tip. I'll give it a spin. ;)


-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
___
Design mailing list
Design@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design

[EE] Recommending things to edit

[Steven Walling]

Hi all,

I'd love to get some feedback on a new Growth team project: task
recommendations for Wikipedia editors. The design specification and
background for this is at
https://www.mediawiki.org/wiki/Task_recommendations. I also gave a brief
introduction to this at the last Foundation Metrics  Activities meeting,
viewable at https://www.youtube.com/watch?v=2JbZ1uWoKEg#t=3483

The two prototype recommendation systems are live now on Beta Labs (
en.wikipedia.beta.wmflabs.org). If you edit copies of real articles (like
Dog, Cat, or Cheese) you'll get some good results. However, this replica of
English Wikipedia is a bit slow, so be patient with us.

The next step for this project is to A/B test this with newly-registered
users on Wikipedia. Since translations of the interface have been pretty
quick (thank you translators!), we'll likely A/B test in at least English,
German, and French, if not other languages too. We've done some usability
testing, including at Wikimania, but we need to run a randomized experiment
to give us a first look at whether these recommendations can have a
positive impact on new editor productivity and retention.

Right now, the main goal of the recommendations we've built is to get
someone who's made their first few edits to keep going. That's why it only
looks at the last article you edited, and makes recommendations off of
that. In the future, we might consider doing something more sophisticated,
such as combing through your entire edit history to recommend articles. We
hope that we can build something which can be continually useful for a
content contributor as they get more experienced.

Thanks,

-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
___
EE mailing list
EE@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ee

[WikimediaMobile] [iOS app] Left-hand navigation menu

[Steven Walling]

Now that the left-hand navigation menu has expanded to six links, I'm
having a little trouble quickly scanning it to find the item I need.
Previously it was no issue, since there were only three or four links. Have
we considered adding icons?

-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [Wikimedia-l] editor retention initiatives

[Steven Walling]

On Sat, Aug 23, 2014 at 6:55 PM, James Salsman jsals...@gmail.com wrote:

 Is there a list somewhere of all currently active Foundation
 initiatives for attracting and retaining active editors?  I am only
 aware of the one project, Task Recommendations, to try to encourage
 editors who have made a few edits to make more, described starting at
  https://www.youtube.com/watch?v=2JbZ1uWoKEgt=60m20s


Task recommendations is one nascent initiative that my team is working
on.[1] We're still in the very early prototyping and testing stages. (BTW,
the whole video segment starts two minutes earlier at about the 58:00
mark.)

Task recommendations is far from the only thing we're doing to attract and
retain active editors. Pretty much the entirety of the features development
roadmap for desktop and mobile is focused on this problem. VisualEditor,
Flow, mobile web and apps work, and more all address this problem from
different angles. You can keep up with what the Foundation is doing by
checking out the monthly engineering reports.[2]


 Is there any evidence at all that anyone in the Foundation is
 interested in any kind of change which would make non-editors more
 inclined to edit, or empower editors with social factors which might
 provide more time, economic power, or other means to enable them to
 edit more?


We practically can't and don't take on initiatives that directly try to
provide more free time or money to editors. We can, however, help people do
more with the free time they have, and ask new people to become
contributors. Both of those are things we're tackling. A central goal of
improving the usability of the core editing experience across devices is to
save people time and energy. My team's also trying other things to attract
new community members, such as actually inviting people to sign up.[3]

1. https://www.mediawiki.org/wiki/Task_recommendations
2. https://www.mediawiki.org/wiki/Wikimedia_Engineering/Report/latest
3.
https://www.mediawiki.org/wiki/Anonymous_editor_acquisition#Invite_users_to_sign_up
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Design] mwui.wmflabs.org reactivated, showing upcoming MW UI styles ($wgUseMediaWikiUIEverywhere = true; )

[Steven Walling]

On Tue, Aug 19, 2014 at 3:29 PM, Jared Zimmerman 
jared.zimmer...@wikimedia.org wrote:

 Ok, I've been thinking about this for a bit. my suggestion is this…


 We create 3 more controls

- Dropdown https://trello.com/c/bdpbPSZT/4-drawer-menu
(can Juliusz's work on compact person bar be componentized?)
- Search Field https://trello.com/c/MC8ovuyw/2-advanced-input-fields
- Radio Button https://trello.com/c/df2N2KJx/8-radio-buttons

 Finalize 2 controls

- Check box (disabled state, disabled checked)
- Vform (vertical padding)

 Then let's make a Beta feature to allow people to test and see
 medaiwiki.ui in context in vector(at least) and report problems.

 I'd love to be able to provide a fixed element on screen that allows
 someone to quickly and easily report problems with a control on a
 particular page (isn't using mediawiki.ui style, isn't using right type
 (progressive, constructive, destructive) and right style normal, quiet,
 etc. and any issues around order or logic, e.g. on WTE Save should be the
 rightmost according to mediawiki.ui guidelines and there are too many
 Primary style buttons.

 *Jon*, perhaps you could brainstorm a fixed header element that allows
 someone to report an issue on their current page that generates bug reports
 or emails or something along those lines?

 Is there any way we could accelerate fixes reported by users more than our
 normal time span of 2-3 weeks? cc'ing *Greg* for his thoughts here about
 a way to do this without breaking things.

 This won't be our first Beta feature that is more for learning and testing
 with no plans to graduate but we should be clear that that's what its for
 in the description on the beta page, so people can give helpful and
 constructive feedback knowing that it will be an iterative process.


Like Erik said, we need to not be in a rush here. This thing is kind of a
mess and needs some basic design review first, before we charge ahead with
expanding the scope into new controls or a reporting tool like you
suggested. I also am very uncomfortable saying we should release a Beta
Feature we don't intend to graduate.

-- 
Steven Walling,
Product Manager
https://wikimediafoundation.org/
___
Design mailing list
Design@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design