Re: [Wikimedia-l] Profile of Magnus Manske

[Marc A. Pelletier]

On 2016-01-20 10:09 PM, Risker wrote:

Marc is not a member of the WMF staff.


[anymore].

But yeah, that was my personal opinion only and not any sort of 
staff-like thing - I was never involved in superprotect or its deployment.


I was hacking happily at Wikimania in London when I saw (a) parts of 
dewiki go insane over the media viewer followed by (b) parts of WMF go 
insane over the parts of dewiki going insane.  Hilarity ensued. My own 
reaction at the time, if I recall correctly, was "what an idiot" 
followed by "is [Erik] insane?  That is the single worst way of handling 
this".  Both were accompanied with copious facepalms.


-- Marc


___
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] Profile of Magnus Manske

[Risker]

On 20 January 2016 at 22:08, John Mark Vandenberg  wrote:

> On Wed, Jan 20, 2016 at 12:51 PM, Marc A. Pelletier 
> wrote:
> > On 2016-01-19 12:53 PM, Pine W wrote:
> >>
> >> The constitutional crisis that WMF created by using Superprotect to
> force
> >> Image VIewer on the communities [...]
> >
> >
> > ... except that this is not what happened.  While that narrative might be
> > satisfying for someone who looks for a sense of being the stalwart
> defender
> > of an oppressed community, the reality is that superprotect was created
> to
> > block the deployment of a technically inapt and entirely broken "fix"
> that
> > was - itself - a kneejerk reaction.
> >
> > Which is not to say that its creation or use was wise in any way - it
> > wasn't.  But trying to reframe things in "oh, evil WMF did all wrong
> against
> > the poor, innocent community" terms serves no purpose other than create a
> > windmill to tilt at.
>
> It is comments like this from WMF staff which make me think that WMF
> has not yet really internalised the reason why VE, MV, etc. were such
> a problem.
>
>
Marc is not a member of the WMF staff.

Risker/Anne
___
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] Profile of Magnus Manske

[John Mark Vandenberg]

On Wed, Jan 20, 2016 at 12:51 PM, Marc A. Pelletier  wrote:
> On 2016-01-19 12:53 PM, Pine W wrote:
>>
>> The constitutional crisis that WMF created by using Superprotect to force
>> Image VIewer on the communities [...]
>
>
> ... except that this is not what happened.  While that narrative might be
> satisfying for someone who looks for a sense of being the stalwart defender
> of an oppressed community, the reality is that superprotect was created to
> block the deployment of a technically inapt and entirely broken "fix" that
> was - itself - a kneejerk reaction.
>
> Which is not to say that its creation or use was wise in any way - it
> wasn't.  But trying to reframe things in "oh, evil WMF did all wrong against
> the poor, innocent community" terms serves no purpose other than create a
> windmill to tilt at.

It is comments like this from WMF staff which make me think that WMF
has not yet really internalised the reason why VE, MV, etc. were such
a problem.

-- 
John Vandenberg

___
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] Profile of Magnus Manske

[Pete Forsyth]

On Tue, Jan 19, 2016 at 5:51 PM, Marc A. Pelletier  wrote:

> On 2016-01-19 12:53 PM, Pine W wrote:
>
>> The constitutional crisis that WMF created by using Superprotect to force
>> Image VIewer on the communities [...]
>>
>
> ... except that this is not what happened.  While that narrative might be
> satisfying for someone who looks for a sense of being the stalwart defender
> of an oppressed community, the reality is that superprotect was created to
> block the deployment of a technically inapt and entirely broken "fix" that
> was - itself - a kneejerk reaction.
>

No, Marc. Your version is quite a stretch. According to Lila Tretikov --
the person responsible for rolling out Superprotect -- its legacy is that
it established a "precedent of mistrust
."

It was deployed to block something, but the thing that was technically
inept was the initial deployment of Media Viewer. Even if you (or WMF)
disagreed, there was no real cost to the alternative of disabling it by
default, with the possibility of fixing it and redeploying it.

Even now, more than a year later, independent news organizations and web
sites frequently cite the wrong person when reusing Commons photos -- they
cite the uploader, rather than the photographer. That bug (one of many) was
caught, has now been fixed (in the last couple of weeks). It was caught by
a photographer looking after his own attribution -- a photographer who did
not sign the Superprotect letter, if that matters -- not by Wikimedia staff.

Media Viewer was deployed before it was ready. There was no benefit to
doing so. Superprotect was deployed to reinforce that bad decision.

Which is not to say that its creation or use was wise in any way - it
> wasn't.  But trying to reframe things in "oh, evil WMF did all wrong
> against the poor, innocent community" terms serves no purpose other than
> create a windmill to tilt at.


The Wikimedia Foundation needs, first and foremost, to look after the
principle and unique asset that gives the Wikimedia and Wikipedia brands
value: its volunteer community. When the Wikimedia Foundation conducts
itself in a way that leads to division, it's damaging our shared vision,
and it needs to be held accountable. None of that is to say that the
Wikimedia Foundation should give way before a mob of pitchfork-wielding
anarchists; but to the repeated suggestion that that's what the community
(or those opposed to any specific software deployment) is, I say:

Citation needed.

-Pete
[[User:Peteforsyth]]
Author of letter objecting to Superprotect:
https://meta.wikimedia.org/wiki/Letter_to_Wikimedia_Foundation:_Superprotect_and_Media_Viewer
___
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] WMF trustee Arnnon Geshuri and part in anticompetitive agreements in Google

[George Herbert]

There was a finding of civil, not criminal, liability in the case.  Against the 
companies as a whole not individuals.

Generally such never becomes individual liability or criminality.


George William Herbert
Sent from my iPhone

> On Jan 20, 2016, at 6:12 PM, Ricordisamoa  
> wrote:
> 
> Has Arnnon been actually convicted of a felony? Where is presumption of 
> innocence?
> The firing was part of a larger system he seems unlikely to have set up on 
> his own volition.
> Look at his face 
> https://commons.wikimedia.org/wiki/File:Arnnon_Geshuri_-_January_2016_by_Myleen_Hollero.jpg
> 
> Il 08/01/2016 17:43, Kevin Gorman ha scritto:
>> I'm going to publicly second (or third, or fifth,) the idea that given
>> Arnnon's role in an incident involving illegal anti-poaching agreements he
>> should either be removed from the board with haste, or the board should
>> publish an incredibly good reason as to why he should remain on it.  Keep
>> in mind that Arnnon wasn't a bystander to this scandal, he actively fired a
>> recruiter who failed to follow the terms of an illegal anti-poaching
>> agreement in less than one hour of being informed about it in the first
>> place.  I like to think of Wikimedia as a relatively humane movement, and
>> there are very few situations where I'm comfortable with someone who is
>> that comfortable with the idea of firing an employee (who had presumably
>> been there for some time) within sixty minutes of learning the employee
>> didn't follow an illegal agreement having the degree of influence over the
>> movement that members of the Board of Trustees have.
>> 
>> The Wikimedia movement is not a movement whose direction should be set by
>> someone with that degree of callousness - and the fact that he happily
>> participated in the sort of anti-competitive agreement he did, which he
>> must have known was illegal and which exposed his former employers to not
>> insignificant liability, brings forth significant doubt as to whether or
>> not he can reasonably be trusted to carry out his fiduciary duties as a
>> trustee of the Wikimedia Foundation.
>> 
>> 
>> Kevin Gorman
>> 
>>> On Fri, Jan 8, 2016 at 5:27 AM, Andreas Kolbe  wrote:
>>> 
>>> My apologies. I just noticed the resolutions were in fact added on January
>>> 6, 2016.[1]
>>> 
>>> They are dated December 9, 2015. Both appointments were unanimous.
>>> 
>>> [1]
>>> 
>>> https://wikimediafoundation.org/w/index.php?title=Resolutions&diff=104423&oldid=104354
>>> 
 On Fri, Jan 8, 2016 at 1:22 PM, Andreas Kolbe  wrote:
 
 The resolutions and voting records for these recent appointments have not
 yet been posted tohttps://wikimediafoundation.org/wiki/Resolutions
 
 Could the page please be brought up to date?
>>> ___
>>> 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: [Wikimedia-l] WMF trustee Arnnon Geshuri and part in anticompetitive agreements in Google

[Pete Forsyth]

Ricordisamoa, I don't believe anybody has said he was convicted of a felony
(though there was, briefly, a related inaccuracy on the Meta page). The
details are explored pretty well here:
https://en.wikipedia.org/wiki/User:Cullen328/Arnnon_Geshuri#Geshuri.27s_personal_role

-Pete
[[User:Peteforsyth]]

On Wed, Jan 20, 2016 at 6:12 PM, Ricordisamoa 
wrote:

> Has Arnnon been actually convicted of a felony? Where is presumption of
> innocence?
> The firing was part of a larger system he seems unlikely to have set up on
> his own volition.
> Look at his face
> https://commons.wikimedia.org/wiki/File:Arnnon_Geshuri_-_January_2016_by_Myleen_Hollero.jpg
>
>
> Il 08/01/2016 17:43, Kevin Gorman ha scritto:
>
>> I'm going to publicly second (or third, or fifth,) the idea that given
>> Arnnon's role in an incident involving illegal anti-poaching agreements he
>> should either be removed from the board with haste, or the board should
>> publish an incredibly good reason as to why he should remain on it.  Keep
>> in mind that Arnnon wasn't a bystander to this scandal, he actively fired
>> a
>> recruiter who failed to follow the terms of an illegal anti-poaching
>> agreement in less than one hour of being informed about it in the first
>> place.  I like to think of Wikimedia as a relatively humane movement, and
>> there are very few situations where I'm comfortable with someone who is
>> that comfortable with the idea of firing an employee (who had presumably
>> been there for some time) within sixty minutes of learning the employee
>> didn't follow an illegal agreement having the degree of influence over the
>> movement that members of the Board of Trustees have.
>>
>> The Wikimedia movement is not a movement whose direction should be set by
>> someone with that degree of callousness - and the fact that he happily
>> participated in the sort of anti-competitive agreement he did, which he
>> must have known was illegal and which exposed his former employers to not
>> insignificant liability, brings forth significant doubt as to whether or
>> not he can reasonably be trusted to carry out his fiduciary duties as a
>> trustee of the Wikimedia Foundation.
>>
>> 
>> Kevin Gorman
>>
>> On Fri, Jan 8, 2016 at 5:27 AM, Andreas Kolbe  wrote:
>>
>> My apologies. I just noticed the resolutions were in fact added on January
>>> 6, 2016.[1]
>>>
>>> They are dated December 9, 2015. Both appointments were unanimous.
>>>
>>> [1]
>>>
>>>
>>> https://wikimediafoundation.org/w/index.php?title=Resolutions&diff=104423&oldid=104354
>>>
>>> On Fri, Jan 8, 2016 at 1:22 PM, Andreas Kolbe
>>> wrote:
>>>
>>> The resolutions and voting records for these recent appointments have not
 yet been posted tohttps://wikimediafoundation.org/wiki/Resolutions

 Could the page please be brought up to date?


 ___
>>> 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: [Wikimedia-l] Profile of Magnus Manske

[Marc A. Pelletier]

On 2016-01-19 12:53 PM, Pine W wrote:

The constitutional crisis that WMF created by using Superprotect to force
Image VIewer on the communities [...]


... except that this is not what happened.  While that narrative might 
be satisfying for someone who looks for a sense of being the stalwart 
defender of an oppressed community, the reality is that superprotect was 
created to block the deployment of a technically inapt and entirely 
broken "fix" that was - itself - a kneejerk reaction.


Which is not to say that its creation or use was wise in any way - it 
wasn't.  But trying to reframe things in "oh, evil WMF did all wrong 
against the poor, innocent community" terms serves no purpose other than 
create a windmill to tilt at.


-- Marc


___
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] WMF trustee Arnnon Geshuri and part in anticompetitive agreements in Google

[Ricordisamoa]

Has Arnnon been actually convicted of a felony? Where is presumption of 
innocence?
The firing was part of a larger system he seems unlikely to have set up 
on his own volition.
Look at his face 
https://commons.wikimedia.org/wiki/File:Arnnon_Geshuri_-_January_2016_by_Myleen_Hollero.jpg


Il 08/01/2016 17:43, Kevin Gorman ha scritto:

I'm going to publicly second (or third, or fifth,) the idea that given
Arnnon's role in an incident involving illegal anti-poaching agreements he
should either be removed from the board with haste, or the board should
publish an incredibly good reason as to why he should remain on it.  Keep
in mind that Arnnon wasn't a bystander to this scandal, he actively fired a
recruiter who failed to follow the terms of an illegal anti-poaching
agreement in less than one hour of being informed about it in the first
place.  I like to think of Wikimedia as a relatively humane movement, and
there are very few situations where I'm comfortable with someone who is
that comfortable with the idea of firing an employee (who had presumably
been there for some time) within sixty minutes of learning the employee
didn't follow an illegal agreement having the degree of influence over the
movement that members of the Board of Trustees have.

The Wikimedia movement is not a movement whose direction should be set by
someone with that degree of callousness - and the fact that he happily
participated in the sort of anti-competitive agreement he did, which he
must have known was illegal and which exposed his former employers to not
insignificant liability, brings forth significant doubt as to whether or
not he can reasonably be trusted to carry out his fiduciary duties as a
trustee of the Wikimedia Foundation.


Kevin Gorman

On Fri, Jan 8, 2016 at 5:27 AM, Andreas Kolbe  wrote:


My apologies. I just noticed the resolutions were in fact added on January
6, 2016.[1]

They are dated December 9, 2015. Both appointments were unanimous.

[1]

https://wikimediafoundation.org/w/index.php?title=Resolutions&diff=104423&oldid=104354

On Fri, Jan 8, 2016 at 1:22 PM, Andreas Kolbe  wrote:


The resolutions and voting records for these recent appointments have not
yet been posted tohttps://wikimediafoundation.org/wiki/Resolutions

Could the page please be brought up to date?



___
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: [Wikimedia-l] The documentary film of Wikimedia Argentina now available. Happy birthday Wikipedia!

[Ricordisamoa]

I see a bunch of "ATTRIBUTION-NONCOMMERCIAL 3.0 INTERNATIONAL LICENSE" 
at the end :-(


Il 15/01/2016 23:50, Anna Torres ha scritto:

Dear all,

Wikimedia Argentina has been working the last 6 months on a documentary
film based on the community, the editors and their work.

Some weeks ago I sent you the trailer and now, after the party for the 15th
anniversary has passed and the film has already been launched in Argentina,
we are pleased to be sharing with you the result.

Please, find it on the following links (all with subtitles in english)

Wikimedia Commons->
In spanish:  here

In english -> here


Youtube->here 

Vimeo:here 

Hope you like it




___
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] Community Wishlist Survey: Status report #1

[Danny Horn]

Hi everyone,

We've posted the Community Tech team's first status report on our progress
with the Community Wishlist Survey, and you're invited to come and check it
out:

https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Status_report_1

In November and December, we invited active contributors to Wikimedia
projects to propose, discuss and vote on the features and fixes that they
most want to see. 634 people participated in the survey, voting on 107
proposals.

Our team has committed to investigating and responding to the top 10
wishes. In many cases, our team will be designing and building tools
ourselves, or collaborating with other teams and volunteers who are working
in that area. For the wishes that we can't build this year -- because it's
too big for our team, or there's a problem that we can't solve -- then we
can at least offer open discussion on the problem, and detailed
documentation explaining what we've learned, so the information can be used
by other developers in the future.

We've done a preliminary assessment of the top 10, which is described in
the status report. As of right now (mid-January), the two items that we're
actively working on  are #1) Migrate dead links to the Wayback Machine, and
#7) Pageview Stats tool. Why are we working on those two and not the
others? Check out the status report for all the answers.

I'm going to post the quick overview of the top 10 wishes here. Each of
these wishes is discussed in detail on the status report page.

1. Migrate dead links to the Wayback Machine: Currently in progress,
working with a community developer and the Internet Archive. This is one of
the two projects we're actively working on now (mid-January).

2. Improved diff compare screen: Needs investigation and community
discussion to define the problems that we want to solve.

3. Central repository for templates, gadgets and Lua modules: Needs
underlying technical work that's currently under discussion by another team.

4. Cross-wiki watchlist: Needs technical investigation on the existing
Crosswatch tool, and the Collaboration team's cross-wiki notifications.

5. Numerical sorting in categories: Investigation is underway. There are a
couple potential solutions that we need to figure out.

6. Allow categories in Commons in all languages: Currently talking with
Wikidata about using structured metadata to solve the underlying problem.

7. Pageview Stats tool: Currently talking with the Analytics team about
their new pageview API. Needs some community discussion to define the
front-end spec. This is one of the two projects we're actively working on
now (mid-January), because the Analytics team is eager to use the new API
that they've developed.

8. Global cross-wiki talk page: Needs community discussion to define the
product.

9. Improve copy and paste detection bot: Need to work with volunteer
developers to define scope on improving the existing Plagiabot.

10. Add a user watchlist: We've heard significant pushback about the
vandal-fighting use case, because of the risk of enabling harassment.
Currently investigating an opt-in version that would be useful for mentors,
classes, editathons and WikiProjects.

Here's the status report link again, for lots more information:

https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Status_report_1

Our team is really excited about the work that we'll get to do this year,
and we're looking forward to talking and working with you as we go along.

Thanks,

Danny Horn
Product Manager
WMF - Community Tech
User:DannyH (WMF)
___
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] WMF trustee Arnnon Geshuri and part in anticompetitive agreements in Google

[Fæ]

We are now approaching 2 weeks since the open letter to the Chairman
of the WMF board. There has been no formal response, nor any
commitment to take action. Consequently a simple open and public vote
of confidence for Geshuri's appointment has been created.

Link:
https://meta.wikimedia.org/wiki/Vote_of_confidence:Arnnon_Geshuri

Please vote or add your comment there.

Thanks,
Fae

On 7 January 2016 at 10:38, Fæ  wrote:
> Dear Patricio Lorente,
>
> I request that the WMF board take immediate action to publish a
> comprehensive account of why you appointed Geshuri as a trustee,
> despite his direct involvement and being named as a defendant in the
> on-going scandal of anticompetitive agreements at Google, or that
> Geshuri chooses to step down from his new position of trust.
>
> This is being separated out as an open letter to the board in a new
> discussion thread, to avoid getting confused with other issues. In the
> light of recent challenges to the WMF with regard to a dramatic loss
> of confidence in their senior management and the politicking behind
> the loss of James Heilman as a trustee openly advocating for
> transparency to the actions of the WMF board, Geshuri's background
> with anticompetitive practices can only damage confidence in the WMF
> board with regard to their duty to hold WMF senior management to
> account and acting with the highest possible accountability and public
> transparency.
>
> Links showing Geshuri's public footprint on this issue:
> 1. 
> http://www.theverge.com/2012/1/27/2753701/no-poach-scandal-unredacted-steve-jobs-eric-schmidt-paul-otellini
> 2. 
> http://www.lieffcabraser.com/Antitrust/Apple-Google-Silicon-Valley-No-Cold-Calling.shtml
> 3. 
> http://www.courthousenews.com/2015/03/23/google-shareholders-miffed-over-wage-fight.htm
> 4. 
> https://www.quora.com/How-is-Arnnon-Geshuri-current-VP-HR-at-Tesla-and-former-chief-architect-of-staffing-at-Google-good-at-what-he-does
>
> Yours sincerely,
> Fae
>
> -- Forwarded message --
> From: Andrew Green 
> Date: 7 January 2016 at 08:58
> Subject: Re: [Wikimedia-l] Announcing new Wikimedia Foundation Trustees
> To: Wikimedia Mailing List 
>
>
> Interesting to note Arnnon's role in the Silicon Valley anti-poaching
> affair: 
> http://www.theverge.com/2012/1/27/2753701/no-poach-scandal-unredacted-steve-jobs-eric-schmidt-paul-otellini
>
> - Andrew
> --
> fae...@gmail.com https://commons.wikimedia.org/wiki/User:Fae



-- 
fae...@gmail.com https://commons.wikimedia.org/wiki/User:Fae
Personal and confidential, please do not circulate or re-quote.

___
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] A page about new editors in different projects

[Risker]

On 20 January 2016 at 17:51, Andy Mabbett  wrote:

> On 20 January 2016 at 20:56, Asaf Bartov  wrote:
>
> > It is an excellent and popular way to *celebrate* (not just describe)
> > good-faith new contributors.  The way it works is a couple of volunteers
> > who run the page look for a relatively new contributor who seems to have
> > successfully integrated on-wiki, and has made more than a handful of good
> > contributions, and they approach the new contributor with a request for
> an
> > interview and a description of this page.
>
> Sounds great. If en.WP do this as part of The Signpost, it would have
> a high level of reach, immediately. Same with Wikidata's weekly
> update.
>
>

Heh. I think back to when I first started editing.  I would have been
completely freaked out at that level of "notice" and would never have
edited again.

Risker/Anne
___
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] [Wmfall] Posting of 2015-16 Risks Document

[Asaf Bartov]

direct link here:
https://wikimediafoundation.org/wiki/2015-2016_Annual_Plan#Wikimedia_Foundation_Risks

   A.

On Wed, Jan 20, 2016 at 1:30 PM, Amy Vossbrinck 
wrote:

> Hello All:
>
> Thanks to an alert Community Member, it has come to our attention that due
> to an oversight, the 2015-16 Risks Document was not posted with the 2015-16
> Annual Plan.  We apologize for that.
>
> Traditionally the Risks Document has been a part of the Annual Plan,
> either included in the text of the plan or in the appendix.  The decision
> was made last year to create the Risks Document separately and it was
> inadvertently not posted when the 2015-16 Annual Plan, Budget and FAQ were
> posted.
>
> The document was completed in July 2015; therefore the language may not
> reflect any recent developments.
>
> You will find the 2015-16 Risks Document posted here as part of the Annual
> Plan:
>
> 2015-16 Annual Plan and Risk Document
> 
>
> Thank you,
>
> Amy
>
> --
> *Amy Vossbrinck*
> *Executive Assistant to the*
> *Chief Financial Officer and to *
> *the Vice President of Human Resources​*
> *Wikimedia Foundation*
> *149 New Montgomery Street*
> *San Francisco, CA 94105*
> *415.839.6885  ext 6628 <415.839.6885%20%C2%A0ext%206628>*
> *avossbri...@wikimedia.org *
>
>
> ___
> Wmfall mailing list
> wmf...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wmfall
>
>


-- 
Asaf Bartov
Wikimedia Foundation 

Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us make it a reality!
https://donate.wikimedia.org
___
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] A page about new editors in different projects

[Andy Mabbett]

On 20 January 2016 at 20:56, Asaf Bartov  wrote:

> It is an excellent and popular way to *celebrate* (not just describe)
> good-faith new contributors.  The way it works is a couple of volunteers
> who run the page look for a relatively new contributor who seems to have
> successfully integrated on-wiki, and has made more than a handful of good
> contributions, and they approach the new contributor with a request for an
> interview and a description of this page.

Sounds great. If en.WP do this as part of The Signpost, it would have
a high level of reach, immediately. Same with Wikidata's weekly
update.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

___
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] Posting of 2015-16 Risks Document

[Amy Vossbrinck]

Hello All:

Thanks to an alert Community Member, it has come to our attention that due
to an oversight, the 2015-16 Risks Document was not posted with the 2015-16
Annual Plan.  We apologize for that.

Traditionally the Risks Document has been a part of the Annual Plan, either
included in the text of the plan or in the appendix.  The decision was made
last year to create the Risks Document separately and it was inadvertently
not posted when the 2015-16 Annual Plan, Budget and FAQ were posted.

The document was completed in July 2015; therefore the language may not
reflect any recent developments.

You will find the 2015-16 Risks Document posted here as part of the Annual
Plan:

2015-16 Annual Plan and Risk Document


Thank you,

Amy

-- 
*Amy Vossbrinck*
*Executive Assistant to the*
*Chief Financial Officer and to *
*the Vice President of Human Resources​*
*Wikimedia Foundation*
*149 New Montgomery Street*
*San Francisco, CA 94105*
*415.839.6885  ext 6628*
*avossbri...@wikimedia.org *
___
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] A page about new editors in different projects

[Asaf Bartov]

It is indeed one of my favorite community ideas on the Hebrew Wikipedia.
Some of you have heard me pitch it at conferences.  Let me add a couple of
notes:

It is an excellent and popular way to *celebrate* (not just describe)
good-faith new contributors.  The way it works is a couple of volunteers
who run the page look for a relatively new contributor who seems to have
successfully integrated on-wiki, and has made more than a handful of good
contributions, and they approach the new contributor with a request for an
interview and a description of this page.  Those new contributors who are
interested are interviewed and featured on the page.

A fun additional feature of the page, is that alongside the one or two
featured new contributors, there is a sidebar where some *veteran*
contributor offers an appreciation of some other contributor.  This page
updates only once a month, and it's great to have these occasional
reminders of appreciation among the old-timers too.

Cheers,

A.

On Wed, Jan 20, 2016 at 6:29 AM, Szymon Grabarczuk  wrote:

> Thanks Amir, this is inspiring :) by this, I mean, there's no such page in
> Polish projects.
>
> As of enwiki, and in general, first of all, an interview sounds much better
> to me than 'fill a template and become a part of this depersonalised crowd
> below'. Second, traffic must be taken into account. I hope it's obvious a
> page doesn't fulfil its function should isn't highly linked or read with a
> permanent high frequency. Therefore, designing a page isn't such an issue
> as much as providing traffic and good UX.
>
> On 20 January 2016 at 09:00, Pine W  wrote:
>
> > The Teahouse on English Wikipedia has a guest profile page (
> > https://en.wikipedia.org/wiki/Wikipedia:Teahouse/Guests), although it's
> > low
> > traffic  I
> like
> > the idea of a higher profile way to welcome newcomers to the community.
> > Perhaps newcomers could be interviewed periodically in the Signpost.
> >
> > Pine
> >
> > On Tue, Jan 19, 2016 at 7:30 AM, Amir E. Aharoni <
> > amir.ahar...@mail.huji.ac.il> wrote:
> >
> > > Hi,
> > >
> > > In the Hebrew Wikipedia there's a page [1] that highlights editors who
> > > recently became active - shows a short interview with them and welcomes
> > > them to the community in a nice way.
> > >
> > > It's not so much a help and a support page like English Wikipedia, but
> > more
> > > like a newsletter or a blog that describes newcomers, in a form of an
> > > regularly updating wiki page.
> > >
> > > Is there anything like that in other projects and languages? (Not
> > > necessarily Wikipedia, of course.)
> > >
> > > Thanks!
> > >
> > > [1] https://he.wikipedia.org/wiki/WP:BIK
> > >
> > > --
> > > Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
> > > http://aharoni.wordpress.com
> > > ‪“We're living in pieces,
> > > I want to live in peace.” – T. Moore‬
> > > ___
> > > 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,
> > 
> >
>
>
>
> --
> *Szymon Grabarczuk*
>
> Free Knowledge Advocacy Group EU
> Head of Research & Development Group, Wikimedia Polska
> pl.wikimedia.org/wiki/User:Tar_Lócesilion
> 
> 
> ___
> 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,
> 
>



-- 
Asaf Bartov
Wikimedia Foundation 

Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us make it a reality!
https://donate.wikimedia.org
___
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] Launch of Community Consultation on strategic approaches

[Luis Villa]

On Tue, Jan 19, 2016 at 11:43 PM, Pine W  wrote:

> Thanks Luis. I am trying to wrap my mind around the strategy process and
> how it interfaces with the many moving pieces in the Wikimedia universe.
>

As are we all. I know we've talked about putting some of the timeline
pieces together in a FAQ, but honestly not sure if that has happened yet.


> A comment that I've heard from staff is that strategies and priorities seem
> to shift frequently. This results in confusion and lack of clarity. Once
> there is a coherent strategy that emerges from this process, will it remain
> set for the next 12-24 months? (Even 12 months seems rather short. Perhaps
> we could be looking at longer-term horizons and higher aspirations, with
> clearly defined intermediate SMART goals.)
>

I've had those concerns myself :) There's a real tension between being
nimble and reactive (which we need to be) and having ability to do
longer-term planning. We've been talking about this as an 18-24 month
strategy; but inevitably that will be different for different parts of the
org - some parts of product may find it outdated almost as soon as we
publish it (based on the earliest experiments they run as a result of it),
while some parts of the community strategy could conceivably last 3-4 years
(given the inevitably longer time scales for social/cultural work).

Sorry that's not more firm/specific, but inevitably some flexibility is
required here.

Luis



> Thanks,
> Pine
>
> On Tue, Jan 19, 2016 at 4:56 PM, Luis Villa  wrote:
>
> > On Mon, Jan 18, 2016 at 6:23 PM, Pine W  wrote:
> >
> > > 2. You wrote, "This is a major step to help us prioritize the work of
> the
> > > Foundation beginning in July 2016 and running for the next 12 to 24
> > months
> > > thereafter into a strategic plan." It seems that there will be some
> > overlap
> > > in the development of the 2016-2017 Annual Plan, and that the
> completion
> > > of
> > > the strategic plan process will come too late to significantly
> influence
> > > the AP until after the AP is already being executed. Can you share with
> > us
> > > which principles are being used to guide the development of the
> 2016-2017
> > > Annual Plan which this document [1] is scheduled to be published for
> > > community review on March 31, 2016?
> > >
> >
> > We mentioned this briefly in the FAQ
> > ,
> > but let me elaborate here:
> >
> > "We also need to finalize the Foundation’s strategy quickly, so that we
> can
> > meet our 2016 Annual Plan deadlines and align our team and department
> > strategies with the overall strategy."
> >
> >
> > In other words, we really are waiting on the results of the public
> > discussion before making our biggest annual plan choices. :) This is part
> > of why the process is somewhat rushed; if we planned to use *other*
> > principles,
> > we could have had a multi-month process, but we really do want to use the
> > outcome of this process to help guide the annual plan, so we do have to
> > make it a bit tighter than we might otherwise have liked.
> >
> > We're splitting things up into "core" and "strategic" to help make this
> > process fit together better: that will allow us to do initial planning on
> > issues we expect will not be affected by strategy (e.g., "keep servers
> on")
> > while waiting for the outcome of the public discussion.
> >
> > (For those who are curious for more details, I also addressed this
> somewhat
> > in my metrics meeting talk
> > 
> > last week, and the question
> > 
> at
> > the end of it.)
> >
> > Hope that helps answer that question-
> > Luis
> >
> > --
> > Luis Villa
> > Sr. Director of Community Engagement
> > Wikimedia Foundation
> > *Working towards a world in which every single human being can freely
> share
> > in the sum of all knowledge.*
> > ___
> > 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,
> 
>



-- 
Luis Villa
Sr. Director of Community Engagement
Wikimedia Foundation
*Working towards a world in which every single human being can freely share
in the sum of all knowledge.*
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wi

[Wikimedia-l] Call for reliable sources for biographical data

[Marco Fossati]

Hi everyone,

The StrepHit IEG project [1] is currently in the phase of curating a 
list of reliable sources containing biographical data.

The mix'n'match tool [2] already maintains a list.

Can anyone involved in GLAM projects please suggest any more reliable 
sources?

Thanks for getting in touch with me!
Cheers,

Marco

[1] 
https://meta.wikimedia.org/wiki/Grants:IEG/StrepHit:_Wikidata_Statements_Validation_via_References

[2] https://tools.wmflabs.org/mix-n-match/

___
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] A page about new editors in different projects

[Szymon Grabarczuk]

Thanks Amir, this is inspiring :) by this, I mean, there's no such page in
Polish projects.

As of enwiki, and in general, first of all, an interview sounds much better
to me than 'fill a template and become a part of this depersonalised crowd
below'. Second, traffic must be taken into account. I hope it's obvious a
page doesn't fulfil its function should isn't highly linked or read with a
permanent high frequency. Therefore, designing a page isn't such an issue
as much as providing traffic and good UX.

On 20 January 2016 at 09:00, Pine W  wrote:

> The Teahouse on English Wikipedia has a guest profile page (
> https://en.wikipedia.org/wiki/Wikipedia:Teahouse/Guests), although it's
> low
> traffic  I like
> the idea of a higher profile way to welcome newcomers to the community.
> Perhaps newcomers could be interviewed periodically in the Signpost.
>
> Pine
>
> On Tue, Jan 19, 2016 at 7:30 AM, Amir E. Aharoni <
> amir.ahar...@mail.huji.ac.il> wrote:
>
> > Hi,
> >
> > In the Hebrew Wikipedia there's a page [1] that highlights editors who
> > recently became active - shows a short interview with them and welcomes
> > them to the community in a nice way.
> >
> > It's not so much a help and a support page like English Wikipedia, but
> more
> > like a newsletter or a blog that describes newcomers, in a form of an
> > regularly updating wiki page.
> >
> > Is there anything like that in other projects and languages? (Not
> > necessarily Wikipedia, of course.)
> >
> > Thanks!
> >
> > [1] https://he.wikipedia.org/wiki/WP:BIK
> >
> > --
> > Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
> > http://aharoni.wordpress.com
> > ‪“We're living in pieces,
> > I want to live in peace.” – T. Moore‬
> > ___
> > 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,
> 
>



-- 
*Szymon Grabarczuk*

Free Knowledge Advocacy Group EU
Head of Research & Development Group, Wikimedia Polska
pl.wikimedia.org/wiki/User:Tar_Lócesilion

___
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] Profile of Magnus Manske

[Magnus Manske]

On Wed, Jan 20, 2016 at 12:58 AM Todd Allen  wrote:

> Once the VisualEditor was fit for purpose and a good deployment strategy
> had been developed, the English Wikipedia community overwhelmingly
> supported rolling it out. (
>
> https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)/Archive_125#Gradually_enabling_VisualEditor_for_new_accounts
> )
>
That is for new accounts only. Without an account, still no VE for you,
even if you are probably the one needing it most.

>
> It's not Luddism, it's not "resistance to change", it's not "power users"
> grumpy about newbies having an easier time, it's not anything like that.
> It's that in the state it was initially released in, the thing did not
> work.
>

No one said "Luddism", except to defend against its use. Odd.


> So yes, by all means, let's try new things. But try:
>
> 1: Asking us what we actually want, before coding something up and feeling
> obligated to push it out. People are a lot more receptive to something they
> asked for than something being forced upon them. That's been an issue with
> Flow. It's not that it doesn't work well (though it doesn't), it's that it
> wasn't wanted to start with. So instead of "Here's the new discussion
> system", ask "What can we do to make our system of discussion better?"
>

Listening to what editors want is important. ONLY listening to wad editors
want is bad. People often don't know what they want or need, until they see
it. Compare the famous (possibly misattributed) Henry Ford quote:
“If I had asked people what they wanted, they would have said faster
horses.”

Also, veteran editors do not represent the readers or casual/newbie
editors; their needs are often quite different.


>
> 2: Make sure it works. Have an opt-in beta phase. Doesn't have to be
> perfect, but certainly make sure it's not breaking page formatting all over
> the place. You'll notice, for example, that there wasn't really any
> resistance to HHVM. It worked well, it was desirable, it was clearly fit
> for purpose. So no, there isn't just a reflexive change aversion. Though
> the previous missteps and hamfisted followups have, rather ironically,
> created a lot of the reflexive change aversion that people said was there.
>

Wrong example. The HHMV switch was a back-end change that should have had
no visible effect. As long as the servers are fast, people don't really
care what's going on there. Did e.g. English Wikipedia actually vote on
HHMV?

>
> 3: Be nice (but NOT condescending or patronizing) if an issue comes up.
> "Superprotect" alienated people right quickly, and turned what could have
> been a productive (if tense) conversation into a war. Same with refusal to
> budge on VE and the arrogant tone several people took. Yes, some people
> might be rude about objecting to the change. Don't sink to their level. If
> they call the new software a steaming pile, ask "Could you offer more
> concrete feedback?"
>

Superprotect was used to revert an admin action on de.wikipedia, an action
that might actually fall under U.S. or German computer sabotage laws. This
was hailed as some heroic action by that vocal group I keep mentioning,
when it can easily be seen as someone abusing the privileges given by the
Foundation (as owners of the servers) to deactivate functionality put in
place by the Foundation.
The creation and subsequent use of superprotect was not exactly the most
wise decision ever undertaken, but neither was the original sabotage
(literally so; using access to a machine to stop it from working, just not
using a wooden shoe).
And while it is always good to ask for more concrete feedback, it is even
better to offer it to begin with.


>
> 4: Don't surprise people. Not everyone follows the Village Pumps or what
> have you. If a major new feature is set to roll out, do banners, do
> watchlist notices, do whatever it takes, but make sure people know. When
> Mediaviewer was rolled out, all of a sudden, I was just having images act
> completely different. I had no idea what was going on. People are more
> amenable to change if you brace them for it. Even better, do that to
> develop a rollout strategy in advance with the community. (You already know
> they want it; they asked for it. Right?)
>

The Foundation appears to be doing this already. I even saw a mail about it
today.


>
> 5: If at all feasible, offer an easy opt-out. People are actually more
> likely to give something a decent try if they know they can switch back if
> they don't like it.
>

IIRC, both VE and MediaViewer offered opt-out from the beginning; the MV
opt-out just was "below the fold" or something.


>
> 6: Show willingness to budge. "No, we won't do ACTRIAL, period." "You get
> VE, like it or not." "You're getting Mediaviewer even if we have to develop
> a new protection level to cram it down your throats!" That type of
> hamfisted, I'm-right-you're-wrong approach will gear people right up for a
> fight. Fights are bad. Discussions are good. But people don'

Re: [Wikimedia-l] A common product development process (was Re: Profile of Magnus Manske)

[Jane Darnell]

+1
I also like this tone and agree both with everything Magnus has claimed and
with Quim's ideas of opening specific Phabricator tasks to move forward. I
think a big problem is how to inform people during product launch. I think
the media viewer would have been launched more smoothly if the viewer had
the "turn this new feature off" button placed more prominently in the first
few weeks of introduction, for logged in users of all kinds, both readers
as well as editors. The main problem there was that the media viewer had a
negative impact on the workflow for many Wiki(p/m)edians, and because there
was no formal study of editor workflows beforehand, this was entirely
overlooked. Readers of maps and other files that use the annotator were
also locked out from that content for a fairly long period of time.

Moving forward, more attention must be paid to documenting existing reader
and editor workflows, gnarly as this may sound to achieve. Once done
however, optimization of such workflows should be much, much easier. After
viewing that video from Mexico Wikimania of a mobile-user's editing
workflow with the Visual Editor I was shocked to think that there are
people out there trying so hard and moving so slowly to achieve their wiki
goals. We really need to spend time on this, because mobile will only
become more and more important. I for one don't see myself making the
switch to Visual Editor any time soon, though I do use several other
websites regularly on mobile.

As far as asking the WMF only to "build what the community wants", I
strongly disagree. I have become a regular user of Facebook to augment my
onwiki work, and a few years ago if you had asked me whether I would find
Wiki(p/m)edians on Facebook I would have said "No Way!"

On Wed, Jan 20, 2016 at 10:36 AM, Pine W  wrote:

> Quim,
>
> I like the tone of these proposals.
>
> I particularly like the concepts (some of which you mentioned) of:
>
> * Limited-scale A/B tests in the wild prior to 100% deployments
>
> * Community involvement in the  ideation and early product design phases
>
> * Well-designed, short surveys with appropriate sampling (with a nod to
> Edward'a possible role here) at various points in product development
>
> * The development and use of SMART goals throughout the product design
> process
>
> * "Design thinking" about contributor workflows
>
> Pine
> On Jan 20, 2016 1:17 AM, "Quim Gil"  wrote:
>
> > Thank you for this interesting thread (and thank you for the interesting
> > blog post in the first place). I'll pick a quote and I will try to
> propose
> > ways forward about other comments made.
> >
> > On Mon, Jan 18, 2016 at 11:35 PM, Magnus Manske <
> > magnusman...@googlemail.com
> > > wrote:
> >
> > > I would hope the Foundation by now understands better how to handle new
> > > software releases.
> >
> >
> > I think so, although I'm sure the Foundation still needs to understand
> > better how to handle new software releases -- and the communities too.
> >
> > https://www.mediawiki.org/wiki/WMF_product_development_process is the
> > common protocol where we want to apply all the learning. Clarifying
> > how community engagement works in this WMF product development process
> is a
> > main priority for us during this quarter (
> > https://phabricator.wikimedia.org/T124022
> > ), and everybody is invited to join.
> >
> > I do think that we have many problems as software partners, the first
> > problem being that we all got used to this situation of
> > confrontation-by-default as something natural, they way it is. We are
> > software partners, we really are, and in order to make this partnership
> > productive we need to be in a mood of collaboration-by-default.
> >
> > We need a climate where new ideas are welcomed and encouraged. Today
> > someone comes with a new idea and the chances are that the first replies
> > setting the tone will be more discouraging than encouraging. We need a
> safe
> > and exciting place where everybody can share new concepts, collaborate on
> > them, learn from each other.
> >
> > We need a prioritization process where great concepts receive initial
> > support for planning and prototyping, and where good plans and prototypes
> > receive support to start their way toward production. The WMF needs to
> open
> > that process to the participation of our communities, and our communities
> > need to understand that this is the best point of time to discuss new
> > plans.
> >
> > We need design and build processes that volunteers find easy to follow
> and
> > participate in. There are many and very diverse groups of people (at
> > Wikimedia and beyond)  that would give their feedback about design
> concepts
> > or alpha releases if they would only know about them.
> >
> > We need to make our deployment process more flexible and predictable,
> > allowing development teams and communities to agree on beta releases, A/B
> > tests, opt-in/opt-out approaches, first/last waves... Some ideas:
> >
> > * In order

Re: [Wikimedia-l] A common product development process (was Re: Profile of Magnus Manske)

[Pine W]

Quim,

I like the tone of these proposals.

I particularly like the concepts (some of which you mentioned) of:

* Limited-scale A/B tests in the wild prior to 100% deployments

* Community involvement in the  ideation and early product design phases

* Well-designed, short surveys with appropriate sampling (with a nod to
Edward'a possible role here) at various points in product development

* The development and use of SMART goals throughout the product design
process

* "Design thinking" about contributor workflows

Pine
On Jan 20, 2016 1:17 AM, "Quim Gil"  wrote:

> Thank you for this interesting thread (and thank you for the interesting
> blog post in the first place). I'll pick a quote and I will try to propose
> ways forward about other comments made.
>
> On Mon, Jan 18, 2016 at 11:35 PM, Magnus Manske <
> magnusman...@googlemail.com
> > wrote:
>
> > I would hope the Foundation by now understands better how to handle new
> > software releases.
>
>
> I think so, although I'm sure the Foundation still needs to understand
> better how to handle new software releases -- and the communities too.
>
> https://www.mediawiki.org/wiki/WMF_product_development_process is the
> common protocol where we want to apply all the learning. Clarifying
> how community engagement works in this WMF product development process is a
> main priority for us during this quarter (
> https://phabricator.wikimedia.org/T124022
> ), and everybody is invited to join.
>
> I do think that we have many problems as software partners, the first
> problem being that we all got used to this situation of
> confrontation-by-default as something natural, they way it is. We are
> software partners, we really are, and in order to make this partnership
> productive we need to be in a mood of collaboration-by-default.
>
> We need a climate where new ideas are welcomed and encouraged. Today
> someone comes with a new idea and the chances are that the first replies
> setting the tone will be more discouraging than encouraging. We need a safe
> and exciting place where everybody can share new concepts, collaborate on
> them, learn from each other.
>
> We need a prioritization process where great concepts receive initial
> support for planning and prototyping, and where good plans and prototypes
> receive support to start their way toward production. The WMF needs to open
> that process to the participation of our communities, and our communities
> need to understand that this is the best point of time to discuss new
> plans.
>
> We need design and build processes that volunteers find easy to follow and
> participate in. There are many and very diverse groups of people (at
> Wikimedia and beyond)  that would give their feedback about design concepts
> or alpha releases if they would only know about them.
>
> We need to make our deployment process more flexible and predictable,
> allowing development teams and communities to agree on beta releases, A/B
> tests, opt-in/opt-out approaches, first/last waves... Some ideas:
>
> * In order to enter the deployment phase, a project would need to have a
> deployment plan proposed, agreed, and documented -- which can be adapted
> based on data and feedback gathered.
>
> * For every new product or significant feature, each community could have
> the chance to determine whether they want to be early adopters (first
> waves) or, on the contrary, be placed in the last waves, after seeing how
> the new software is being used by others and is being matured.
>
> * Communities would focus not so much on {{Support}} / {{Oppose}} decisions
> about the totality of a feature, but on the identification of specific
> blockers, allowing development teams to negotiate and change their plans
> under clearer terms.
>
> This common protocol should allow us to move away from the current
> situation where both communities and development teams fear that a single
> strike might disrupt their work overnight, without even seeing it coming.
>
> A more predictable path with specialized checkpoints should allow
> communities and development teams understanding better what is going on and
> when to talk about what. It should also help recruiting more and more
> diverse participants, who could contribute their time and skills in more
> daring and productive ways.
>
> What makes me optimistic about this common product development process is
> that we don't need to finalize all the pieces to make it work. As long as
> we agree that we are software partners and we agree that iterations are
> good, we can start agreeing on improvements and implement them one by one.
>
> Get involved, please. You can either join the more theoretical work about
> the overall process or you can pick a specific improvement and help pushing
> it forward in very practical terms. See you at
> https://www.mediawiki.org/wiki/Talk:WMF_product_development_process (where
> we have been a bit slow lately but not anymore now that is a top goal).
>
> --
> Quim Gil
> Engineerin

Re: [Wikimedia-l] A common product development process (was Re: Profile of Magnus Manske)

[Gerard Meijssen]

Hoi,
One issue is that with phabricator the discussion has been largely moved to
.. phabricator. That is normal however, following what happens there and
finding where a discussion should/could rage takes a substantial effort.

For me phabricator is a painful experience, it often does not work for me.
It is why I do not write about my red link/wiki link suggestion even though
I am certain it will improve quality.

So yes, we need to talk but the talk does not happen in one place. When you
insist on one place, the confrontation is already in place.
Thanks,
  GerardM

On 20 January 2016 at 10:17, Quim Gil  wrote:

> Thank you for this interesting thread (and thank you for the interesting
> blog post in the first place). I'll pick a quote and I will try to propose
> ways forward about other comments made.
>
> On Mon, Jan 18, 2016 at 11:35 PM, Magnus Manske <
> magnusman...@googlemail.com
> > wrote:
>
> > I would hope the Foundation by now understands better how to handle new
> > software releases.
>
>
> I think so, although I'm sure the Foundation still needs to understand
> better how to handle new software releases -- and the communities too.
>
> https://www.mediawiki.org/wiki/WMF_product_development_process is the
> common protocol where we want to apply all the learning. Clarifying
> how community engagement works in this WMF product development process is a
> main priority for us during this quarter (
> https://phabricator.wikimedia.org/T124022
> ), and everybody is invited to join.
>
> I do think that we have many problems as software partners, the first
> problem being that we all got used to this situation of
> confrontation-by-default as something natural, they way it is. We are
> software partners, we really are, and in order to make this partnership
> productive we need to be in a mood of collaboration-by-default.
>
> We need a climate where new ideas are welcomed and encouraged. Today
> someone comes with a new idea and the chances are that the first replies
> setting the tone will be more discouraging than encouraging. We need a safe
> and exciting place where everybody can share new concepts, collaborate on
> them, learn from each other.
>
> We need a prioritization process where great concepts receive initial
> support for planning and prototyping, and where good plans and prototypes
> receive support to start their way toward production. The WMF needs to open
> that process to the participation of our communities, and our communities
> need to understand that this is the best point of time to discuss new
> plans.
>
> We need design and build processes that volunteers find easy to follow and
> participate in. There are many and very diverse groups of people (at
> Wikimedia and beyond)  that would give their feedback about design concepts
> or alpha releases if they would only know about them.
>
> We need to make our deployment process more flexible and predictable,
> allowing development teams and communities to agree on beta releases, A/B
> tests, opt-in/opt-out approaches, first/last waves... Some ideas:
>
> * In order to enter the deployment phase, a project would need to have a
> deployment plan proposed, agreed, and documented -- which can be adapted
> based on data and feedback gathered.
>
> * For every new product or significant feature, each community could have
> the chance to determine whether they want to be early adopters (first
> waves) or, on the contrary, be placed in the last waves, after seeing how
> the new software is being used by others and is being matured.
>
> * Communities would focus not so much on {{Support}} / {{Oppose}} decisions
> about the totality of a feature, but on the identification of specific
> blockers, allowing development teams to negotiate and change their plans
> under clearer terms.
>
> This common protocol should allow us to move away from the current
> situation where both communities and development teams fear that a single
> strike might disrupt their work overnight, without even seeing it coming.
>
> A more predictable path with specialized checkpoints should allow
> communities and development teams understanding better what is going on and
> when to talk about what. It should also help recruiting more and more
> diverse participants, who could contribute their time and skills in more
> daring and productive ways.
>
> What makes me optimistic about this common product development process is
> that we don't need to finalize all the pieces to make it work. As long as
> we agree that we are software partners and we agree that iterations are
> good, we can start agreeing on improvements and implement them one by one.
>
> Get involved, please. You can either join the more theoretical work about
> the overall process or you can pick a specific improvement and help pushing
> it forward in very practical terms. See you at
> https://www.mediawiki.org/wiki/Talk:WMF_product_development_process (where
> we have been a bit slow lately but not anymore now 

[Wikimedia-l] A common product development process (was Re: Profile of Magnus Manske)

[Quim Gil]

Thank you for this interesting thread (and thank you for the interesting
blog post in the first place). I'll pick a quote and I will try to propose
ways forward about other comments made.

On Mon, Jan 18, 2016 at 11:35 PM, Magnus Manske  wrote:

> I would hope the Foundation by now understands better how to handle new
> software releases.


I think so, although I'm sure the Foundation still needs to understand
better how to handle new software releases -- and the communities too.

https://www.mediawiki.org/wiki/WMF_product_development_process is the
common protocol where we want to apply all the learning. Clarifying
how community engagement works in this WMF product development process is a
main priority for us during this quarter (
https://phabricator.wikimedia.org/T124022
), and everybody is invited to join.

I do think that we have many problems as software partners, the first
problem being that we all got used to this situation of
confrontation-by-default as something natural, they way it is. We are
software partners, we really are, and in order to make this partnership
productive we need to be in a mood of collaboration-by-default.

We need a climate where new ideas are welcomed and encouraged. Today
someone comes with a new idea and the chances are that the first replies
setting the tone will be more discouraging than encouraging. We need a safe
and exciting place where everybody can share new concepts, collaborate on
them, learn from each other.

We need a prioritization process where great concepts receive initial
support for planning and prototyping, and where good plans and prototypes
receive support to start their way toward production. The WMF needs to open
that process to the participation of our communities, and our communities
need to understand that this is the best point of time to discuss new plans.

We need design and build processes that volunteers find easy to follow and
participate in. There are many and very diverse groups of people (at
Wikimedia and beyond)  that would give their feedback about design concepts
or alpha releases if they would only know about them.

We need to make our deployment process more flexible and predictable,
allowing development teams and communities to agree on beta releases, A/B
tests, opt-in/opt-out approaches, first/last waves... Some ideas:

* In order to enter the deployment phase, a project would need to have a
deployment plan proposed, agreed, and documented -- which can be adapted
based on data and feedback gathered.

* For every new product or significant feature, each community could have
the chance to determine whether they want to be early adopters (first
waves) or, on the contrary, be placed in the last waves, after seeing how
the new software is being used by others and is being matured.

* Communities would focus not so much on {{Support}} / {{Oppose}} decisions
about the totality of a feature, but on the identification of specific
blockers, allowing development teams to negotiate and change their plans
under clearer terms.

This common protocol should allow us to move away from the current
situation where both communities and development teams fear that a single
strike might disrupt their work overnight, without even seeing it coming.

A more predictable path with specialized checkpoints should allow
communities and development teams understanding better what is going on and
when to talk about what. It should also help recruiting more and more
diverse participants, who could contribute their time and skills in more
daring and productive ways.

What makes me optimistic about this common product development process is
that we don't need to finalize all the pieces to make it work. As long as
we agree that we are software partners and we agree that iterations are
good, we can start agreeing on improvements and implement them one by one.

Get involved, please. You can either join the more theoretical work about
the overall process or you can pick a specific improvement and help pushing
it forward in very practical terms. See you at
https://www.mediawiki.org/wiki/Talk:WMF_product_development_process (where
we have been a bit slow lately but not anymore now that is a top goal).

--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
___
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] How to disseminate free knowledge? Was: Profile of Magnus Manske

[Gerard Meijssen]

Hoi,
In my blogpost, Mr Anthony is linked to Reasonator [1]. With all due
respect, it provides better information than Wikidata does [2]. So when you
want to talk about quality, fine. This is where Wikidata will make the most
difference. It will also help you see that Mr Anthony is linked to a
publication [3] something you will miss when you rely on Wikidata alone.

You talk about quality and you are apparently of the opinion that
everything has to be "perfect". That is fine. Mr Anthony had several awards
and most of them I have added, I have added information about the
organisation that conferred them. For me quality is not in sources, they
are overrated. In Wikidata relevance is in the network, the linking of
people widely. A source at most gives an opinion on a single statement. By
including VIAF and ISNI, I do better, I link Mr Anthony to outside
Wikimedia because every Wikimedia project fails in this.

When you talk about quality, you can think on coverage. It noticed in a
blog somewhere that Wikipedia is so good in its information about ebola.
That is good. When you look at mental health, psychiatry Wikipedia is an
underachiever. Given the prevalence of psychiatry it is significant that we
are doing so poorly.

Yes we need to get our ships working together but as it is, the item of Mr
Anthony is 100% better because of me. What we need is a task force to get
proper information so that people are supported with proper information in
their recovery. Recovery is what Mr Anthony is about and that is where we
could do better.
Thanks,
   GerardM

[1] https://tools.wmflabs.org/reasonator/?&q=21745493
[2] https://www.wikidata.org/wiki/Q21745493
[3] https://tools.wmflabs.org/reasonator/?&q=22019124

On 19 January 2016 at 23:33, John Mark Vandenberg  wrote:

> On Tue, Jan 19, 2016 at 9:49 PM, Gerard Meijssen
>  wrote:
> > Hoi,
> >
> http://ultimategerardm.blogspot.nl/2016/01/wikidata-william-anthony-phd.html
>
> That blog post doesnt appear link to the Wikidata item.
>
> It is https://www.wikidata.org/wiki/Q21745493
>
> which only has 14 facts, but only one reference.
>
> It really should have a fact that he is a Professor Emeritus, as that
> is a very significant fact.
>
> Of the 11 awards list on
> http://cpr.bu.edu/about/directory/william-anthony, only 4 have been
> added to Wikidata.
>
> Distinguished Service Award of the President of the United States
> looks quite important, but has been omitted.
>
> My point I guess is this wikidata item is data; not knowledge, yet.
> ;-)  Until William Anthony is linked into his esteemed place in his
> field of excellence, we do him a disservice.  Lots of room for
> improvement.
>
> Or, we need all of our ships working together, and most of our
> community is moving from quantity to quality, seeing that as our next
> big challenge.
>
> --
> John Vandenberg
>
> ___
> 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] A page about new editors in different projects

[Pine W]

The Teahouse on English Wikipedia has a guest profile page (
https://en.wikipedia.org/wiki/Wikipedia:Teahouse/Guests), although it's low
traffic  I like
the idea of a higher profile way to welcome newcomers to the community.
Perhaps newcomers could be interviewed periodically in the Signpost.

Pine

On Tue, Jan 19, 2016 at 7:30 AM, Amir E. Aharoni <
amir.ahar...@mail.huji.ac.il> wrote:

> Hi,
>
> In the Hebrew Wikipedia there's a page [1] that highlights editors who
> recently became active - shows a short interview with them and welcomes
> them to the community in a nice way.
>
> It's not so much a help and a support page like English Wikipedia, but more
> like a newsletter or a blog that describes newcomers, in a form of an
> regularly updating wiki page.
>
> Is there anything like that in other projects and languages? (Not
> necessarily Wikipedia, of course.)
>
> Thanks!
>
> [1] https://he.wikipedia.org/wiki/WP:BIK
>
> --
> Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
> http://aharoni.wordpress.com
> ‪“We're living in pieces,
> I want to live in peace.” – T. Moore‬
> ___
> 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,