Re: [Wikimedia-l] Wikimedia Foundation supports legal challenge to new travel-related executive order

2017-03-15 Thread Newyorkbrad
Also of interest for those following these cases, today a majority of
the Ninth Circuit voted against an en banc rehearing regarding the
stay order in the State of Washington case.  The order and concurring
and dissenting opinions can be found at
http://cdn.ca9.uscourts.gov/datastore/general/2017/03/15/17-35105%20en%20banc.pdf

Newyorkbrad/IBM


On 3/15/17, Michelle Paulson  wrote:
> Hello All,
>
> I’m writing with a brief update; this afternoon, Judge Derrick K. Watson
> granted the temporary restraining order [1], blocking the executive order
> from enforcement nationwide. We are pleased with this result, and look
> forward to the next stages of the case, when the court will examine the
> order and its effects more thoroughly. We have updated the Foundation blog
> to reflect the hearing’s outcome [2].
>
> Best,
>
> Michelle Paulson
>
> [1] https://en.wikipedia.org/wiki/Executive_Order_13780#Hawaii
> [2]
> https://blog.wikimedia.org/2017/03/15/amicus-brief-us-travel-restrictions/
>
> ==
> Michelle Paulson
> Interim General Counsel
> Wikimedia Foundation
> 149 New Montgomery Street, 6th Floor
> San Francisco, CA 94105
> mpaul...@wikimedia.org
> 415.839.6885 ext. 6608 (Office)
> 415.882.0495 (Fax)
>
> *NOTICE: This message may be confidential or legally privileged. If you
> have received it by accident, please delete it and let us know about the
> mistake. As an attorney for the Wikimedia Foundation and for legal/ethical
> reasons, I cannot give legal advice to, or serve as a lawyer for, community
> members, volunteers, or staff members in their personal capacity. For more
> on what this means, please see our legal disclaimer
> .*
>
> On Wed, Mar 15, 2017 at 9:11 AM, Michelle Paulson 
> wrote:
>
>> Dear All,
>>
>> Yesterday, the Wikimedia Foundation joined more than 50 other
>> organizations, including Electronic Arts, Pinterest, and Zendesk, in
>> signing an amicus brief[1] that was filed in State of Hawaii v. Trump,[2]
>> a challenge to the new immigration-related executive order issued in the
>> United States.[3] This order was issued following legal challenges to a
>> previous executive order that instituted restrictions on immigration and
>> travel based upon national origin.[4]
>>
>> The amicus brief was filed in support of an application for a temporary
>> restraining order,[5] which would prevent the executive order from going
>> into effect until legal challenges to its substance can be heard by a
>> court. It details how the order’s provisions would harm the operations of
>> the signatories, including the Wikimedia Foundation. As an organization
>> that collaborates across borders daily, with staff, contractors, and
>> members of the Wikimedia communities, these restrictions will hamper the
>> Foundation’s ability to work effectively in pursuit of our mission to make
>> free knowledge globally available.
>>
>> The Wikimedia Foundation continuously monitors events around the world
>> that may impact the Foundation’s ability to support the projects and
>> communities. When that capacity is threatened, as in the case of these
>> travel restrictions, we will take action to protect the future of the
>> projects, our mission, and our team's ability to serve both. This is not
>> about political ideology, it is about preservation. More about today’s
>> filing is available on the Wikimedia blog.[6]
>>
>> Best,
>>
>> Michelle Paulson
>>
>> [1] https://wikimediafoundation.org/wiki/File:Tech_Amici_
>> Curiae_Brief,_Hawaii_v._Trump,_3.14.17.pdf
>>
>> [2] https://en.wikipedia.org/wiki/Executive_Order_13780#Hawaii
>>
>> [3] https://en.wikipedia.org/wiki/Executive_Order_13780
>>
>> [4] https://en.wikipedia.org/wiki/Executive_Order_13769
>>
>> [5] https://en.wikipedia.org/wiki/Injunction
>>
>> [6] https://blog.wikimedia.org/2017/03/15/amicus-brief-us-
>> travel-restrictions/
>>
>> ==
>> Michelle Paulson
>> Interim General Counsel
>> Wikimedia Foundation
>> 149 New Montgomery Street, 6th Floor
>> San Francisco, CA 94105
>> mpaul...@wikimedia.org
>> 415.839.6885 ext. 6608 <(415)%20839-6885> (Office)
>> 415.882.0495 <(415)%20882-0495> (Fax)
>>
>> *NOTICE: This message may be confidential or legally privileged. If you
>> have received it by accident, please delete it and let us know about the
>> mistake. As an attorney for the Wikimedia Foundation and for legal/ethical
>> reasons, I cannot give legal advice to, or serve as a lawyer for,
>> community
>> members, volunteers, or staff members in their personal capacity. For more
>> on what this means, please see our legal disclaimer
>> .*
>>
> ___
> 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/wiki

Re: [Wikimedia-l] Wikimedia Foundation supports legal challenge to new travel-related executive order

2017-03-15 Thread Michelle Paulson
Hello All,

I’m writing with a brief update; this afternoon, Judge Derrick K. Watson
granted the temporary restraining order [1], blocking the executive order
from enforcement nationwide. We are pleased with this result, and look
forward to the next stages of the case, when the court will examine the
order and its effects more thoroughly. We have updated the Foundation blog
to reflect the hearing’s outcome [2].

Best,

Michelle Paulson

[1] https://en.wikipedia.org/wiki/Executive_Order_13780#Hawaii
[2]
https://blog.wikimedia.org/2017/03/15/amicus-brief-us-travel-restrictions/

==
Michelle Paulson
Interim General Counsel
Wikimedia Foundation
149 New Montgomery Street, 6th Floor
San Francisco, CA 94105
mpaul...@wikimedia.org
415.839.6885 ext. 6608 (Office)
415.882.0495 (Fax)

*NOTICE: This message may be confidential or legally privileged. If you
have received it by accident, please delete it and let us know about the
mistake. As an attorney for the Wikimedia Foundation and for legal/ethical
reasons, I cannot give legal advice to, or serve as a lawyer for, community
members, volunteers, or staff members in their personal capacity. For more
on what this means, please see our legal disclaimer
.*

On Wed, Mar 15, 2017 at 9:11 AM, Michelle Paulson 
wrote:

> Dear All,
>
> Yesterday, the Wikimedia Foundation joined more than 50 other
> organizations, including Electronic Arts, Pinterest, and Zendesk, in
> signing an amicus brief[1] that was filed in State of Hawaii v. Trump,[2]
> a challenge to the new immigration-related executive order issued in the
> United States.[3] This order was issued following legal challenges to a
> previous executive order that instituted restrictions on immigration and
> travel based upon national origin.[4]
>
> The amicus brief was filed in support of an application for a temporary
> restraining order,[5] which would prevent the executive order from going
> into effect until legal challenges to its substance can be heard by a
> court. It details how the order’s provisions would harm the operations of
> the signatories, including the Wikimedia Foundation. As an organization
> that collaborates across borders daily, with staff, contractors, and
> members of the Wikimedia communities, these restrictions will hamper the
> Foundation’s ability to work effectively in pursuit of our mission to make
> free knowledge globally available.
>
> The Wikimedia Foundation continuously monitors events around the world
> that may impact the Foundation’s ability to support the projects and
> communities. When that capacity is threatened, as in the case of these
> travel restrictions, we will take action to protect the future of the
> projects, our mission, and our team's ability to serve both. This is not
> about political ideology, it is about preservation. More about today’s
> filing is available on the Wikimedia blog.[6]
>
> Best,
>
> Michelle Paulson
>
> [1] https://wikimediafoundation.org/wiki/File:Tech_Amici_
> Curiae_Brief,_Hawaii_v._Trump,_3.14.17.pdf
>
> [2] https://en.wikipedia.org/wiki/Executive_Order_13780#Hawaii
>
> [3] https://en.wikipedia.org/wiki/Executive_Order_13780
>
> [4] https://en.wikipedia.org/wiki/Executive_Order_13769
>
> [5] https://en.wikipedia.org/wiki/Injunction
>
> [6] https://blog.wikimedia.org/2017/03/15/amicus-brief-us-
> travel-restrictions/
>
> ==
> Michelle Paulson
> Interim General Counsel
> Wikimedia Foundation
> 149 New Montgomery Street, 6th Floor
> San Francisco, CA 94105
> mpaul...@wikimedia.org
> 415.839.6885 ext. 6608 <(415)%20839-6885> (Office)
> 415.882.0495 <(415)%20882-0495> (Fax)
>
> *NOTICE: This message may be confidential or legally privileged. If you
> have received it by accident, please delete it and let us know about the
> mistake. As an attorney for the Wikimedia Foundation and for legal/ethical
> reasons, I cannot give legal advice to, or serve as a lawyer for, community
> members, volunteers, or staff members in their personal capacity. For more
> on what this means, please see our legal disclaimer
> .*
>
___
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] WikiJournal project

2017-03-15 Thread Vi to
I missed your email so I wrote the same thing by mistake, sorry!

Vito

2017-03-15 16:26 GMT+01:00 Brad Jorsch (Anomie) :

> On Tue, Mar 14, 2017 at 10:45 PM, Felipe Schenone 
> wrote:
>
> > If we migrate the content we currently have (on Meta and
> > Wikiversity) to wikijournal.org, and the project grows, and eventually
> > gets
> > accepted as a sister-project (as we hope), how will we merge the user
> > accounts? Should we not worry about it, and we'll figure it out when the
> > time comes? Or should we totally worry about it, and adopt some strategy
> > about it now? What's your advice on this issue?
>
>
> Note: This post is my personal view and in no way represents any official
> WMF position.
>
> My personal guess is that it would wind up being done something like how
> accounts on WikiVoyage were handled: people who used the same username on
> both WikiVoyage and Wikimedia wikis were able to merge those accounts,
> people whose usernames weren't already in use on Wikimedia wikis were able
> to claim those names, and other people had to be renamed. Or at least it
> seems that's what was done based on the plan document on mediawiki.org[1]
> and the process page on en.wikivoyage.org.[2]
>
> To reduce the number of people who would need renaming should the time
> come, you might start using an extension like OAuthAuthentication[3] to
> authenticate against Meta, and disable any further local account creations.
>
> [1]: https://www.mediawiki.org/wiki/Wikivoyage_migration/Accounts
> [2]: https://en.wikivoyage.org/wiki/Wikivoyage:User_account_migration
> [3]: https://www.mediawiki.org/wiki/Extension:OAuthAuthentication
> ___
> 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] WikiJournal project

2017-03-15 Thread Peter Southwood
That looks about right. (how it happened)
Cheers,
Peter

-Original Message-
From: Wikimedia-l [mailto:wikimedia-l-boun...@lists.wikimedia.org] On Behalf Of 
Felipe Schenone
Sent: Wednesday, 15 March 2017 9:44 PM
To: Wikimedia Mailing List
Subject: Re: [Wikimedia-l] WikiJournal project

Awesome advice Brad, I can't think of a better solution than that, thanks!

On Wed, Mar 15, 2017 at 12:26 PM Brad Jorsch (Anomie) 
wrote:

> On Tue, Mar 14, 2017 at 10:45 PM, Felipe Schenone 
> 
> wrote:
>
> > If we migrate the content we currently have (on Meta and
> > Wikiversity) to wikijournal.org, and the project grows, and 
> > eventually gets accepted as a sister-project (as we hope), how will 
> > we merge the user accounts? Should we not worry about it, and we'll 
> > figure it out when the time comes? Or should we totally worry about 
> > it, and adopt some strategy about it now? What's your advice on this 
> > issue?
>
>
> Note: This post is my personal view and in no way represents any 
> official WMF position.
>
> My personal guess is that it would wind up being done something like 
> how accounts on WikiVoyage were handled: people who used the same 
> username on both WikiVoyage and Wikimedia wikis were able to merge 
> those accounts, people whose usernames weren't already in use on 
> Wikimedia wikis were able to claim those names, and other people had 
> to be renamed. Or at least it seems that's what was done based on the 
> plan document on mediawiki.org[1] and the process page on 
> en.wikivoyage.org.[2]
>
> To reduce the number of people who would need renaming should the time 
> come, you might start using an extension like OAuthAuthentication[3] 
> to authenticate against Meta, and disable any further local account creations.
>
> [1]: https://www.mediawiki.org/wiki/Wikivoyage_migration/Accounts
> [2]: https://en.wikivoyage.org/wiki/Wikivoyage:User_account_migration
> [3]: https://www.mediawiki.org/wiki/Extension:OAuthAuthentication
> ___
> 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, 


-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2016.0.8007 / Virus Database: 4756/14120 - Release Date: 03/15/17


___
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] WikiJournal project

2017-03-15 Thread Peter Southwood
When Wikivoyage joined WMF as a fork from Wikitravel they had to deal with the 
same problem. It should be in the records somewhere. It wasn’t a big deal from 
memory. I had the same username on both anyway. A few people had to change when 
there were conflicts, and a few dropped one name as redundant.
Cheers,
Peter

-Original Message-
From: Wikimedia-l [mailto:wikimedia-l-boun...@lists.wikimedia.org] On Behalf Of 
Felipe Schenone
Sent: Wednesday, 15 March 2017 4:45 AM
To: wikimedia-l@lists.wikimedia.org
Subject: [Wikimedia-l] WikiJournal project

Hi! So there's a sprouting project called WikiJournal 
, the basic idea of 
which is to develop an open peer-reviewed academic journal, where we can all 
publish our research, and also, maybe, permalinks to Wikipedia articles that 
have been peer-reviewed (featured articles) together with the names of the main 
author(s), so as to give some well-deserved credit.

Anyway, the thing is that recently, we've been talking to the owner of 
wikijournal.org, a fairly similar project with the perfect domain name, and he 
has agreed to a merge. So now we're all excited trying to figure out the 
details of the merge, and there's one particular issue I'd like to ask about. 
If we migrate the content we currently have (on Meta and
Wikiversity) to wikijournal.org, and the project grows, and eventually gets 
accepted as a sister-project (as we hope), how will we merge the user accounts? 
Should we not worry about it, and we'll figure it out when the time comes? Or 
should we totally worry about it, and adopt some strategy about it now? What's 
your advice on this issue? I've been looking around for documentation but the 
most relevant one  seems 
to have no advice on this point.

Thanks for any input!
___
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, 


-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2016.0.7998 / Virus Database: 4756/14115 - Release Date: 03/14/17


___
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] WikiJournal project

2017-03-15 Thread Vi to
You can think about relying upon WMF OAuth to login to wikijournal.
Basically anyone would be able to login to wikijournal using their WMF
wikis' credentials. If you make this the sole way to login you'll end up
having an already-ready-to-merge userbase.

Vito

2017-03-15 20:44 GMT+01:00 Felipe Schenone :

> Awesome advice Brad, I can't think of a better solution than that, thanks!
>
> On Wed, Mar 15, 2017 at 12:26 PM Brad Jorsch (Anomie) <
> bjor...@wikimedia.org>
> wrote:
>
> > On Tue, Mar 14, 2017 at 10:45 PM, Felipe Schenone 
> > wrote:
> >
> > > If we migrate the content we currently have (on Meta and
> > > Wikiversity) to wikijournal.org, and the project grows, and eventually
> > > gets
> > > accepted as a sister-project (as we hope), how will we merge the user
> > > accounts? Should we not worry about it, and we'll figure it out when
> the
> > > time comes? Or should we totally worry about it, and adopt some
> strategy
> > > about it now? What's your advice on this issue?
> >
> >
> > Note: This post is my personal view and in no way represents any official
> > WMF position.
> >
> > My personal guess is that it would wind up being done something like how
> > accounts on WikiVoyage were handled: people who used the same username on
> > both WikiVoyage and Wikimedia wikis were able to merge those accounts,
> > people whose usernames weren't already in use on Wikimedia wikis were
> able
> > to claim those names, and other people had to be renamed. Or at least it
> > seems that's what was done based on the plan document on mediawiki.org
> [1]
> > and the process page on en.wikivoyage.org.[2]
> >
> > To reduce the number of people who would need renaming should the time
> > come, you might start using an extension like OAuthAuthentication[3] to
> > authenticate against Meta, and disable any further local account
> creations.
> >
> > [1]: https://www.mediawiki.org/wiki/Wikivoyage_migration/Accounts
> > [2]: https://en.wikivoyage.org/wiki/Wikivoyage:User_account_migration
> > [3]: https://www.mediawiki.org/wiki/Extension:OAuthAuthentication
> > ___
> > 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: [Wikimedia-l] WikiJournal project

2017-03-15 Thread Felipe Schenone
Awesome advice Brad, I can't think of a better solution than that, thanks!

On Wed, Mar 15, 2017 at 12:26 PM Brad Jorsch (Anomie) 
wrote:

> On Tue, Mar 14, 2017 at 10:45 PM, Felipe Schenone 
> wrote:
>
> > If we migrate the content we currently have (on Meta and
> > Wikiversity) to wikijournal.org, and the project grows, and eventually
> > gets
> > accepted as a sister-project (as we hope), how will we merge the user
> > accounts? Should we not worry about it, and we'll figure it out when the
> > time comes? Or should we totally worry about it, and adopt some strategy
> > about it now? What's your advice on this issue?
>
>
> Note: This post is my personal view and in no way represents any official
> WMF position.
>
> My personal guess is that it would wind up being done something like how
> accounts on WikiVoyage were handled: people who used the same username on
> both WikiVoyage and Wikimedia wikis were able to merge those accounts,
> people whose usernames weren't already in use on Wikimedia wikis were able
> to claim those names, and other people had to be renamed. Or at least it
> seems that's what was done based on the plan document on mediawiki.org[1]
> and the process page on en.wikivoyage.org.[2]
>
> To reduce the number of people who would need renaming should the time
> come, you might start using an extension like OAuthAuthentication[3] to
> authenticate against Meta, and disable any further local account creations.
>
> [1]: https://www.mediawiki.org/wiki/Wikivoyage_migration/Accounts
> [2]: https://en.wikivoyage.org/wiki/Wikivoyage:User_account_migration
> [3]: https://www.mediawiki.org/wiki/Extension:OAuthAuthentication
> ___
> 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] Wikimedia Foundation supports legal challenge to new travel-related executive order

2017-03-15 Thread Michelle Paulson
Dear All,

Yesterday, the Wikimedia Foundation joined more than 50 other
organizations, including Electronic Arts, Pinterest, and Zendesk, in
signing an amicus brief[1] that was filed in State of Hawaii v. Trump,[2] a
challenge to the new immigration-related executive order issued in the
United States.[3] This order was issued following legal challenges to a
previous executive order that instituted restrictions on immigration and
travel based upon national origin.[4]

The amicus brief was filed in support of an application for a temporary
restraining order,[5] which would prevent the executive order from going
into effect until legal challenges to its substance can be heard by a
court. It details how the order’s provisions would harm the operations of
the signatories, including the Wikimedia Foundation. As an organization
that collaborates across borders daily, with staff, contractors, and
members of the Wikimedia communities, these restrictions will hamper the
Foundation’s ability to work effectively in pursuit of our mission to make
free knowledge globally available.

The Wikimedia Foundation continuously monitors events around the world that
may impact the Foundation’s ability to support the projects and
communities. When that capacity is threatened, as in the case of these
travel restrictions, we will take action to protect the future of the
projects, our mission, and our team's ability to serve both. This is not
about political ideology, it is about preservation. More about today’s
filing is available on the Wikimedia blog.[6]

Best,

Michelle Paulson

[1]
https://wikimediafoundation.org/wiki/File:Tech_Amici_Curiae_Brief,_Hawaii_v._Trump,_3.14.17.pdf

[2] https://en.wikipedia.org/wiki/Executive_Order_13780#Hawaii

[3] https://en.wikipedia.org/wiki/Executive_Order_13780

[4] https://en.wikipedia.org/wiki/Executive_Order_13769

[5] https://en.wikipedia.org/wiki/Injunction

[6]
https://blog.wikimedia.org/2017/03/15/amicus-brief-us-travel-restrictions/

==
Michelle Paulson
Interim General Counsel
Wikimedia Foundation
149 New Montgomery Street, 6th Floor
San Francisco, CA 94105
mpaul...@wikimedia.org
415.839.6885 ext. 6608 (Office)
415.882.0495 (Fax)

*NOTICE: This message may be confidential or legally privileged. If you
have received it by accident, please delete it and let us know about the
mistake. As an attorney for the Wikimedia Foundation and for legal/ethical
reasons, I cannot give legal advice to, or serve as a lawyer for, community
members, volunteers, or staff members in their personal capacity. For more
on what this means, please see our legal disclaimer
.*
___
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] WikiJournal project

2017-03-15 Thread Brad Jorsch (Anomie)
On Tue, Mar 14, 2017 at 10:45 PM, Felipe Schenone 
wrote:

> If we migrate the content we currently have (on Meta and
> Wikiversity) to wikijournal.org, and the project grows, and eventually
> gets
> accepted as a sister-project (as we hope), how will we merge the user
> accounts? Should we not worry about it, and we'll figure it out when the
> time comes? Or should we totally worry about it, and adopt some strategy
> about it now? What's your advice on this issue?


Note: This post is my personal view and in no way represents any official
WMF position.

My personal guess is that it would wind up being done something like how
accounts on WikiVoyage were handled: people who used the same username on
both WikiVoyage and Wikimedia wikis were able to merge those accounts,
people whose usernames weren't already in use on Wikimedia wikis were able
to claim those names, and other people had to be renamed. Or at least it
seems that's what was done based on the plan document on mediawiki.org[1]
and the process page on en.wikivoyage.org.[2]

To reduce the number of people who would need renaming should the time
come, you might start using an extension like OAuthAuthentication[3] to
authenticate against Meta, and disable any further local account creations.

[1]: https://www.mediawiki.org/wiki/Wikivoyage_migration/Accounts
[2]: https://en.wikivoyage.org/wiki/Wikivoyage:User_account_migration
[3]: https://www.mediawiki.org/wiki/Extension:OAuthAuthentication
___
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] Product draft goals posted on mediawiki

2017-03-15 Thread Toby Negrin
Hi everyone --

I wanted to let you know that the product team has posted our draft goals
for next quarter (the fourth quarter of the Foundation's fiscal year aka
Q4) up on mediawiki:

https://www.mediawiki.org/wiki/Wikimedia_Engineering/2016-17_Q4_Goals#Product

Please take a look and let us know your thoughts on the talk page. We'd
like to lock these goals and make a commitment to them in a week or two.

thanks,

-Toby
___
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] Spam email (Was: interesting reading)

2017-03-15 Thread Katie Chan

Spam/scam, with a forged from email address field.

Apology to anyone who received the original email(s).

KTC

On 15/03/2017 09:55, Andrea Zanni wrote:

mmm, scam?

Aubrey



--
Katie Chan
Any views or opinions presented in this e-mail are solely those of the 
author and do not necessarily represent the view of any organisation the 
author is associated with or employed by.



Experience is a good school but the fees are high.
- Heinrich Heine

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


___
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] [Wikisource-l] interesting reading

2017-03-15 Thread Andrea Zanni
mmm, scam?

Aubrey

On Wed, Mar 15, 2017 at 10:52 AM, Wikimedia-l  wrote:

> Hi friend!
>
>
>
> I've found a nice book that makes interesting reading, please read it here 
> continue
> reading 
>
>
>
> Yours faithfully, Wikimedia-l
>
>
> ___
> Wikisource-l mailing list
> wikisourc...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikisource-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] interesting reading

2017-03-15 Thread Wikimedia-l
Hi friend! 

I've found a nice book that makes interesting reading, please read it here 
http://venue.theshowalter.net/bebf

Yours faithfully, 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] Using non-free elements vs our values (Apple Maps vs Wikipedia iOS app)

2017-03-15 Thread Magnus Manske
Hi Josh, all,

I am not one hell-bent on "FOSS or death"; I tend to use whatever works
best.

That said, the cost-benefit analysis of using Apple Maps seems to boil down:
* Apple Maps has slightly better rendering (didn't check, but I assume)
* Apple Maps uses less mobile bandwidth
* Apple Maps is not free (as in freedom)

Now, looking at these points:

* Somewhat better quality is not an argument. If it were, we would have
stayed with Britannica, and skipped that whole Wikipedia nonsense.
Wikipedia became better, in part, because people actually used it, saw the
issues, and fixed them. And OSM rendering might be not quite en par with
Apple Maps, it is quite usable, in my experience.

* Less bandwidth usage is not an argument either. I doubt we are talking
about a significant percentage of an average users' data volume here. If
Android users can afford the bandwidth, so can people who buy an iPhone
(source: used to have iPhone).

* The price tag is the "non-freedom". As far as I can tell, this would be
the very first Wikimedia "product" that incorporates non-free technology
and data. It sets a precedence. It also has the potential to poison the
otherwise great relations between the Wikipedia, Wikidata, and OSM
community. It says "OSM is not good enough (at least for Apple users)"
quite plainly. How would we feel if OSM started to remove Wikidata tags and
replace them with Britannica links?

All in all, IMHO, the cost is too high for the (at best) flimsy benefits.

Cheers,
Magnus


On Wed, Mar 15, 2017 at 12:52 AM Joshua Minor  wrote:

> Hello,
>
> My name is Josh Minor, and I am the Product Manager for the Wikipedia iOS
> app. I wanted to speak to a couple specific issues and misunderstandings
> raised by this email thread.
>
> First, please take a look at
> https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service which
> provides some background on this decision. Jonatan linked to it, and it
> covers several of the concerns raised on the thread and gives our
> reasoning. I'd also suggest subscribing to this ticket:
> https://phabricator.wikimedia.org/T157763 which Jonatan filed, and where
> you can track efforts and issues with replacement maps.
>
> A few clarifying points:
>
> 1. The Places tab[1], and its use of Apple’s maps tiles, is not part of the
> articles or article display, it is a navigational aid to help you find
> articles. This doesn’t mean it’s exempt from considerations raised here,
> but just want to clarify that this is not about editor created maps in
> projects, but rather an app-specific discovery mechanism.
>
> 2. The feature doesn’t violate our privacy policy[2] and was reviewed by
> Wikimedia Foundation's Legal department before entering beta. The App’s
> access to the users’ geolocation to recommend nearby articles, with the
> users’ explicit consent, is already part of both apps. The new feature
> merely adds a different way to visually view nearby articles - the user
> must, as before, still provide explicit consent for the App to access their
> geolocation. Users can always turn on or off the provision of their
> geolocation via their iPhone location settings.
>
> The feature also makes requests to Apple’s map tile servers for display on
> the App. These tiles may or may not be near the actual location of the
> user. It doesn’t involve sending Apple the articles you read or anything
> about your Wikipedia usage. Apple has public statements and documentation
> to explain[3] how their maps service preserves privacy by using a
> randomized and frequently changing device ID to request the maps, by not
> tracking users over time, and by not  building map usage profiles of users.
> Overall, Apple’s data collection practices are governed by their privacy
> policy [4], which  users must agree to order to use their iPhones.
>
> We plan to further expand the explanation in the FAQ/privacy section of the
> https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service page
> in
> the next day or so.
>
> 3. As stated by others on this thread, the issue at hand is the feasibility
> and usability of a libre maps tile server, and impacts on users and how it
> reflects (or doesn’t) the values of Wikimedians. The rest of the work on
> this feature (such as the time spent on search, visually clustering items
> on the map, a list view of nearby landmarks, and the Wikipedia article
> pins) will be applicable, independent of the map provider. In fact, I’d
> estimate the engineer doing the work spent more time on hacking to try to
> make a combination of MapBox and Wikimedia tiles work, than he did/will on
> integrating/removing Apple maps.
>
> 4. This feature was announced on the Wikimedia Blog[5], described in an
> initial MediaWiki.org page[6], all work was documented and tracked on
> Phabricator (including an initial tech investigation, the request to remove
> Apple Maps during development, and the overall feature[7]) and then the
> decision to push into beta with Apple Maps furth

Re: [Wikimedia-l] Using non-free elements vs our values (Apple Maps vs Wikipedia iOS app)

2017-03-15 Thread Gerard Meijssen
Hoi,
One point about OSM is that it provides a better service in situations that
are sub optimal. The infra structure for Haiti is diminished and it is in
OSM where people are actually working hard to provide the best map service.

We have had nearby function in Labs for a very long time, I have read the
article and I find what has been decided, it does not provide me with the
reasons for it. As far as I am concerned you chose to go this way.
Thanks,
   GerardM

On 15 March 2017 at 01:18, Joshua Minor  wrote:

> Hello,
>
> My name is Josh Minor, and I am the Product Manager for the Wikipedia iOS
> app. I wanted to speak to a couple specific issues and misunderstandings
> raised by this email thread.
>
> First, please take a look at
> https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service which
> provides some background on this decision. Jonatan linked to it, and it
> covers several of the concerns raised on the thread and gives our
> reasoning. I'd also suggest subscribing to this ticket:
> https://phabricator.wikimedia.org/T157763 which Jonatan filed, and where
> you can track efforts and issues with replacement maps.
>
> A few clarifying points:
>
> 1. The Places tab[1], and its use of Apple’s maps tiles, is not part of the
> articles or article display, it is a navigational aid to help you find
> articles. This doesn’t mean it’s exempt from considerations raised here,
> but just want to clarify that this is not about editor created maps in
> projects, but rather an app-specific discovery mechanism.
>
> 2. The feature doesn’t violate our privacy policy[2] and was reviewed by
> Wikimedia Foundation's Legal department before entering beta. The App’s
> access to the users’ geolocation to recommend nearby articles, with the
> users’ explicit consent, is already part of both apps. The new feature
> merely adds a different way to visually view nearby articles - the user
> must, as before, still provide explicit consent for the App to access their
> geolocation. Users can always turn on or off the provision of their
> geolocation via their iPhone location settings.
>
> The feature also makes requests to Apple’s map tile servers for display on
> the App. These tiles may or may not be near the actual location of the
> user. It doesn’t involve sending Apple the articles you read or anything
> about your Wikipedia usage. Apple has public statements and documentation
> to explain[3] how their maps service preserves privacy by using a
> randomized and frequently changing device ID to request the maps, by not
> tracking users over time, and by not  building map usage profiles of users.
> Overall, Apple’s data collection practices are governed by their privacy
> policy [4], which  users must agree to order to use their iPhones.
>
> We plan to further expand the explanation in the FAQ/privacy section of the
> https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service page
> in
> the next day or so.
>
> 3. As stated by others on this thread, the issue at hand is the feasibility
> and usability of a libre maps tile server, and impacts on users and how it
> reflects (or doesn’t) the values of Wikimedians. The rest of the work on
> this feature (such as the time spent on search, visually clustering items
> on the map, a list view of nearby landmarks, and the Wikipedia article
> pins) will be applicable, independent of the map provider. In fact, I’d
> estimate the engineer doing the work spent more time on hacking to try to
> make a combination of MapBox and Wikimedia tiles work, than he did/will on
> integrating/removing Apple maps.
>
> 4. This feature was announced on the Wikimedia Blog[5], described in an
> initial MediaWiki.org page[6], all work was documented and tracked on
> Phabricator (including an initial tech investigation, the request to remove
> Apple Maps during development, and the overall feature[7]) and then the
> decision to push into beta with Apple Maps further documented on
> MediaWiki.org[8].
>
> In conclusion, I would like to thank you for the feedback and the
> opportunity to engage in a civil discussion about these important issues.
> Again, if you are interested in the next steps, I’d invite you to subscribe
> and comment on the phab ticket https://phabricator.wikimedia.org/T157763
> or
> the MediaWiki.org page.
>
> [1] Design specification: https://phabricator.wikimedia.org/T130889
> [2]
> https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/
> Maps_service#Privacy
> [3] https://support.apple.com/en-us/HT203033,
> https://support.apple.com/en-us/HT207056,
> http://www.apple.com/privacy/approach-to-privacy/
> [4] http://www.apple.com/privacy/privacy-policy/
> [5] https://blog.wikimedia.org/2016/06/17/wikipedia-mobile/
> [6] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Nearby
> [7] https://phabricator.wikimedia.org/tag/ios-app-feature-places/
> [8] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service
> __