Re: [Wikimedia-l] Paid API?

2020-07-23 Thread Leila Zia
Hi Victoria,

I hope you're doing well. Please see below.

On Mon, Jul 20, 2020 at 12:19 PM Victoria Coleman
 wrote:
>
> The WMF Cloud Services team can totally provide the needed support. The 
> Foundation would have to invest them to build up the team which is over 
> stretched but that should easily pay for itself as revenue starts flowing in 
> from the paid API.

You have worked in WMF and you are more deeply familiar with the
internal workings of WMF, however, for the sake of others who read
your comments above, I'd like to share some thoughts:

* I have concerns about specific teams in WMF being volunteered on a
public list for a project or work. As you know, adding a project to a
team's set of responsibilities is not just about making a financial
investment. Teams usually have plans for what they want to do over the
coming 1-2 years and expanding the scope of their work or the
diversity of what they need to manage can have major implications for
the teams.

Instead, I encourage us to ask the question "what does it take to be
able to do x in our own infrastructure?" when we know this is the kind
of experiment that has worked.

* As has been shared before, the project is at the "experiment" level.
When we don't know if an idea even works or not, we want to be mindful
of our time investments. I personally want to be able to trust the
team who is responsible for the project in assessing where the best
place to invest their time is as they have better visibility into the
work and the resources that are available to them.

* You said "The Foundation would have to invest them to build up the
team [...]". I want to be very explicit: the problem of where to
invest the WMF resources is a very very complex problem. There are
many important projects and ideas in WMF, all potentially with big
impact, and there are, as you had more visibility into during your
tenure, critical efforts that can benefit from much more investments.
The c-team has a hard job each time they make resourcing decisions:
they can't think about one project or one team only. They need to take
into account the portfolio of projects and needs the WMF has and
figure out where to invest. You and I may or may not agree with their
decisions, however, I'd caution us from assuming that this is the kind
of problem that we can easily solve once we're in their shoes.

Best,
Leila

--
Leila Zia
Head of Research
Wikimedia Foundation

> Victoria
>
> > On Jul 9, 2020, at 1:38 PM, Kunal Mehta  wrote:
> >
> > Hi,
> >
> > On 2020-07-09 13:15, Dan Garry (Deskana) wrote:
> >> Which cloud provider would you recommend?
> >
> > Wikimedia Cloud Services, which incidentally, has the fastest network
> > connection to Wikimedia sites by virtue of it being hosted *inside* the
> > cluster.
> >
> > -- Legoktm
> >
> > ___
> > 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] Paid API?

2020-07-23 Thread Joseph Seddon
And just as an additional note. Using AWS was mainly because it was what
the team was most familiar with and enabled us to prototype faster. We know
there are going to be a lot of requirements from a lot of different users
from with the WMF, the broader technical community, researchers along with
mission aligned reusers and we are beginning to gather those now and that
will help work out what needs to be done in the long term.

One of the advantages we will have is that if it does wholly or in part at
some point get brought onto Wikimedia Cloud Services, we will know exactly
what the requirements will be.

Regards
Seddon

On Thu, Jul 23, 2020 at 5:26 PM Joseph Seddon  wrote:

> Hey all,
>
> Given that this project is a direct result of the recommendations from the
> strategy process the biggest questions are I feel mainly about how we go
> about this. There are really bad ways this project could be approached and
> then there are ways which are aligned with our movement and we are most
> definitely approaching this project via the latter.
>
> Regarding the hosting on AWS, when the project started it wasn't clear to
> what extent we would be able to utilise Wikimedia Cloud Services in short
> and long term for this specific project and that remains true for a number
> of reasons. This has brought a benefit as it means we have been highly
> conservative in our development approach. In the HTML dump work ongoing, we
> are utilising purely public endpoints and we have purposefully
> containerized the entire application in docker to allow flexibility of
> infrastructure as well as remove any dependencies to AWS. This was
> identified as a requirement pretty early on so things have been designed in
> a way to avoid obvious pitfalls like becoming dependent on RDS or S3 and
> aim to make the tools we build platform agnostic and fully open source.
>
> We will be beginning a regular release of the code base soon that will
> hopefully be aligned with the end of sprints. Given that there is nothing
> preventing this from also existing on Wikimedia Cloud Services or any other
> cloud infrastructure. In the long term our goal is to try and make anything
> we build usable by anyone.
>
> Regards
> Seddon
>
> On Thu, Jul 23, 2020 at 5:03 PM Victoria Coleman <
> vstavridoucole...@gmail.com> wrote:
>
>> Rupert,
>>
>> My comment below referred to the point Kunal made about hosting should
>> the movement decide (and it is a movement decision in my view) to go
>> forward with a paid API. There is a healthy debate as you point out about
>> the wisdom or otherwise of doing so. But should a decision be made to go
>> forward, I believe that the hosting can be done on WMF clusters run by the
>> Cloud Services team to avoid putting our content on 3rd party commercial
>> services. While I was on staff, and I don’t think this has changed since my
>> departure, the preference was to maintain control of content - including
>> accessing it  - internally to protect movement privacy. If I had a penny
>> for every time I got an offer of “free” hosting from AWS and others, my
>> penny jar would be overflowing!
>>
>> All the best,
>>
>> Victoria
>>
>> > On Jul 22, 2020, at 12:50 AM, rupert THURNER 
>> wrote:
>> >
>> > victoria, discussions to monetize the wikipedia content in one or the
>> other
>> > way are as old as wikipedia. some people say "why should i continue
>> editing
>> > and supporting wikipedia in my free time, or donate money, attracted by
>> the
>> > vision to make it available to all, without condition, when WMF starts
>> > selling parts of it?" while the others feel that wikipedia relying on
>> > donations only keeps them at a shoestring budget, which meanwhile grew
>> to
>> > 100 million USD a year. up to now the discussion always ended with a
>> > similar result: wikipedia would loose more than it would gain, and the
>> > initiative stopped. why this time it would be different? even more so as
>> > this API idea was already there when sue gardner joined 10 or more years
>> > ago. but maybe it becomes a good idea over time if it is brought up
>> often
>> > enough and the environment changes. in 20 years or so, when the
>> wikipedia
>> > content is auto-generated, auto-translated and WMF has no employees any
>> > more and no need of voluntary work this for sure would work.
>> >
>> > rupert
>> >
>> >
>> > On Mon, Jul 20, 2020 at 9:19 PM Victoria Coleman <
>> > vstavridoucole...@gmail.com> wrote:
>> >
>> >> +1 Kunal! The WMF Cloud Services team can totally provide the needed
>> >> support. The Foundation would have to invest them to build up the team
>> >> which is over stretched but that should easily pay for itself as
>> revenue
>> >> starts flowing in from the paid API.
>> >>
>> >> Victoria
>> >>
>> >>> On Jul 9, 2020, at 1:38 PM, Kunal Mehta 
>> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> On 2020-07-09 13:15, Dan Garry (Deskana) wrote:
>>  Which cloud provider would you recommend?
>> >>>
>> >>> Wikimedia Cloud Services, 

Re: [Wikimedia-l] Paid API?

2020-07-23 Thread Joseph Seddon
Hey all,

Given that this project is a direct result of the recommendations from the
strategy process the biggest questions are I feel mainly about how we go
about this. There are really bad ways this project could be approached and
then there are ways which are aligned with our movement and we are most
definitely approaching this project via the latter.

Regarding the hosting on AWS, when the project started it wasn't clear to
what extent we would be able to utilise Wikimedia Cloud Services in short
and long term for this specific project and that remains true for a number
of reasons. This has brought a benefit as it means we have been highly
conservative in our development approach. In the HTML dump work ongoing, we
are utilising purely public endpoints and we have purposefully
containerized the entire application in docker to allow flexibility of
infrastructure as well as remove any dependencies to AWS. This was
identified as a requirement pretty early on so things have been designed in
a way to avoid obvious pitfalls like becoming dependent on RDS or S3 and
aim to make the tools we build platform agnostic and fully open source.

We will be beginning a regular release of the code base soon that will
hopefully be aligned with the end of sprints. Given that there is nothing
preventing this from also existing on Wikimedia Cloud Services or any other
cloud infrastructure. In the long term our goal is to try and make anything
we build usable by anyone.

Regards
Seddon

On Thu, Jul 23, 2020 at 5:03 PM Victoria Coleman <
vstavridoucole...@gmail.com> wrote:

> Rupert,
>
> My comment below referred to the point Kunal made about hosting should the
> movement decide (and it is a movement decision in my view) to go forward
> with a paid API. There is a healthy debate as you point out about the
> wisdom or otherwise of doing so. But should a decision be made to go
> forward, I believe that the hosting can be done on WMF clusters run by the
> Cloud Services team to avoid putting our content on 3rd party commercial
> services. While I was on staff, and I don’t think this has changed since my
> departure, the preference was to maintain control of content - including
> accessing it  - internally to protect movement privacy. If I had a penny
> for every time I got an offer of “free” hosting from AWS and others, my
> penny jar would be overflowing!
>
> All the best,
>
> Victoria
>
> > On Jul 22, 2020, at 12:50 AM, rupert THURNER 
> wrote:
> >
> > victoria, discussions to monetize the wikipedia content in one or the
> other
> > way are as old as wikipedia. some people say "why should i continue
> editing
> > and supporting wikipedia in my free time, or donate money, attracted by
> the
> > vision to make it available to all, without condition, when WMF starts
> > selling parts of it?" while the others feel that wikipedia relying on
> > donations only keeps them at a shoestring budget, which meanwhile grew to
> > 100 million USD a year. up to now the discussion always ended with a
> > similar result: wikipedia would loose more than it would gain, and the
> > initiative stopped. why this time it would be different? even more so as
> > this API idea was already there when sue gardner joined 10 or more years
> > ago. but maybe it becomes a good idea over time if it is brought up often
> > enough and the environment changes. in 20 years or so, when the wikipedia
> > content is auto-generated, auto-translated and WMF has no employees any
> > more and no need of voluntary work this for sure would work.
> >
> > rupert
> >
> >
> > On Mon, Jul 20, 2020 at 9:19 PM Victoria Coleman <
> > vstavridoucole...@gmail.com> wrote:
> >
> >> +1 Kunal! The WMF Cloud Services team can totally provide the needed
> >> support. The Foundation would have to invest them to build up the team
> >> which is over stretched but that should easily pay for itself as revenue
> >> starts flowing in from the paid API.
> >>
> >> Victoria
> >>
> >>> On Jul 9, 2020, at 1:38 PM, Kunal Mehta 
> wrote:
> >>>
> >>> Hi,
> >>>
> >>> On 2020-07-09 13:15, Dan Garry (Deskana) wrote:
>  Which cloud provider would you recommend?
> >>>
> >>> Wikimedia Cloud Services, which incidentally, has the fastest network
> >>> connection to Wikimedia sites by virtue of it being hosted *inside* the
> >>> cluster.
> >>>
> >>> -- Legoktm
> >>>
> >>> ___
> >>> 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 

Re: [Wikimedia-l] Paid API?

2020-07-23 Thread Victoria Coleman
Rupert,

My comment below referred to the point Kunal made about hosting should the 
movement decide (and it is a movement decision in my view) to go forward with a 
paid API. There is a healthy debate as you point out about the wisdom or 
otherwise of doing so. But should a decision be made to go forward, I believe 
that the hosting can be done on WMF clusters run by the Cloud Services team to 
avoid putting our content on 3rd party commercial services. While I was on 
staff, and I don’t think this has changed since my departure, the preference 
was to maintain control of content - including accessing it  - internally to 
protect movement privacy. If I had a penny for every time I got an offer of 
“free” hosting from AWS and others, my penny jar would be overflowing!

All the best,

Victoria

> On Jul 22, 2020, at 12:50 AM, rupert THURNER  wrote:
> 
> victoria, discussions to monetize the wikipedia content in one or the other
> way are as old as wikipedia. some people say "why should i continue editing
> and supporting wikipedia in my free time, or donate money, attracted by the
> vision to make it available to all, without condition, when WMF starts
> selling parts of it?" while the others feel that wikipedia relying on
> donations only keeps them at a shoestring budget, which meanwhile grew to
> 100 million USD a year. up to now the discussion always ended with a
> similar result: wikipedia would loose more than it would gain, and the
> initiative stopped. why this time it would be different? even more so as
> this API idea was already there when sue gardner joined 10 or more years
> ago. but maybe it becomes a good idea over time if it is brought up often
> enough and the environment changes. in 20 years or so, when the wikipedia
> content is auto-generated, auto-translated and WMF has no employees any
> more and no need of voluntary work this for sure would work.
> 
> rupert
> 
> 
> On Mon, Jul 20, 2020 at 9:19 PM Victoria Coleman <
> vstavridoucole...@gmail.com> wrote:
> 
>> +1 Kunal! The WMF Cloud Services team can totally provide the needed
>> support. The Foundation would have to invest them to build up the team
>> which is over stretched but that should easily pay for itself as revenue
>> starts flowing in from the paid API.
>> 
>> Victoria
>> 
>>> On Jul 9, 2020, at 1:38 PM, Kunal Mehta  wrote:
>>> 
>>> Hi,
>>> 
>>> On 2020-07-09 13:15, Dan Garry (Deskana) wrote:
 Which cloud provider would you recommend?
>>> 
>>> Wikimedia Cloud Services, which incidentally, has the fastest network
>>> connection to Wikimedia sites by virtue of it being hosted *inside* the
>>> cluster.
>>> 
>>> -- Legoktm
>>> 
>>> ___
>>> 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, 
> 


___
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] Paid API?

2020-07-22 Thread Samuel Klein
+1 This sounds like an ideal approach. !

Else: surprised that noone mentioned public cloud options running on
OpenStack. Is there no obvious place to start there?



On Mon., Jul. 20, 2020, 3:19 p.m. Victoria Coleman, <
vstavridoucole...@gmail.com> wrote:

> +1 Kunal! The WMF Cloud Services team can totally provide the needed
> support. The Foundation would have to invest them to build up the team
> which is over stretched but that should easily pay for itself as revenue
> starts flowing in from the paid API.
>
> Victoria
>
> > On Jul 9, 2020, at 1:38 PM, Kunal Mehta  wrote:
> >
> > Hi,
> >
> > On 2020-07-09 13:15, Dan Garry (Deskana) wrote:
> >> Which cloud provider would you recommend?
> >
> > Wikimedia Cloud Services, which incidentally, has the fastest network
> > connection to Wikimedia sites by virtue of it being hosted *inside* the
> > cluster.
> >
> > -- Legoktm
> >
> > ___
> > 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] Paid API?

2020-07-22 Thread rupert THURNER
victoria, discussions to monetize the wikipedia content in one or the other
way are as old as wikipedia. some people say "why should i continue editing
and supporting wikipedia in my free time, or donate money, attracted by the
vision to make it available to all, without condition, when WMF starts
selling parts of it?" while the others feel that wikipedia relying on
donations only keeps them at a shoestring budget, which meanwhile grew to
100 million USD a year. up to now the discussion always ended with a
similar result: wikipedia would loose more than it would gain, and the
initiative stopped. why this time it would be different? even more so as
this API idea was already there when sue gardner joined 10 or more years
ago. but maybe it becomes a good idea over time if it is brought up often
enough and the environment changes. in 20 years or so, when the wikipedia
content is auto-generated, auto-translated and WMF has no employees any
more and no need of voluntary work this for sure would work.

rupert


On Mon, Jul 20, 2020 at 9:19 PM Victoria Coleman <
vstavridoucole...@gmail.com> wrote:

> +1 Kunal! The WMF Cloud Services team can totally provide the needed
> support. The Foundation would have to invest them to build up the team
> which is over stretched but that should easily pay for itself as revenue
> starts flowing in from the paid API.
>
> Victoria
>
> > On Jul 9, 2020, at 1:38 PM, Kunal Mehta  wrote:
> >
> > Hi,
> >
> > On 2020-07-09 13:15, Dan Garry (Deskana) wrote:
> >> Which cloud provider would you recommend?
> >
> > Wikimedia Cloud Services, which incidentally, has the fastest network
> > connection to Wikimedia sites by virtue of it being hosted *inside* the
> > cluster.
> >
> > -- Legoktm
> >
> > ___
> > 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] Paid API?

2020-07-20 Thread Victoria Coleman
+1 Kunal! The WMF Cloud Services team can totally provide the needed support. 
The Foundation would have to invest them to build up the team which is over 
stretched but that should easily pay for itself as revenue starts flowing in 
from the paid API.

Victoria

> On Jul 9, 2020, at 1:38 PM, Kunal Mehta  wrote:
> 
> Hi,
> 
> On 2020-07-09 13:15, Dan Garry (Deskana) wrote:
>> Which cloud provider would you recommend? 
> 
> Wikimedia Cloud Services, which incidentally, has the fastest network
> connection to Wikimedia sites by virtue of it being hosted *inside* the
> cluster.
> 
> -- Legoktm
> 
> ___
> 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] Paid API?

2020-07-09 Thread Kunal Mehta
Hi,

On 2020-07-09 13:15, Dan Garry (Deskana) wrote:
> Which cloud provider would you recommend? 

Wikimedia Cloud Services, which incidentally, has the fastest network
connection to Wikimedia sites by virtue of it being hosted *inside* the
cluster.

-- Legoktm



signature.asc
Description: OpenPGP digital signature
___
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] Paid API?

2020-07-09 Thread David Gerard
All cloud providers are approximately level in evil. The way we break
it down at my day job is:

* AWS: when you want it to work and want customer service
* Microsoft: when you hate yourself, you're running Windows or both
* Google: when you want zero customer service ever under any circumstances
* Ali: when you're serving in China
* Oracle: lol no, not under any circumstances are we signing up with
Oracle again for anything

My personal server is at Hetzner, which is cheaper than AWS with less
services - but that's a very bespoke box, not managed cattle in a
server farm.

tl;dr if we're going to use cloud at all rather than our own cloud,
AWS is as good as any and better technically.


- d.



On Thu, 9 Jul 2020 at 21:16, Dan Garry (Deskana)  wrote:
>
> On Thu, 9 Jul 2020 at 18:20, Amir Sarabadani  wrote:
>
> > * I find it ethically wrong to use AWS, even if you can't host it in WMF
> > for legal reasons, why not another cloud provider.
>
>
> Which cloud provider would you recommend? Popular alternatives to AWS
> include GCP (by Google, who unscrupulously harvest user data and sell it
> for profit) and Azure (by Microsoft who arguably owe their position in the
> market due to numerous anti-competitive practices for which they have
> fought, and lost, numerous lawsuits). In addition to that, there are
> numerous other factors to consider, such as cost (we should be responsible
> with donor money), and environmental impact of the hosting choice in
> question. My point is, there is no objectively correct ethical choice.
>
> There's also numerous other factors to take into account in addition to
> ethics. There are different feature sets that each cloud provider offers;
> as an example, I recently did a competitive analysis of different
> cloud-hosted container registry providers, and was surprised at the large
> number of feature differences in each provider, even for something as
> relatively straightforward as a container registry, even between ECR and
> GKE. Engineering productivity is an important factor too.
>
> From a project management perspective, it seems to me that the most prudent
> thing to do is to choose a solution for prototyping rather than spending an
> excessive amount of time analysing it. After all, time is money. I would be
> concerned by the choice of AWS if this were in any way a permanent choice,
> but the docs specifically mention that AWS is being used for ease of
> prototyping, and that the long-term solution is presently undetermined.
>
> Dan
> ___
> 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] Paid API?

2020-07-09 Thread Dan Garry (Deskana)
On Thu, 9 Jul 2020 at 21:15, Dan Garry (Deskana)  wrote:

> ECR and GKE.
>

Correction: I meant GCR, not GKE.

Dan
___
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] Paid API?

2020-07-09 Thread Dan Garry (Deskana)
On Thu, 9 Jul 2020 at 18:20, Amir Sarabadani  wrote:

> * I find it ethically wrong to use AWS, even if you can't host it in WMF
> for legal reasons, why not another cloud provider.


Which cloud provider would you recommend? Popular alternatives to AWS
include GCP (by Google, who unscrupulously harvest user data and sell it
for profit) and Azure (by Microsoft who arguably owe their position in the
market due to numerous anti-competitive practices for which they have
fought, and lost, numerous lawsuits). In addition to that, there are
numerous other factors to consider, such as cost (we should be responsible
with donor money), and environmental impact of the hosting choice in
question. My point is, there is no objectively correct ethical choice.

There's also numerous other factors to take into account in addition to
ethics. There are different feature sets that each cloud provider offers;
as an example, I recently did a competitive analysis of different
cloud-hosted container registry providers, and was surprised at the large
number of feature differences in each provider, even for something as
relatively straightforward as a container registry, even between ECR and
GKE. Engineering productivity is an important factor too.

From a project management perspective, it seems to me that the most prudent
thing to do is to choose a solution for prototyping rather than spending an
excessive amount of time analysing it. After all, time is money. I would be
concerned by the choice of AWS if this were in any way a permanent choice,
but the docs specifically mention that AWS is being used for ease of
prototyping, and that the long-term solution is presently undetermined.

Dan
___
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] Paid API?

2020-07-09 Thread Joseph Seddon
Hey all.

I'll reply to some of the more finer legal details tomorrow but to be clear
the repo will be made available publicly and the code base will be open
sourced and based on open source tech.

Seddon

On Thu, 9 Jul 2020, 19:06 Benjamin Ikuta,  wrote:

>
>
> I agree, the lack of transparency is quite concerning, as is the use of
> AWS.
>
> I sure hope we're not going to be producing closed source code!
>
>
>
> On Jul 9, 2020, at 10:19 AM, Amir Sarabadani  wrote:
>
> > Thanks Joseph for the links. It's more clear now.
> >
> > I think I need to clarify something: I'm not against asking the big corps
> > to pay. If they are using a significant amount of our computational
> > resources (=donors money) to make even more money, they should pay. And
> > thank you for improving the movement's financial security. I don't oppose
> > the general idea.
> >
> > That being said, what worries me are the details:
> > * WMF is creating a company (LLC) and contracts that company, this means
> > less transparency. This is the first time I think in the history of the
> > foundation AFAIK that WMF is creating a company for legal reasons (I'm
> > sorry if I missed anything).
> > * That company is contracting another company for engineering work (even
> > less transparency). We have lots of engineering resources at WMF.
> > * As the result, for the first time, code produced by donors money is
> > closed source and inaccessible to public (or at least I couldn't find the
> > code linked anywhere)
> > * I find it ethically wrong to use AWS, even if you can't host it in WMF
> > for legal reasons, why not another cloud provider.
> > * There wasn't a period for giving feedback for example about the choice
> of
> > cloud provider or anything, suddenly it came out ready. The rumors about
> it
> > have been going around for months.
> > * This has not been communicated properly to the community, I find this
> > lack of communication and transparency concerning and insulting.
> >
> > Hope what I'm saying here makes sense.
> >
> > On Thu, Jul 9, 2020 at 7:02 PM Todd Allen  wrote:
> >
> >> I tend to agree with this. I'm one of the first to criticize WMF when
> they
> >> deserve it (I wish they didn't as often!), but I see nothing wrong with
> >> consumers of huge amounts of data being asked to chip in to cover the
> costs
> >> of providing it. That is, of course, provided that there is never any
> fee
> >> for use of the API for users of data in regular amounts, but every plan
> >> I've seen thus far accommodates that.
> >>
> >> Todd
> >>
> >> On Thu, Jul 9, 2020 at 7:15 AM Ad Huikeshoven 
> wrote:
> >>
> >>> Hi,
> >>>
> >>> Great news: the WMF is going to charge the tech giants for using the
> API
> >>> millions of times each day. Nothing in the free licenses we use
> obligate
> >> us
> >>> (that is we in our movement) to provide an API for free as in beer. It
> is
> >>> part of KAAS: Knowledge As A Service, part of the strategic direction
> >>> chosen in 2017.
> >>>
> >>> Thanks for your understanding,
> >>>
> >>> Ad Huikeshoven
> >>>
> >>> On Sun, Jun 14, 2020 at 8:33 PM Amir Sarabadani 
> >>> wrote:
> >>>
>  Hello,
>  Today I stumbled upon this public phabricator ticket [1] created by
> >>> someone
>  from WMF starting with:
>  "My team is creating bi-weekly HTML Dumps for all of the wikis, except
> >>> for
>  wikidata as part of the paid API project."
> 
>  I have so many questions:
>  - What is the "paid API" project? Are we planning to make money out of
> >>> our
>  API? Now are we selling our dumps?
>  - If so, why is this not communicated before? Why are we kept in the
> >>> dark?
>  - Does the board know and approve it?
>  - How is this going to align with our core values like openness and
>  transparency?
>  - The ticket implicitly says these are going to be stored on AWS ("S3
>  bucket"). Is this thought through? Specially the ethical problems of
>  feeding Jeff Bezos' empire? (If you have seen this episode of Hasan
>  Minhaj's on ethical issues of using AWS [2]). Why can't we do/host
> this
> >>> on
>  Wikimedia infrastructure? Has this been evaluated?
>  - Why is the community not consulted about this?
> 
>  Maybe I missed announcements, consultations or anything, forgive me
> for
> >>> my
>  ignorance. Any pointers is enough. I also understand diversifying our
>  revenue is a good tool for rainy days but a consultation with the
> >>> community
>  wouldn't be too bad.
> 
>  [1]: https://phabricator.wikimedia.org/T254275
>  [2]: https://www.youtube.com/watch?v=5maXvZ5fyQY
> 
>  Best
>  --
>  Amir (he/him)
>  ___
>  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: 

Re: [Wikimedia-l] Paid API?

2020-07-09 Thread Jan Ainali
Let me just flip the perspective. The tech giants are leveraging their
resources to serve the knowledge we create to even more users. In a way,
they are partly furthering our mission. So rather than solely using our
resources as a cost, it could instead be viewed upon as a multiplier. Now
this is just a hypothesis that I have no facts to back up, but it would be
nice if this project had this factor as a part of the analysis, if only to
prove it wrong.

To boil it down: are we sharing the knowledge to fewer or more people due
to the tech giants?
If it is fewer, they should just be stopped rather than asked to pay.
If it is more, there is an argument for allowing it to incur costs, this is
after all our mission. Of course, if the cost is cannibalizing our capacity
to serve knowledge to others then some more complex evaluation needs to be
done. As far as I am aware no such analysis has been published. If I am
mistaken, a link would be appreciated.

Jan Ainali

Den tors 9 juli 2020 kl 20:06 skrev Benjamin Ikuta :

>
>
> I agree, the lack of transparency is quite concerning, as is the use of
> AWS.
>
> I sure hope we're not going to be producing closed source code!
>
>
>
> On Jul 9, 2020, at 10:19 AM, Amir Sarabadani  wrote:
>
> > Thanks Joseph for the links. It's more clear now.
> >
> > I think I need to clarify something: I'm not against asking the big corps
> > to pay. If they are using a significant amount of our computational
> > resources (=donors money) to make even more money, they should pay. And
> > thank you for improving the movement's financial security. I don't oppose
> > the general idea.
> >
> > That being said, what worries me are the details:
> > * WMF is creating a company (LLC) and contracts that company, this means
> > less transparency. This is the first time I think in the history of the
> > foundation AFAIK that WMF is creating a company for legal reasons (I'm
> > sorry if I missed anything).
> > * That company is contracting another company for engineering work (even
> > less transparency). We have lots of engineering resources at WMF.
> > * As the result, for the first time, code produced by donors money is
> > closed source and inaccessible to public (or at least I couldn't find the
> > code linked anywhere)
> > * I find it ethically wrong to use AWS, even if you can't host it in WMF
> > for legal reasons, why not another cloud provider.
> > * There wasn't a period for giving feedback for example about the choice
> of
> > cloud provider or anything, suddenly it came out ready. The rumors about
> it
> > have been going around for months.
> > * This has not been communicated properly to the community, I find this
> > lack of communication and transparency concerning and insulting.
> >
> > Hope what I'm saying here makes sense.
> >
> > On Thu, Jul 9, 2020 at 7:02 PM Todd Allen  wrote:
> >
> >> I tend to agree with this. I'm one of the first to criticize WMF when
> they
> >> deserve it (I wish they didn't as often!), but I see nothing wrong with
> >> consumers of huge amounts of data being asked to chip in to cover the
> costs
> >> of providing it. That is, of course, provided that there is never any
> fee
> >> for use of the API for users of data in regular amounts, but every plan
> >> I've seen thus far accommodates that.
> >>
> >> Todd
> >>
> >> On Thu, Jul 9, 2020 at 7:15 AM Ad Huikeshoven 
> wrote:
> >>
> >>> Hi,
> >>>
> >>> Great news: the WMF is going to charge the tech giants for using the
> API
> >>> millions of times each day. Nothing in the free licenses we use
> obligate
> >> us
> >>> (that is we in our movement) to provide an API for free as in beer. It
> is
> >>> part of KAAS: Knowledge As A Service, part of the strategic direction
> >>> chosen in 2017.
> >>>
> >>> Thanks for your understanding,
> >>>
> >>> Ad Huikeshoven
> >>>
> >>> On Sun, Jun 14, 2020 at 8:33 PM Amir Sarabadani 
> >>> wrote:
> >>>
>  Hello,
>  Today I stumbled upon this public phabricator ticket [1] created by
> >>> someone
>  from WMF starting with:
>  "My team is creating bi-weekly HTML Dumps for all of the wikis, except
> >>> for
>  wikidata as part of the paid API project."
> 
>  I have so many questions:
>  - What is the "paid API" project? Are we planning to make money out of
> >>> our
>  API? Now are we selling our dumps?
>  - If so, why is this not communicated before? Why are we kept in the
> >>> dark?
>  - Does the board know and approve it?
>  - How is this going to align with our core values like openness and
>  transparency?
>  - The ticket implicitly says these are going to be stored on AWS ("S3
>  bucket"). Is this thought through? Specially the ethical problems of
>  feeding Jeff Bezos' empire? (If you have seen this episode of Hasan
>  Minhaj's on ethical issues of using AWS [2]). Why can't we do/host
> this
> >>> on
>  Wikimedia infrastructure? Has this been evaluated?
>  - Why is the community not consulted 

Re: [Wikimedia-l] Paid API?

2020-07-09 Thread Benjamin Ikuta


I agree, the lack of transparency is quite concerning, as is the use of AWS. 

I sure hope we're not going to be producing closed source code! 



On Jul 9, 2020, at 10:19 AM, Amir Sarabadani  wrote:

> Thanks Joseph for the links. It's more clear now.
> 
> I think I need to clarify something: I'm not against asking the big corps
> to pay. If they are using a significant amount of our computational
> resources (=donors money) to make even more money, they should pay. And
> thank you for improving the movement's financial security. I don't oppose
> the general idea.
> 
> That being said, what worries me are the details:
> * WMF is creating a company (LLC) and contracts that company, this means
> less transparency. This is the first time I think in the history of the
> foundation AFAIK that WMF is creating a company for legal reasons (I'm
> sorry if I missed anything).
> * That company is contracting another company for engineering work (even
> less transparency). We have lots of engineering resources at WMF.
> * As the result, for the first time, code produced by donors money is
> closed source and inaccessible to public (or at least I couldn't find the
> code linked anywhere)
> * I find it ethically wrong to use AWS, even if you can't host it in WMF
> for legal reasons, why not another cloud provider.
> * There wasn't a period for giving feedback for example about the choice of
> cloud provider or anything, suddenly it came out ready. The rumors about it
> have been going around for months.
> * This has not been communicated properly to the community, I find this
> lack of communication and transparency concerning and insulting.
> 
> Hope what I'm saying here makes sense.
> 
> On Thu, Jul 9, 2020 at 7:02 PM Todd Allen  wrote:
> 
>> I tend to agree with this. I'm one of the first to criticize WMF when they
>> deserve it (I wish they didn't as often!), but I see nothing wrong with
>> consumers of huge amounts of data being asked to chip in to cover the costs
>> of providing it. That is, of course, provided that there is never any fee
>> for use of the API for users of data in regular amounts, but every plan
>> I've seen thus far accommodates that.
>> 
>> Todd
>> 
>> On Thu, Jul 9, 2020 at 7:15 AM Ad Huikeshoven  wrote:
>> 
>>> Hi,
>>> 
>>> Great news: the WMF is going to charge the tech giants for using the API
>>> millions of times each day. Nothing in the free licenses we use obligate
>> us
>>> (that is we in our movement) to provide an API for free as in beer. It is
>>> part of KAAS: Knowledge As A Service, part of the strategic direction
>>> chosen in 2017.
>>> 
>>> Thanks for your understanding,
>>> 
>>> Ad Huikeshoven
>>> 
>>> On Sun, Jun 14, 2020 at 8:33 PM Amir Sarabadani 
>>> wrote:
>>> 
 Hello,
 Today I stumbled upon this public phabricator ticket [1] created by
>>> someone
 from WMF starting with:
 "My team is creating bi-weekly HTML Dumps for all of the wikis, except
>>> for
 wikidata as part of the paid API project."
 
 I have so many questions:
 - What is the "paid API" project? Are we planning to make money out of
>>> our
 API? Now are we selling our dumps?
 - If so, why is this not communicated before? Why are we kept in the
>>> dark?
 - Does the board know and approve it?
 - How is this going to align with our core values like openness and
 transparency?
 - The ticket implicitly says these are going to be stored on AWS ("S3
 bucket"). Is this thought through? Specially the ethical problems of
 feeding Jeff Bezos' empire? (If you have seen this episode of Hasan
 Minhaj's on ethical issues of using AWS [2]). Why can't we do/host this
>>> on
 Wikimedia infrastructure? Has this been evaluated?
 - Why is the community not consulted about this?
 
 Maybe I missed announcements, consultations or anything, forgive me for
>>> my
 ignorance. Any pointers is enough. I also understand diversifying our
 revenue is a good tool for rainy days but a consultation with the
>>> community
 wouldn't be too bad.
 
 [1]: https://phabricator.wikimedia.org/T254275
 [2]: https://www.youtube.com/watch?v=5maXvZ5fyQY
 
 Best
 --
 Amir (he/him)
 ___
 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] Paid API?

2020-07-09 Thread Pete Forsyth
Worth noting, for those who may not have been tracking this issue in the
media in recent years: CEO Katherine Maher has prominently and frequently
highlighted how big tech companies benefit from Wikipedia and Wikimedia
content, and that they pay little if anything for it. This shows up in many
places; perhaps Joseph can add to this list if I haven't picked the best
example:

* April Glaser: YouTube Is Adding Fact-Check Links for Videos on Topics
That Inspire Conspiracy Theories, August 14, 2018, Slate
https://slate.com/technology/2018/08/youtube-is-adding-fact-check-links-from-wikipedia-and-encyclopedia-britannica-for-videos-on-topics-that-inspire-conspiracy-theories.html
* And a number of tweets such as:
https://twitter.com/krmaher/status/1113394557830483969

-Pete
--
User:Peteforsyth

On Thu, Jul 9, 2020 at 10:20 AM Amir Sarabadani  wrote:

> Thanks Joseph for the links. It's more clear now.
>
> I think I need to clarify something: I'm not against asking the big corps
> to pay. If they are using a significant amount of our computational
> resources (=donors money) to make even more money, they should pay. And
> thank you for improving the movement's financial security. I don't oppose
> the general idea.
>
> That being said, what worries me are the details:
> * WMF is creating a company (LLC) and contracts that company, this means
> less transparency. This is the first time I think in the history of the
> foundation AFAIK that WMF is creating a company for legal reasons (I'm
> sorry if I missed anything).
> * That company is contracting another company for engineering work (even
> less transparency). We have lots of engineering resources at WMF.
> * As the result, for the first time, code produced by donors money is
> closed source and inaccessible to public (or at least I couldn't find the
> code linked anywhere)
> * I find it ethically wrong to use AWS, even if you can't host it in WMF
> for legal reasons, why not another cloud provider.
> * There wasn't a period for giving feedback for example about the choice of
> cloud provider or anything, suddenly it came out ready. The rumors about it
> have been going around for months.
> * This has not been communicated properly to the community, I find this
> lack of communication and transparency concerning and insulting.
>
> Hope what I'm saying here makes sense.
>
> On Thu, Jul 9, 2020 at 7:02 PM Todd Allen  wrote:
>
> > I tend to agree with this. I'm one of the first to criticize WMF when
> they
> > deserve it (I wish they didn't as often!), but I see nothing wrong with
> > consumers of huge amounts of data being asked to chip in to cover the
> costs
> > of providing it. That is, of course, provided that there is never any fee
> > for use of the API for users of data in regular amounts, but every plan
> > I've seen thus far accommodates that.
> >
> > Todd
> >
> > On Thu, Jul 9, 2020 at 7:15 AM Ad Huikeshoven 
> wrote:
> >
> > > Hi,
> > >
> > > Great news: the WMF is going to charge the tech giants for using the
> API
> > > millions of times each day. Nothing in the free licenses we use
> obligate
> > us
> > > (that is we in our movement) to provide an API for free as in beer. It
> is
> > > part of KAAS: Knowledge As A Service, part of the strategic direction
> > > chosen in 2017.
> > >
> > > Thanks for your understanding,
> > >
> > > Ad Huikeshoven
> > >
> > > On Sun, Jun 14, 2020 at 8:33 PM Amir Sarabadani 
> > > wrote:
> > >
> > > > Hello,
> > > > Today I stumbled upon this public phabricator ticket [1] created by
> > > someone
> > > > from WMF starting with:
> > > > "My team is creating bi-weekly HTML Dumps for all of the wikis,
> except
> > > for
> > > > wikidata as part of the paid API project."
> > > >
> > > > I have so many questions:
> > > >  - What is the "paid API" project? Are we planning to make money out
> of
> > > our
> > > > API? Now are we selling our dumps?
> > > >  - If so, why is this not communicated before? Why are we kept in the
> > > dark?
> > > >  - Does the board know and approve it?
> > > >  - How is this going to align with our core values like openness and
> > > > transparency?
> > > >  - The ticket implicitly says these are going to be stored on AWS
> ("S3
> > > > bucket"). Is this thought through? Specially the ethical problems of
> > > > feeding Jeff Bezos' empire? (If you have seen this episode of Hasan
> > > > Minhaj's on ethical issues of using AWS [2]). Why can't we do/host
> this
> > > on
> > > > Wikimedia infrastructure? Has this been evaluated?
> > > >  - Why is the community not consulted about this?
> > > >
> > > > Maybe I missed announcements, consultations or anything, forgive me
> for
> > > my
> > > > ignorance. Any pointers is enough. I also understand diversifying our
> > > > revenue is a good tool for rainy days but a consultation with the
> > > community
> > > > wouldn't be too bad.
> > > >
> > > > [1]: https://phabricator.wikimedia.org/T254275
> > > > [2]: https://www.youtube.com/watch?v=5maXvZ5fyQY
> > > >
> 

Re: [Wikimedia-l] Paid API?

2020-07-09 Thread Amir Sarabadani
Thanks Joseph for the links. It's more clear now.

I think I need to clarify something: I'm not against asking the big corps
to pay. If they are using a significant amount of our computational
resources (=donors money) to make even more money, they should pay. And
thank you for improving the movement's financial security. I don't oppose
the general idea.

That being said, what worries me are the details:
* WMF is creating a company (LLC) and contracts that company, this means
less transparency. This is the first time I think in the history of the
foundation AFAIK that WMF is creating a company for legal reasons (I'm
sorry if I missed anything).
* That company is contracting another company for engineering work (even
less transparency). We have lots of engineering resources at WMF.
* As the result, for the first time, code produced by donors money is
closed source and inaccessible to public (or at least I couldn't find the
code linked anywhere)
* I find it ethically wrong to use AWS, even if you can't host it in WMF
for legal reasons, why not another cloud provider.
* There wasn't a period for giving feedback for example about the choice of
cloud provider or anything, suddenly it came out ready. The rumors about it
have been going around for months.
* This has not been communicated properly to the community, I find this
lack of communication and transparency concerning and insulting.

Hope what I'm saying here makes sense.

On Thu, Jul 9, 2020 at 7:02 PM Todd Allen  wrote:

> I tend to agree with this. I'm one of the first to criticize WMF when they
> deserve it (I wish they didn't as often!), but I see nothing wrong with
> consumers of huge amounts of data being asked to chip in to cover the costs
> of providing it. That is, of course, provided that there is never any fee
> for use of the API for users of data in regular amounts, but every plan
> I've seen thus far accommodates that.
>
> Todd
>
> On Thu, Jul 9, 2020 at 7:15 AM Ad Huikeshoven  wrote:
>
> > Hi,
> >
> > Great news: the WMF is going to charge the tech giants for using the API
> > millions of times each day. Nothing in the free licenses we use obligate
> us
> > (that is we in our movement) to provide an API for free as in beer. It is
> > part of KAAS: Knowledge As A Service, part of the strategic direction
> > chosen in 2017.
> >
> > Thanks for your understanding,
> >
> > Ad Huikeshoven
> >
> > On Sun, Jun 14, 2020 at 8:33 PM Amir Sarabadani 
> > wrote:
> >
> > > Hello,
> > > Today I stumbled upon this public phabricator ticket [1] created by
> > someone
> > > from WMF starting with:
> > > "My team is creating bi-weekly HTML Dumps for all of the wikis, except
> > for
> > > wikidata as part of the paid API project."
> > >
> > > I have so many questions:
> > >  - What is the "paid API" project? Are we planning to make money out of
> > our
> > > API? Now are we selling our dumps?
> > >  - If so, why is this not communicated before? Why are we kept in the
> > dark?
> > >  - Does the board know and approve it?
> > >  - How is this going to align with our core values like openness and
> > > transparency?
> > >  - The ticket implicitly says these are going to be stored on AWS ("S3
> > > bucket"). Is this thought through? Specially the ethical problems of
> > > feeding Jeff Bezos' empire? (If you have seen this episode of Hasan
> > > Minhaj's on ethical issues of using AWS [2]). Why can't we do/host this
> > on
> > > Wikimedia infrastructure? Has this been evaluated?
> > >  - Why is the community not consulted about this?
> > >
> > > Maybe I missed announcements, consultations or anything, forgive me for
> > my
> > > ignorance. Any pointers is enough. I also understand diversifying our
> > > revenue is a good tool for rainy days but a consultation with the
> > community
> > > wouldn't be too bad.
> > >
> > > [1]: https://phabricator.wikimedia.org/T254275
> > > [2]: https://www.youtube.com/watch?v=5maXvZ5fyQY
> > >
> > > Best
> > > --
> > > Amir (he/him)
> > > ___
> > > 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
> 

Re: [Wikimedia-l] Paid API?

2020-07-09 Thread Todd Allen
I tend to agree with this. I'm one of the first to criticize WMF when they
deserve it (I wish they didn't as often!), but I see nothing wrong with
consumers of huge amounts of data being asked to chip in to cover the costs
of providing it. That is, of course, provided that there is never any fee
for use of the API for users of data in regular amounts, but every plan
I've seen thus far accommodates that.

Todd

On Thu, Jul 9, 2020 at 7:15 AM Ad Huikeshoven  wrote:

> Hi,
>
> Great news: the WMF is going to charge the tech giants for using the API
> millions of times each day. Nothing in the free licenses we use obligate us
> (that is we in our movement) to provide an API for free as in beer. It is
> part of KAAS: Knowledge As A Service, part of the strategic direction
> chosen in 2017.
>
> Thanks for your understanding,
>
> Ad Huikeshoven
>
> On Sun, Jun 14, 2020 at 8:33 PM Amir Sarabadani 
> wrote:
>
> > Hello,
> > Today I stumbled upon this public phabricator ticket [1] created by
> someone
> > from WMF starting with:
> > "My team is creating bi-weekly HTML Dumps for all of the wikis, except
> for
> > wikidata as part of the paid API project."
> >
> > I have so many questions:
> >  - What is the "paid API" project? Are we planning to make money out of
> our
> > API? Now are we selling our dumps?
> >  - If so, why is this not communicated before? Why are we kept in the
> dark?
> >  - Does the board know and approve it?
> >  - How is this going to align with our core values like openness and
> > transparency?
> >  - The ticket implicitly says these are going to be stored on AWS ("S3
> > bucket"). Is this thought through? Specially the ethical problems of
> > feeding Jeff Bezos' empire? (If you have seen this episode of Hasan
> > Minhaj's on ethical issues of using AWS [2]). Why can't we do/host this
> on
> > Wikimedia infrastructure? Has this been evaluated?
> >  - Why is the community not consulted about this?
> >
> > Maybe I missed announcements, consultations or anything, forgive me for
> my
> > ignorance. Any pointers is enough. I also understand diversifying our
> > revenue is a good tool for rainy days but a consultation with the
> community
> > wouldn't be too bad.
> >
> > [1]: https://phabricator.wikimedia.org/T254275
> > [2]: https://www.youtube.com/watch?v=5maXvZ5fyQY
> >
> > Best
> > --
> > Amir (he/him)
> > ___
> > 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] Paid API?

2020-07-09 Thread Ad Huikeshoven
Hi,

Great news: the WMF is going to charge the tech giants for using the API
millions of times each day. Nothing in the free licenses we use obligate us
(that is we in our movement) to provide an API for free as in beer. It is
part of KAAS: Knowledge As A Service, part of the strategic direction
chosen in 2017.

Thanks for your understanding,

Ad Huikeshoven

On Sun, Jun 14, 2020 at 8:33 PM Amir Sarabadani  wrote:

> Hello,
> Today I stumbled upon this public phabricator ticket [1] created by someone
> from WMF starting with:
> "My team is creating bi-weekly HTML Dumps for all of the wikis, except for
> wikidata as part of the paid API project."
>
> I have so many questions:
>  - What is the "paid API" project? Are we planning to make money out of our
> API? Now are we selling our dumps?
>  - If so, why is this not communicated before? Why are we kept in the dark?
>  - Does the board know and approve it?
>  - How is this going to align with our core values like openness and
> transparency?
>  - The ticket implicitly says these are going to be stored on AWS ("S3
> bucket"). Is this thought through? Specially the ethical problems of
> feeding Jeff Bezos' empire? (If you have seen this episode of Hasan
> Minhaj's on ethical issues of using AWS [2]). Why can't we do/host this on
> Wikimedia infrastructure? Has this been evaluated?
>  - Why is the community not consulted about this?
>
> Maybe I missed announcements, consultations or anything, forgive me for my
> ignorance. Any pointers is enough. I also understand diversifying our
> revenue is a good tool for rainy days but a consultation with the community
> wouldn't be too bad.
>
> [1]: https://phabricator.wikimedia.org/T254275
> [2]: https://www.youtube.com/watch?v=5maXvZ5fyQY
>
> Best
> --
> Amir (he/him)
> ___
> 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] Paid API?

2020-07-09 Thread Mohammed Bachounda
Yes it's - donation not working for me

* Mohammed Bachounda *
Leader Wikimedia Algeria UG
  [image: Thumbnail for version as of 13:48, 19 April 2020]


On Thu, Jul 9, 2020 at 2:20 PM William Chan  wrote:

> It's don...@wikimedia.org.
>
> On Thu, Jul 9, 2020, 19:05 Mohammed Bachounda  wrote:
>
> > Hello,
> > Why i'm recieving this message :
> > Message not delivered
> > There was a problem delivering your message to *don...@wikimedia.com*.
> See
> > the technical details below.
> >
> > * Mohammed Bachounda *
> > Leader Wikimedia Algeria UG
> >   [image: Thumbnail for version as of 13:48, 19 April 2020]
> >
> >
> > On Thu, Jul 9, 2020 at 2:05 AM Joseph Seddon 
> > wrote:
> >
> > > Hey all,
> > >
> > > Apologies for the delay. Two overview pages covering the technical and
> > > business side of the project:
> > >
> > > https://meta.wikimedia.org/wiki/OKAPI
> > > https://www.mediawiki.org/wiki/OKAPI
> > >
> > > Regards
> > > Seddon
> > >
> > > On Tue, Jun 16, 2020 at 10:29 PM Samuel Klein 
> wrote:
> > >
> > > > A well-provisioned bulk api has been missing for some time.  Thanks
> for
> > > > working on this.  And clearing up the recommended way for WP content
> to
> > > > appear and be linked in third-party searches and infoboxes is
> important
> > > --
> > > > the sort of thing that an internal policy (and way to subscribe to
> > feeds)
> > > > can help.
> > > >
> > > > I do hope we can host this on WM or openstack infrastructure, and do
> it
> > > in
> > > > a way that expands and improves the solid existing frameworks for
> HTML
> > > > dumps :)
> > > >
> > > > S
> > > >
> > > >
> > > > On Tue, Jun 16, 2020 at 8:43 AM Chris Keating <
> > > chriskeatingw...@gmail.com>
> > > > wrote:
> > > >
> > > > > It's interesting that of all the strategy recommendations, two are
> so
> > > far
> > > > > being implemented. One is the Universal Code of Conduct, which has
> at
> > > > least
> > > > > had plenty of discussion and publicity, that even precedes the
> > strategy
> > > > > process. The other is this, which hasn't been particularly
> prominent
> > > > > before, but the WMF seems to have a team working on it just a
> couple
> > of
> > > > > weeks after the final recommendations were published.
> > > > >
> > > > > So while doing this is one of the strategy recommendations, it
> > doesn't
> > > > seem
> > > > > that is is now happening *because of* the strategy
> > recommendations
> > > > >
> > > > > Chris
> > > > >
> > > > > On Mon, Jun 15, 2020 at 10:46 AM Gergő Tisza 
> > wrote:
> > > > >
> > > > > > You can find some more discussion at
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://meta.wikimedia.org/wiki/Talk:Strategy/Wikimedia_movement/2018-20/Recommendations/Iteration_3/Promote_Sustainability_and_Resilience#Freemium
> > > > > >
> > > > > > As I mentioned there, the premise of the recommendation is that
> the
> > > > > > movement needs new revenue sources; in part because the 2030
> > strategy
> > > > is
> > > > > > ambitious and requires a significant increase in resources, in
> part
> > > > > because
> > > > > > our current lack of diversity (about 40% of the movement's budget
> > is
> > > > from
> > > > > > donations through website banners, and another 40% from past
> > banners
> > > > via
> > > > > > email campaigns and such) is a strategic risk because those
> > donations
> > > > can
> > > > > > be disrupted by various social or technical trends. For example,
> > > large
> > > > > tech
> > > > > > companies which are the starting point of people's internet
> > > experience
> > > > > > (such as Facebook or Google) clearly have aspirations to become
> the
> > > end
> > > > > > point as well - they try to ingest and display to their users
> > > directly
> > > > as
> > > > > > much online content as they can. Today, that's not a whole lot of
> > > > content
> > > > > > (you might see fragments of Wikipedia infoboxes in Google's
> > > "knowledge
> > > > > > panel", for example, but nothing resembling an encyclopedia
> > article).
> > > > Ten
> > > > > > years from now, that might be different, and so we need to
> consider
> > > how
> > > > > we
> > > > > > would sustain ourselves in such a world - in terms of revenue,
> and
> > > also
> > > > > in
> > > > > > terms of people (how would new editors join the project, if most
> > > people
> > > > > > interacted with our content not via our website, but interfaces
> > > > provided
> > > > > by
> > > > > > big tech companies where there is no edit button?).
> > > > > >
> > > > > > The new API project aims to do that, both in the sense of making
> it
> > > > > > possible to have more equitable arrangements with bulk reusers of
> > our
> > > > > > content (who make lots of money with it), and by making it easier
> > to
> > > > > reuse
> > > > > > content in ways that align with our movement's values (currently,
> > if
> > > > you
> > > > > > reuse Wikipedia content in your own 

Re: [Wikimedia-l] Paid API?

2020-07-09 Thread William Chan
It's don...@wikimedia.org.

On Thu, Jul 9, 2020, 19:05 Mohammed Bachounda  wrote:

> Hello,
> Why i'm recieving this message :
> Message not delivered
> There was a problem delivering your message to *don...@wikimedia.com*. See
> the technical details below.
>
> * Mohammed Bachounda *
> Leader Wikimedia Algeria UG
>   [image: Thumbnail for version as of 13:48, 19 April 2020]
>
>
> On Thu, Jul 9, 2020 at 2:05 AM Joseph Seddon 
> wrote:
>
> > Hey all,
> >
> > Apologies for the delay. Two overview pages covering the technical and
> > business side of the project:
> >
> > https://meta.wikimedia.org/wiki/OKAPI
> > https://www.mediawiki.org/wiki/OKAPI
> >
> > Regards
> > Seddon
> >
> > On Tue, Jun 16, 2020 at 10:29 PM Samuel Klein  wrote:
> >
> > > A well-provisioned bulk api has been missing for some time.  Thanks for
> > > working on this.  And clearing up the recommended way for WP content to
> > > appear and be linked in third-party searches and infoboxes is important
> > --
> > > the sort of thing that an internal policy (and way to subscribe to
> feeds)
> > > can help.
> > >
> > > I do hope we can host this on WM or openstack infrastructure, and do it
> > in
> > > a way that expands and improves the solid existing frameworks for HTML
> > > dumps :)
> > >
> > > S
> > >
> > >
> > > On Tue, Jun 16, 2020 at 8:43 AM Chris Keating <
> > chriskeatingw...@gmail.com>
> > > wrote:
> > >
> > > > It's interesting that of all the strategy recommendations, two are so
> > far
> > > > being implemented. One is the Universal Code of Conduct, which has at
> > > least
> > > > had plenty of discussion and publicity, that even precedes the
> strategy
> > > > process. The other is this, which hasn't been particularly prominent
> > > > before, but the WMF seems to have a team working on it just a couple
> of
> > > > weeks after the final recommendations were published.
> > > >
> > > > So while doing this is one of the strategy recommendations, it
> doesn't
> > > seem
> > > > that is is now happening *because of* the strategy
> recommendations
> > > >
> > > > Chris
> > > >
> > > > On Mon, Jun 15, 2020 at 10:46 AM Gergő Tisza 
> wrote:
> > > >
> > > > > You can find some more discussion at
> > > > >
> > > > >
> > > >
> > >
> >
> https://meta.wikimedia.org/wiki/Talk:Strategy/Wikimedia_movement/2018-20/Recommendations/Iteration_3/Promote_Sustainability_and_Resilience#Freemium
> > > > >
> > > > > As I mentioned there, the premise of the recommendation is that the
> > > > > movement needs new revenue sources; in part because the 2030
> strategy
> > > is
> > > > > ambitious and requires a significant increase in resources, in part
> > > > because
> > > > > our current lack of diversity (about 40% of the movement's budget
> is
> > > from
> > > > > donations through website banners, and another 40% from past
> banners
> > > via
> > > > > email campaigns and such) is a strategic risk because those
> donations
> > > can
> > > > > be disrupted by various social or technical trends. For example,
> > large
> > > > tech
> > > > > companies which are the starting point of people's internet
> > experience
> > > > > (such as Facebook or Google) clearly have aspirations to become the
> > end
> > > > > point as well - they try to ingest and display to their users
> > directly
> > > as
> > > > > much online content as they can. Today, that's not a whole lot of
> > > content
> > > > > (you might see fragments of Wikipedia infoboxes in Google's
> > "knowledge
> > > > > panel", for example, but nothing resembling an encyclopedia
> article).
> > > Ten
> > > > > years from now, that might be different, and so we need to consider
> > how
> > > > we
> > > > > would sustain ourselves in such a world - in terms of revenue, and
> > also
> > > > in
> > > > > terms of people (how would new editors join the project, if most
> > people
> > > > > interacted with our content not via our website, but interfaces
> > > provided
> > > > by
> > > > > big tech companies where there is no edit button?).
> > > > >
> > > > > The new API project aims to do that, both in the sense of making it
> > > > > possible to have more equitable arrangements with bulk reusers of
> our
> > > > > content (who make lots of money with it), and by making it easier
> to
> > > > reuse
> > > > > content in ways that align with our movement's values (currently,
> if
> > > you
> > > > > reuse Wikipedia content in your own website or application, and
> want
> > to
> > > > > provide your users with information about the licensing or
> provenance
> > > of
> > > > > that content, or allow them to contribute, the tools we provide for
> > > that
> > > > > are third rate at best). As the recommendation mentions, erecting
> > > > > unintentional barriers to small-scale or non-commercial reusers was
> > > very
> > > > > much a concern, and I'm sure much care will be taken during
> > > > implementation
> > > > > to avoid it.
> > > > >
> > > > > Wrt transparency, I agree 

Re: [Wikimedia-l] Paid API?

2020-07-09 Thread Mohammed Bachounda
Hello,
Why i'm recieving this message :
Message not delivered
There was a problem delivering your message to *don...@wikimedia.com*. See
the technical details below.

* Mohammed Bachounda *
Leader Wikimedia Algeria UG
  [image: Thumbnail for version as of 13:48, 19 April 2020]


On Thu, Jul 9, 2020 at 2:05 AM Joseph Seddon  wrote:

> Hey all,
>
> Apologies for the delay. Two overview pages covering the technical and
> business side of the project:
>
> https://meta.wikimedia.org/wiki/OKAPI
> https://www.mediawiki.org/wiki/OKAPI
>
> Regards
> Seddon
>
> On Tue, Jun 16, 2020 at 10:29 PM Samuel Klein  wrote:
>
> > A well-provisioned bulk api has been missing for some time.  Thanks for
> > working on this.  And clearing up the recommended way for WP content to
> > appear and be linked in third-party searches and infoboxes is important
> --
> > the sort of thing that an internal policy (and way to subscribe to feeds)
> > can help.
> >
> > I do hope we can host this on WM or openstack infrastructure, and do it
> in
> > a way that expands and improves the solid existing frameworks for HTML
> > dumps :)
> >
> > S
> >
> >
> > On Tue, Jun 16, 2020 at 8:43 AM Chris Keating <
> chriskeatingw...@gmail.com>
> > wrote:
> >
> > > It's interesting that of all the strategy recommendations, two are so
> far
> > > being implemented. One is the Universal Code of Conduct, which has at
> > least
> > > had plenty of discussion and publicity, that even precedes the strategy
> > > process. The other is this, which hasn't been particularly prominent
> > > before, but the WMF seems to have a team working on it just a couple of
> > > weeks after the final recommendations were published.
> > >
> > > So while doing this is one of the strategy recommendations, it doesn't
> > seem
> > > that is is now happening *because of* the strategy recommendations
> > >
> > > Chris
> > >
> > > On Mon, Jun 15, 2020 at 10:46 AM Gergő Tisza  wrote:
> > >
> > > > You can find some more discussion at
> > > >
> > > >
> > >
> >
> https://meta.wikimedia.org/wiki/Talk:Strategy/Wikimedia_movement/2018-20/Recommendations/Iteration_3/Promote_Sustainability_and_Resilience#Freemium
> > > >
> > > > As I mentioned there, the premise of the recommendation is that the
> > > > movement needs new revenue sources; in part because the 2030 strategy
> > is
> > > > ambitious and requires a significant increase in resources, in part
> > > because
> > > > our current lack of diversity (about 40% of the movement's budget is
> > from
> > > > donations through website banners, and another 40% from past banners
> > via
> > > > email campaigns and such) is a strategic risk because those donations
> > can
> > > > be disrupted by various social or technical trends. For example,
> large
> > > tech
> > > > companies which are the starting point of people's internet
> experience
> > > > (such as Facebook or Google) clearly have aspirations to become the
> end
> > > > point as well - they try to ingest and display to their users
> directly
> > as
> > > > much online content as they can. Today, that's not a whole lot of
> > content
> > > > (you might see fragments of Wikipedia infoboxes in Google's
> "knowledge
> > > > panel", for example, but nothing resembling an encyclopedia article).
> > Ten
> > > > years from now, that might be different, and so we need to consider
> how
> > > we
> > > > would sustain ourselves in such a world - in terms of revenue, and
> also
> > > in
> > > > terms of people (how would new editors join the project, if most
> people
> > > > interacted with our content not via our website, but interfaces
> > provided
> > > by
> > > > big tech companies where there is no edit button?).
> > > >
> > > > The new API project aims to do that, both in the sense of making it
> > > > possible to have more equitable arrangements with bulk reusers of our
> > > > content (who make lots of money with it), and by making it easier to
> > > reuse
> > > > content in ways that align with our movement's values (currently, if
> > you
> > > > reuse Wikipedia content in your own website or application, and want
> to
> > > > provide your users with information about the licensing or provenance
> > of
> > > > that content, or allow them to contribute, the tools we provide for
> > that
> > > > are third rate at best). As the recommendation mentions, erecting
> > > > unintentional barriers to small-scale or non-commercial reusers was
> > very
> > > > much a concern, and I'm sure much care will be taken during
> > > implementation
> > > > to avoid it.
> > > >
> > > > Wrt transparency, I agree this was communicated less clearly than
> > ideal,
> > > > but from the Wikimedia Foundation's point of view, it can be hard to
> > know
> > > > when to consult the community and to what extent (churning out so
> much
> > > > information that few volunteers can keep up with it can be a problem
> > too;
> > > > arguably early phases of the strategy process suffered from 

Re: [Wikimedia-l] Paid API?

2020-07-08 Thread Joseph Seddon
Hey all,

Apologies for the delay. Two overview pages covering the technical and
business side of the project:

https://meta.wikimedia.org/wiki/OKAPI
https://www.mediawiki.org/wiki/OKAPI

Regards
Seddon

On Tue, Jun 16, 2020 at 10:29 PM Samuel Klein  wrote:

> A well-provisioned bulk api has been missing for some time.  Thanks for
> working on this.  And clearing up the recommended way for WP content to
> appear and be linked in third-party searches and infoboxes is important --
> the sort of thing that an internal policy (and way to subscribe to feeds)
> can help.
>
> I do hope we can host this on WM or openstack infrastructure, and do it in
> a way that expands and improves the solid existing frameworks for HTML
> dumps :)
>
> S
>
>
> On Tue, Jun 16, 2020 at 8:43 AM Chris Keating 
> wrote:
>
> > It's interesting that of all the strategy recommendations, two are so far
> > being implemented. One is the Universal Code of Conduct, which has at
> least
> > had plenty of discussion and publicity, that even precedes the strategy
> > process. The other is this, which hasn't been particularly prominent
> > before, but the WMF seems to have a team working on it just a couple of
> > weeks after the final recommendations were published.
> >
> > So while doing this is one of the strategy recommendations, it doesn't
> seem
> > that is is now happening *because of* the strategy recommendations
> >
> > Chris
> >
> > On Mon, Jun 15, 2020 at 10:46 AM Gergő Tisza  wrote:
> >
> > > You can find some more discussion at
> > >
> > >
> >
> https://meta.wikimedia.org/wiki/Talk:Strategy/Wikimedia_movement/2018-20/Recommendations/Iteration_3/Promote_Sustainability_and_Resilience#Freemium
> > >
> > > As I mentioned there, the premise of the recommendation is that the
> > > movement needs new revenue sources; in part because the 2030 strategy
> is
> > > ambitious and requires a significant increase in resources, in part
> > because
> > > our current lack of diversity (about 40% of the movement's budget is
> from
> > > donations through website banners, and another 40% from past banners
> via
> > > email campaigns and such) is a strategic risk because those donations
> can
> > > be disrupted by various social or technical trends. For example, large
> > tech
> > > companies which are the starting point of people's internet experience
> > > (such as Facebook or Google) clearly have aspirations to become the end
> > > point as well - they try to ingest and display to their users directly
> as
> > > much online content as they can. Today, that's not a whole lot of
> content
> > > (you might see fragments of Wikipedia infoboxes in Google's "knowledge
> > > panel", for example, but nothing resembling an encyclopedia article).
> Ten
> > > years from now, that might be different, and so we need to consider how
> > we
> > > would sustain ourselves in such a world - in terms of revenue, and also
> > in
> > > terms of people (how would new editors join the project, if most people
> > > interacted with our content not via our website, but interfaces
> provided
> > by
> > > big tech companies where there is no edit button?).
> > >
> > > The new API project aims to do that, both in the sense of making it
> > > possible to have more equitable arrangements with bulk reusers of our
> > > content (who make lots of money with it), and by making it easier to
> > reuse
> > > content in ways that align with our movement's values (currently, if
> you
> > > reuse Wikipedia content in your own website or application, and want to
> > > provide your users with information about the licensing or provenance
> of
> > > that content, or allow them to contribute, the tools we provide for
> that
> > > are third rate at best). As the recommendation mentions, erecting
> > > unintentional barriers to small-scale or non-commercial reusers was
> very
> > > much a concern, and I'm sure much care will be taken during
> > implementation
> > > to avoid it.
> > >
> > > Wrt transparency, I agree this was communicated less clearly than
> ideal,
> > > but from the Wikimedia Foundation's point of view, it can be hard to
> know
> > > when to consult the community and to what extent (churning out so much
> > > information that few volunteers can keep up with it can be a problem
> too;
> > > arguably early phases of the strategy process suffered from it). This
> is
> > a
> > > problem that has received considerable attention within the WMF
> recently
> > > (unrelated to API plans) so there's at the very least an effort to make
> > the
> > > process of sharing plans and gathering feedback more predictable.
> > > Also, the pandemic has been a huge disruption for the WMF. Normally, by
> > > this point, the community would have been consulted on the draft annual
> > > plan, which is where new initiatives tend to be announced; but that has
> > > been delayed significantly due to so many staff members' lives being
> > > upheaved. Movement events where such plans are usually 

Re: [Wikimedia-l] Paid API?

2020-06-16 Thread Samuel Klein
A well-provisioned bulk api has been missing for some time.  Thanks for
working on this.  And clearing up the recommended way for WP content to
appear and be linked in third-party searches and infoboxes is important --
the sort of thing that an internal policy (and way to subscribe to feeds)
can help.

I do hope we can host this on WM or openstack infrastructure, and do it in
a way that expands and improves the solid existing frameworks for HTML
dumps :)

S


On Tue, Jun 16, 2020 at 8:43 AM Chris Keating 
wrote:

> It's interesting that of all the strategy recommendations, two are so far
> being implemented. One is the Universal Code of Conduct, which has at least
> had plenty of discussion and publicity, that even precedes the strategy
> process. The other is this, which hasn't been particularly prominent
> before, but the WMF seems to have a team working on it just a couple of
> weeks after the final recommendations were published.
>
> So while doing this is one of the strategy recommendations, it doesn't seem
> that is is now happening *because of* the strategy recommendations
>
> Chris
>
> On Mon, Jun 15, 2020 at 10:46 AM Gergő Tisza  wrote:
>
> > You can find some more discussion at
> >
> >
> https://meta.wikimedia.org/wiki/Talk:Strategy/Wikimedia_movement/2018-20/Recommendations/Iteration_3/Promote_Sustainability_and_Resilience#Freemium
> >
> > As I mentioned there, the premise of the recommendation is that the
> > movement needs new revenue sources; in part because the 2030 strategy is
> > ambitious and requires a significant increase in resources, in part
> because
> > our current lack of diversity (about 40% of the movement's budget is from
> > donations through website banners, and another 40% from past banners via
> > email campaigns and such) is a strategic risk because those donations can
> > be disrupted by various social or technical trends. For example, large
> tech
> > companies which are the starting point of people's internet experience
> > (such as Facebook or Google) clearly have aspirations to become the end
> > point as well - they try to ingest and display to their users directly as
> > much online content as they can. Today, that's not a whole lot of content
> > (you might see fragments of Wikipedia infoboxes in Google's "knowledge
> > panel", for example, but nothing resembling an encyclopedia article). Ten
> > years from now, that might be different, and so we need to consider how
> we
> > would sustain ourselves in such a world - in terms of revenue, and also
> in
> > terms of people (how would new editors join the project, if most people
> > interacted with our content not via our website, but interfaces provided
> by
> > big tech companies where there is no edit button?).
> >
> > The new API project aims to do that, both in the sense of making it
> > possible to have more equitable arrangements with bulk reusers of our
> > content (who make lots of money with it), and by making it easier to
> reuse
> > content in ways that align with our movement's values (currently, if you
> > reuse Wikipedia content in your own website or application, and want to
> > provide your users with information about the licensing or provenance of
> > that content, or allow them to contribute, the tools we provide for that
> > are third rate at best). As the recommendation mentions, erecting
> > unintentional barriers to small-scale or non-commercial reusers was very
> > much a concern, and I'm sure much care will be taken during
> implementation
> > to avoid it.
> >
> > Wrt transparency, I agree this was communicated less clearly than ideal,
> > but from the Wikimedia Foundation's point of view, it can be hard to know
> > when to consult the community and to what extent (churning out so much
> > information that few volunteers can keep up with it can be a problem too;
> > arguably early phases of the strategy process suffered from it). This is
> a
> > problem that has received considerable attention within the WMF recently
> > (unrelated to API plans) so there's at the very least an effort to make
> the
> > process of sharing plans and gathering feedback more predictable.
> > Also, the pandemic has been a huge disruption for the WMF. Normally, by
> > this point, the community would have been consulted on the draft annual
> > plan, which is where new initiatives tend to be announced; but that has
> > been delayed significantly due to so many staff members' lives being
> > upheaved. Movement events where such plans are usually discussed had to
> be
> > cancelled, and so on.
> >
> > (Written with my volunteer hat on. I was involved in the strategy process
> > and helped write the recommendation snippet Yair quoted upthread; I'm not
> > involved in the API gateway project.)
> > ___
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> > https://meta.wikimedia.org/wiki/Wikimedia-l
> > New messages 

Re: [Wikimedia-l] Paid API?

2020-06-16 Thread Joseph Seddon
Hey Chris,

I think that saying this happened because of the recommendations remains a
fair statement but for sure there are some caveats with that. I don’t want
to speak for the entire org but I'm also pretty confident in saying that
there are a lot more than just two recommendations with work having started
or about having work spun up on. Infrastructure and Financial
sustainability, User Experience, Safety and Inclusion work are all things
aligned with work the foundation is doing and that are in step with the
strategy recommendations.

With the WMF’s planning process for 2020-21, I think it is fair to say it
was done with both eyes firmly on what was working its way through Phase 2
of the strategy and we aligned or are aligning plans with what came out
back in May.  In this instance improvements to infrastructure and in this
case APIs, data interfaces etc. have been present throughout that and were
the output from two separate working groups during phase 2. The
recommendations of those two working groups aren't moving forward in
isolation either and the WMF is looking to improve its API infrastructure
in a much broader sense and that work is also getting up to speed as we
move into the next financial year.

The reason for that is that we must keep in mind that the strategy process
has gone on for nearly 4 years and the phase we just completed has been
going on for nearly two years now. The recommendations we have today have
grown from that entire 4 year body of work and the whole process has had a
huge influence on the WMF and what goals it is working towards.

Although sometimes many of us might think it, the organisation doesn’t work
in a silo and with that comes the reality that planning timelines don’t
align. I know that if the strategy had come out and the WMF had just sat on
its hands for 16 months until June 2021, waiting for another cycle, before
it started any of the work contained within the strategy, I would have had
a very strongly raised eyebrow and I think there would have been
frustrations from many people. Given that it makes sense that the WMF has
been actively preparing, readying itself and laying the groundwork to get
straight to work in implementing those recommendations.

Seddon

On Tue, Jun 16, 2020 at 1:43 PM Chris Keating 
wrote:

> It's interesting that of all the strategy recommendations, two are so far
> being implemented. One is the Universal Code of Conduct, which has at least
> had plenty of discussion and publicity, that even precedes the strategy
> process. The other is this, which hasn't been particularly prominent
> before, but the WMF seems to have a team working on it just a couple of
> weeks after the final recommendations were published.
>
> So while doing this is one of the strategy recommendations, it doesn't seem
> that is is now happening *because of* the strategy recommendations
>
> Chris
>
> On Mon, Jun 15, 2020 at 10:46 AM Gergő Tisza  wrote:
>
> > You can find some more discussion at
> >
> >
> https://meta.wikimedia.org/wiki/Talk:Strategy/Wikimedia_movement/2018-20/Recommendations/Iteration_3/Promote_Sustainability_and_Resilience#Freemium
> >
> > As I mentioned there, the premise of the recommendation is that the
> > movement needs new revenue sources; in part because the 2030 strategy is
> > ambitious and requires a significant increase in resources, in part
> because
> > our current lack of diversity (about 40% of the movement's budget is from
> > donations through website banners, and another 40% from past banners via
> > email campaigns and such) is a strategic risk because those donations can
> > be disrupted by various social or technical trends. For example, large
> tech
> > companies which are the starting point of people's internet experience
> > (such as Facebook or Google) clearly have aspirations to become the end
> > point as well - they try to ingest and display to their users directly as
> > much online content as they can. Today, that's not a whole lot of content
> > (you might see fragments of Wikipedia infoboxes in Google's "knowledge
> > panel", for example, but nothing resembling an encyclopedia article). Ten
> > years from now, that might be different, and so we need to consider how
> we
> > would sustain ourselves in such a world - in terms of revenue, and also
> in
> > terms of people (how would new editors join the project, if most people
> > interacted with our content not via our website, but interfaces provided
> by
> > big tech companies where there is no edit button?).
> >
> > The new API project aims to do that, both in the sense of making it
> > possible to have more equitable arrangements with bulk reusers of our
> > content (who make lots of money with it), and by making it easier to
> reuse
> > content in ways that align with our movement's values (currently, if you
> > reuse Wikipedia content in your own website or application, and want to
> > provide your users with information about the licensing or provenance of
> 

Re: [Wikimedia-l] Paid API?

2020-06-16 Thread Dennis During
1. Never let a crisis go to waste.
2. Never let a strategy process go to waste.

If you've got something you want that is not necessarily universally loved,
make a plan and cram it into anything that doesn't make it a laughingstock.

Want to loot Constantinople? Make sure you're in the Crusade that passes by
there. This tactic is neutral, available for good, evil, partisan ends.

On Tue, Jun 16, 2020, 08:43 Chris Keating 
wrote:

> It's interesting that of all the strategy recommendations, two are so far
> being implemented. One is the Universal Code of Conduct, which has at least
> had plenty of discussion and publicity, that even precedes the strategy
> process. The other is this, which hasn't been particularly prominent
> before, but the WMF seems to have a team working on it just a couple of
> weeks after the final recommendations were published.
>
> So while doing this is one of the strategy recommendations, it doesn't seem
> that is is now happening *because of* the strategy recommendations
>
> Chris
>
> On Mon, Jun 15, 2020 at 10:46 AM Gergő Tisza  wrote:
>
> > You can find some more discussion at
> >
> >
> https://meta.wikimedia.org/wiki/Talk:Strategy/Wikimedia_movement/2018-20/Recommendations/Iteration_3/Promote_Sustainability_and_Resilience#Freemium
> >
> > As I mentioned there, the premise of the recommendation is that the
> > movement needs new revenue sources; in part because the 2030 strategy is
> > ambitious and requires a significant increase in resources, in part
> because
> > our current lack of diversity (about 40% of the movement's budget is from
> > donations through website banners, and another 40% from past banners via
> > email campaigns and such) is a strategic risk because those donations can
> > be disrupted by various social or technical trends. For example, large
> tech
> > companies which are the starting point of people's internet experience
> > (such as Facebook or Google) clearly have aspirations to become the end
> > point as well - they try to ingest and display to their users directly as
> > much online content as they can. Today, that's not a whole lot of content
> > (you might see fragments of Wikipedia infoboxes in Google's "knowledge
> > panel", for example, but nothing resembling an encyclopedia article). Ten
> > years from now, that might be different, and so we need to consider how
> we
> > would sustain ourselves in such a world - in terms of revenue, and also
> in
> > terms of people (how would new editors join the project, if most people
> > interacted with our content not via our website, but interfaces provided
> by
> > big tech companies where there is no edit button?).
> >
> > The new API project aims to do that, both in the sense of making it
> > possible to have more equitable arrangements with bulk reusers of our
> > content (who make lots of money with it), and by making it easier to
> reuse
> > content in ways that align with our movement's values (currently, if you
> > reuse Wikipedia content in your own website or application, and want to
> > provide your users with information about the licensing or provenance of
> > that content, or allow them to contribute, the tools we provide for that
> > are third rate at best). As the recommendation mentions, erecting
> > unintentional barriers to small-scale or non-commercial reusers was very
> > much a concern, and I'm sure much care will be taken during
> implementation
> > to avoid it.
> >
> > Wrt transparency, I agree this was communicated less clearly than ideal,
> > but from the Wikimedia Foundation's point of view, it can be hard to know
> > when to consult the community and to what extent (churning out so much
> > information that few volunteers can keep up with it can be a problem too;
> > arguably early phases of the strategy process suffered from it). This is
> a
> > problem that has received considerable attention within the WMF recently
> > (unrelated to API plans) so there's at the very least an effort to make
> the
> > process of sharing plans and gathering feedback more predictable.
> > Also, the pandemic has been a huge disruption for the WMF. Normally, by
> > this point, the community would have been consulted on the draft annual
> > plan, which is where new initiatives tend to be announced; but that has
> > been delayed significantly due to so many staff members' lives being
> > upheaved. Movement events where such plans are usually discussed had to
> be
> > cancelled, and so on.
> >
> > (Written with my volunteer hat on. I was involved in the strategy process
> > and helped write the recommendation snippet Yair quoted upthread; I'm not
> > involved in the API gateway project.)
> > ___
> > 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: 

Re: [Wikimedia-l] Paid API?

2020-06-16 Thread Chris Keating
It's interesting that of all the strategy recommendations, two are so far
being implemented. One is the Universal Code of Conduct, which has at least
had plenty of discussion and publicity, that even precedes the strategy
process. The other is this, which hasn't been particularly prominent
before, but the WMF seems to have a team working on it just a couple of
weeks after the final recommendations were published.

So while doing this is one of the strategy recommendations, it doesn't seem
that is is now happening *because of* the strategy recommendations

Chris

On Mon, Jun 15, 2020 at 10:46 AM Gergő Tisza  wrote:

> You can find some more discussion at
>
> https://meta.wikimedia.org/wiki/Talk:Strategy/Wikimedia_movement/2018-20/Recommendations/Iteration_3/Promote_Sustainability_and_Resilience#Freemium
>
> As I mentioned there, the premise of the recommendation is that the
> movement needs new revenue sources; in part because the 2030 strategy is
> ambitious and requires a significant increase in resources, in part because
> our current lack of diversity (about 40% of the movement's budget is from
> donations through website banners, and another 40% from past banners via
> email campaigns and such) is a strategic risk because those donations can
> be disrupted by various social or technical trends. For example, large tech
> companies which are the starting point of people's internet experience
> (such as Facebook or Google) clearly have aspirations to become the end
> point as well - they try to ingest and display to their users directly as
> much online content as they can. Today, that's not a whole lot of content
> (you might see fragments of Wikipedia infoboxes in Google's "knowledge
> panel", for example, but nothing resembling an encyclopedia article). Ten
> years from now, that might be different, and so we need to consider how we
> would sustain ourselves in such a world - in terms of revenue, and also in
> terms of people (how would new editors join the project, if most people
> interacted with our content not via our website, but interfaces provided by
> big tech companies where there is no edit button?).
>
> The new API project aims to do that, both in the sense of making it
> possible to have more equitable arrangements with bulk reusers of our
> content (who make lots of money with it), and by making it easier to reuse
> content in ways that align with our movement's values (currently, if you
> reuse Wikipedia content in your own website or application, and want to
> provide your users with information about the licensing or provenance of
> that content, or allow them to contribute, the tools we provide for that
> are third rate at best). As the recommendation mentions, erecting
> unintentional barriers to small-scale or non-commercial reusers was very
> much a concern, and I'm sure much care will be taken during implementation
> to avoid it.
>
> Wrt transparency, I agree this was communicated less clearly than ideal,
> but from the Wikimedia Foundation's point of view, it can be hard to know
> when to consult the community and to what extent (churning out so much
> information that few volunteers can keep up with it can be a problem too;
> arguably early phases of the strategy process suffered from it). This is a
> problem that has received considerable attention within the WMF recently
> (unrelated to API plans) so there's at the very least an effort to make the
> process of sharing plans and gathering feedback more predictable.
> Also, the pandemic has been a huge disruption for the WMF. Normally, by
> this point, the community would have been consulted on the draft annual
> plan, which is where new initiatives tend to be announced; but that has
> been delayed significantly due to so many staff members' lives being
> upheaved. Movement events where such plans are usually discussed had to be
> cancelled, and so on.
>
> (Written with my volunteer hat on. I was involved in the strategy process
> and helped write the recommendation snippet Yair quoted upthread; I'm not
> involved in the API gateway project.)
> ___
> 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] Paid API?

2020-06-15 Thread Gergő Tisza
You can find some more discussion at
https://meta.wikimedia.org/wiki/Talk:Strategy/Wikimedia_movement/2018-20/Recommendations/Iteration_3/Promote_Sustainability_and_Resilience#Freemium

As I mentioned there, the premise of the recommendation is that the
movement needs new revenue sources; in part because the 2030 strategy is
ambitious and requires a significant increase in resources, in part because
our current lack of diversity (about 40% of the movement's budget is from
donations through website banners, and another 40% from past banners via
email campaigns and such) is a strategic risk because those donations can
be disrupted by various social or technical trends. For example, large tech
companies which are the starting point of people's internet experience
(such as Facebook or Google) clearly have aspirations to become the end
point as well - they try to ingest and display to their users directly as
much online content as they can. Today, that's not a whole lot of content
(you might see fragments of Wikipedia infoboxes in Google's "knowledge
panel", for example, but nothing resembling an encyclopedia article). Ten
years from now, that might be different, and so we need to consider how we
would sustain ourselves in such a world - in terms of revenue, and also in
terms of people (how would new editors join the project, if most people
interacted with our content not via our website, but interfaces provided by
big tech companies where there is no edit button?).

The new API project aims to do that, both in the sense of making it
possible to have more equitable arrangements with bulk reusers of our
content (who make lots of money with it), and by making it easier to reuse
content in ways that align with our movement's values (currently, if you
reuse Wikipedia content in your own website or application, and want to
provide your users with information about the licensing or provenance of
that content, or allow them to contribute, the tools we provide for that
are third rate at best). As the recommendation mentions, erecting
unintentional barriers to small-scale or non-commercial reusers was very
much a concern, and I'm sure much care will be taken during implementation
to avoid it.

Wrt transparency, I agree this was communicated less clearly than ideal,
but from the Wikimedia Foundation's point of view, it can be hard to know
when to consult the community and to what extent (churning out so much
information that few volunteers can keep up with it can be a problem too;
arguably early phases of the strategy process suffered from it). This is a
problem that has received considerable attention within the WMF recently
(unrelated to API plans) so there's at the very least an effort to make the
process of sharing plans and gathering feedback more predictable.
Also, the pandemic has been a huge disruption for the WMF. Normally, by
this point, the community would have been consulted on the draft annual
plan, which is where new initiatives tend to be announced; but that has
been delayed significantly due to so many staff members' lives being
upheaved. Movement events where such plans are usually discussed had to be
cancelled, and so on.

(Written with my volunteer hat on. I was involved in the strategy process
and helped write the recommendation snippet Yair quoted upthread; I'm not
involved in the API gateway project.)
___
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] Paid API?

2020-06-14 Thread Joseph Seddon
Hey Amir!

Thanks for your questions. It’s sunday (for me 0400 on a Monday) and a
mailing list isn’t the right venue for a full detailed explanation for this
but I’ll give a little background.

James is correct that the work in this area is coming out of the strategy
process and the recommendations it produced [1] [2] and is part of broad
improvements we are aiming to make to Wikimedia APIs. [3] We are aiming to
improve the experience for both free knowledge and community users, along
with large scale users.

Many of the people working on this are brand new (just a few weeks in) and
just getting their feet under the table. Right now they are just
experimenting on concepts relating to the data “, as part of their
onboarding and their early research work to understand the problems and
challenges. Everything is “early days” as they say. There is a lot to learn
and work on, and right now none of it is set in stone. Even the name is
mainly a placeholder (Bulk API might be a more accurate description).

The feedback and concerns that were provided during the strategy process
will be required reading and will help guide us initially. We will
definitely need to seek the expertise and insight of our communities both
editing and technical to ensure it is not just successful but in keeping
with our movement's ideals. The community can expect to see requests for
input and feedback in the coming months.

Given we are very early in this process there will definitely be further
documentation on the work planned and some initial details will be
available ASAP. My genuine apologies that this didn’t happen already.

Many thanks

Seddon

[1] From
https://meta.wikimedia.org/wiki/Strategy/Wikimedia_movement/2018-20/Recommendations/Improve_User_Experience
:

** Make the Wikimedia API suite more comprehensive, reliable, secure and
fast, in partnership with large scale users where that aligns with our
mission and principles, to improve the user experience of both our direct
and indirect users, increase the reach and discoverability of our content
and the potential for data returns, and improve awareness of and ease of
attribution and verifiability for content reusers.

[2] From
https://meta.wikimedia.org/wiki/Strategy/Wikimedia_movement/2018-20/Recommendations/Increase_the_Sustainability_of_Our_Movement#Financial_sustainability
:

* Building enterprise-level APIs (with high standards of availability,
throughput, and usability).

** Engage partners in the development wherever appropriate, incorporating
the needs of a spectrum of small, non-commercial, and larger commercial
reusers.

** Explore fees or sustainability models for enterprise-scale commercial
reusers, taking care to avoid revenue dependencies or other undue external
influence in product design and development.

** Develop appropriate safeguards to ensure continued free, unrestricted
access for non-commercial, research, and small to moderate commercial use.

[3] For example
https://www.mediawiki.org/wiki/Core_Platform_Team/Initiatives/API_Gateway

On Sun, Jun 14, 2020 at 10:23 PM Amir Sarabadani 
wrote:

> Thanks for the pointers, I personally disagree with some parts of it (e.g.
> Twitter is a company and we are an NGO) BUT since it passed the community
> consultation (and I somehow missed it to raise my feedback), I don't want
> to be vocal about the high level reasoning behind the project.
>
> What I would extremely appreciate is more transparent communication to the
> community about such large changes (especially sooner). Something like a
> two-line text on a phabricator has lots of potential for misunderstanding.
>
> Thanks again.
>
> On Sun, Jun 14, 2020 at 9:44 PM James Heilman  wrote:
>
> > Further details are forthcoming from WMF staff.
> >
> > J
> >
> > On Sun, Jun 14, 2020 at 1:42 PM James Heilman  wrote:
> >
> > > Was discussed here
> > >
> > >
> > >
> >
> https://meta.wikimedia.org/wiki/Strategy/Wikimedia_movement/2018-20/Recommendations/Iteration_1/Revenue_Streams/1
> > >
> > > and
> > >
> > >
> > >
> >
> https://meta.wikimedia.org/wiki/Talk:Strategy/Wikimedia_movement/2018-20/Recommendations/Iteration_1/Revenue_Streams/1
> > >
> > > James
> > >
> > > On Sun, Jun 14, 2020 at 1:37 PM Yair Rand  wrote:
> > >
> > >> The strategy recommendations include the text: "Explore fees or
> > >> sustainability models for enterprise-scale commercial reusers, taking
> > care
> > >> to avoid revenue dependencies or other undue external influence in
> > product
> > >> design and development. / Develop appropriate safeguards to ensure
> > >> continued free, unrestricted access for non-commercial, research, and
> > >> small
> > >> to moderate commercial use." Earlier versions elaborate somewhat, and
> > >> there
> > >> were considerable reservations expressed about the idea during the
> > >> process.
> > >>
> > >> It is quite concerning.
> > >>
> > >> -- Yair Rand
> > >>
> > >> ‫בתאריך יום א׳, 14 ביוני 2020 ב-14:33 מאת ‪Amir Sarabadani‬‏ <‪
> > >> ladsgr...@gmail.com‬‏>:‬

Re: [Wikimedia-l] Paid API?

2020-06-14 Thread Amir Sarabadani
Thanks for the pointers, I personally disagree with some parts of it (e.g.
Twitter is a company and we are an NGO) BUT since it passed the community
consultation (and I somehow missed it to raise my feedback), I don't want
to be vocal about the high level reasoning behind the project.

What I would extremely appreciate is more transparent communication to the
community about such large changes (especially sooner). Something like a
two-line text on a phabricator has lots of potential for misunderstanding.

Thanks again.

On Sun, Jun 14, 2020 at 9:44 PM James Heilman  wrote:

> Further details are forthcoming from WMF staff.
>
> J
>
> On Sun, Jun 14, 2020 at 1:42 PM James Heilman  wrote:
>
> > Was discussed here
> >
> >
> >
> https://meta.wikimedia.org/wiki/Strategy/Wikimedia_movement/2018-20/Recommendations/Iteration_1/Revenue_Streams/1
> >
> > and
> >
> >
> >
> https://meta.wikimedia.org/wiki/Talk:Strategy/Wikimedia_movement/2018-20/Recommendations/Iteration_1/Revenue_Streams/1
> >
> > James
> >
> > On Sun, Jun 14, 2020 at 1:37 PM Yair Rand  wrote:
> >
> >> The strategy recommendations include the text: "Explore fees or
> >> sustainability models for enterprise-scale commercial reusers, taking
> care
> >> to avoid revenue dependencies or other undue external influence in
> product
> >> design and development. / Develop appropriate safeguards to ensure
> >> continued free, unrestricted access for non-commercial, research, and
> >> small
> >> to moderate commercial use." Earlier versions elaborate somewhat, and
> >> there
> >> were considerable reservations expressed about the idea during the
> >> process.
> >>
> >> It is quite concerning.
> >>
> >> -- Yair Rand
> >>
> >> ‫בתאריך יום א׳, 14 ביוני 2020 ב-14:33 מאת ‪Amir Sarabadani‬‏ <‪
> >> ladsgr...@gmail.com‬‏>:‬
> >>
> >> > Hello,
> >> > Today I stumbled upon this public phabricator ticket [1] created by
> >> someone
> >> > from WMF starting with:
> >> > "My team is creating bi-weekly HTML Dumps for all of the wikis, except
> >> for
> >> > wikidata as part of the paid API project."
> >> >
> >> > I have so many questions:
> >> >  - What is the "paid API" project? Are we planning to make money out
> of
> >> our
> >> > API? Now are we selling our dumps?
> >> >  - If so, why is this not communicated before? Why are we kept in the
> >> dark?
> >> >  - Does the board know and approve it?
> >> >  - How is this going to align with our core values like openness and
> >> > transparency?
> >> >  - The ticket implicitly says these are going to be stored on AWS ("S3
> >> > bucket"). Is this thought through? Specially the ethical problems of
> >> > feeding Jeff Bezos' empire? (If you have seen this episode of Hasan
> >> > Minhaj's on ethical issues of using AWS [2]). Why can't we do/host
> this
> >> on
> >> > Wikimedia infrastructure? Has this been evaluated?
> >> >  - Why is the community not consulted about this?
> >> >
> >> > Maybe I missed announcements, consultations or anything, forgive me
> for
> >> my
> >> > ignorance. Any pointers is enough. I also understand diversifying our
> >> > revenue is a good tool for rainy days but a consultation with the
> >> community
> >> > wouldn't be too bad.
> >> >
> >> > [1]: https://phabricator.wikimedia.org/T254275
> >> > [2]: https://www.youtube.com/watch?v=5maXvZ5fyQY
> >> >
> >> > Best
> >> > --
> >> > Amir (he/him)
> >> > ___
> >> > 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,
> >> 
> >
> >
> >
> > --
> > James Heilman
> > MD, CCFP-EM, Wikipedian
> >
>
>
> --
> James Heilman
> MD, CCFP-EM, Wikipedian
> ___
> 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,
> 



-- 
Amir (he/him)
___
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

Re: [Wikimedia-l] Paid API?

2020-06-14 Thread James Heilman
Further details are forthcoming from WMF staff.

J

On Sun, Jun 14, 2020 at 1:42 PM James Heilman  wrote:

> Was discussed here
>
>
> https://meta.wikimedia.org/wiki/Strategy/Wikimedia_movement/2018-20/Recommendations/Iteration_1/Revenue_Streams/1
>
> and
>
>
> https://meta.wikimedia.org/wiki/Talk:Strategy/Wikimedia_movement/2018-20/Recommendations/Iteration_1/Revenue_Streams/1
>
> James
>
> On Sun, Jun 14, 2020 at 1:37 PM Yair Rand  wrote:
>
>> The strategy recommendations include the text: "Explore fees or
>> sustainability models for enterprise-scale commercial reusers, taking care
>> to avoid revenue dependencies or other undue external influence in product
>> design and development. / Develop appropriate safeguards to ensure
>> continued free, unrestricted access for non-commercial, research, and
>> small
>> to moderate commercial use." Earlier versions elaborate somewhat, and
>> there
>> were considerable reservations expressed about the idea during the
>> process.
>>
>> It is quite concerning.
>>
>> -- Yair Rand
>>
>> ‫בתאריך יום א׳, 14 ביוני 2020 ב-14:33 מאת ‪Amir Sarabadani‬‏ <‪
>> ladsgr...@gmail.com‬‏>:‬
>>
>> > Hello,
>> > Today I stumbled upon this public phabricator ticket [1] created by
>> someone
>> > from WMF starting with:
>> > "My team is creating bi-weekly HTML Dumps for all of the wikis, except
>> for
>> > wikidata as part of the paid API project."
>> >
>> > I have so many questions:
>> >  - What is the "paid API" project? Are we planning to make money out of
>> our
>> > API? Now are we selling our dumps?
>> >  - If so, why is this not communicated before? Why are we kept in the
>> dark?
>> >  - Does the board know and approve it?
>> >  - How is this going to align with our core values like openness and
>> > transparency?
>> >  - The ticket implicitly says these are going to be stored on AWS ("S3
>> > bucket"). Is this thought through? Specially the ethical problems of
>> > feeding Jeff Bezos' empire? (If you have seen this episode of Hasan
>> > Minhaj's on ethical issues of using AWS [2]). Why can't we do/host this
>> on
>> > Wikimedia infrastructure? Has this been evaluated?
>> >  - Why is the community not consulted about this?
>> >
>> > Maybe I missed announcements, consultations or anything, forgive me for
>> my
>> > ignorance. Any pointers is enough. I also understand diversifying our
>> > revenue is a good tool for rainy days but a consultation with the
>> community
>> > wouldn't be too bad.
>> >
>> > [1]: https://phabricator.wikimedia.org/T254275
>> > [2]: https://www.youtube.com/watch?v=5maXvZ5fyQY
>> >
>> > Best
>> > --
>> > Amir (he/him)
>> > ___
>> > 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,
>> 
>
>
>
> --
> James Heilman
> MD, CCFP-EM, Wikipedian
>


-- 
James Heilman
MD, CCFP-EM, Wikipedian
___
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] Paid API?

2020-06-14 Thread James Heilman
Was discussed here

https://meta.wikimedia.org/wiki/Strategy/Wikimedia_movement/2018-20/Recommendations/Iteration_1/Revenue_Streams/1

and

https://meta.wikimedia.org/wiki/Talk:Strategy/Wikimedia_movement/2018-20/Recommendations/Iteration_1/Revenue_Streams/1

James

On Sun, Jun 14, 2020 at 1:37 PM Yair Rand  wrote:

> The strategy recommendations include the text: "Explore fees or
> sustainability models for enterprise-scale commercial reusers, taking care
> to avoid revenue dependencies or other undue external influence in product
> design and development. / Develop appropriate safeguards to ensure
> continued free, unrestricted access for non-commercial, research, and small
> to moderate commercial use." Earlier versions elaborate somewhat, and there
> were considerable reservations expressed about the idea during the process.
>
> It is quite concerning.
>
> -- Yair Rand
>
> ‫בתאריך יום א׳, 14 ביוני 2020 ב-14:33 מאת ‪Amir Sarabadani‬‏ <‪
> ladsgr...@gmail.com‬‏>:‬
>
> > Hello,
> > Today I stumbled upon this public phabricator ticket [1] created by
> someone
> > from WMF starting with:
> > "My team is creating bi-weekly HTML Dumps for all of the wikis, except
> for
> > wikidata as part of the paid API project."
> >
> > I have so many questions:
> >  - What is the "paid API" project? Are we planning to make money out of
> our
> > API? Now are we selling our dumps?
> >  - If so, why is this not communicated before? Why are we kept in the
> dark?
> >  - Does the board know and approve it?
> >  - How is this going to align with our core values like openness and
> > transparency?
> >  - The ticket implicitly says these are going to be stored on AWS ("S3
> > bucket"). Is this thought through? Specially the ethical problems of
> > feeding Jeff Bezos' empire? (If you have seen this episode of Hasan
> > Minhaj's on ethical issues of using AWS [2]). Why can't we do/host this
> on
> > Wikimedia infrastructure? Has this been evaluated?
> >  - Why is the community not consulted about this?
> >
> > Maybe I missed announcements, consultations or anything, forgive me for
> my
> > ignorance. Any pointers is enough. I also understand diversifying our
> > revenue is a good tool for rainy days but a consultation with the
> community
> > wouldn't be too bad.
> >
> > [1]: https://phabricator.wikimedia.org/T254275
> > [2]: https://www.youtube.com/watch?v=5maXvZ5fyQY
> >
> > Best
> > --
> > Amir (he/him)
> > ___
> > 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,
> 



-- 
James Heilman
MD, CCFP-EM, Wikipedian
___
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] Paid API?

2020-06-14 Thread Yair Rand
The strategy recommendations include the text: "Explore fees or
sustainability models for enterprise-scale commercial reusers, taking care
to avoid revenue dependencies or other undue external influence in product
design and development. / Develop appropriate safeguards to ensure
continued free, unrestricted access for non-commercial, research, and small
to moderate commercial use." Earlier versions elaborate somewhat, and there
were considerable reservations expressed about the idea during the process.

It is quite concerning.

-- Yair Rand

‫בתאריך יום א׳, 14 ביוני 2020 ב-14:33 מאת ‪Amir Sarabadani‬‏ <‪
ladsgr...@gmail.com‬‏>:‬

> Hello,
> Today I stumbled upon this public phabricator ticket [1] created by someone
> from WMF starting with:
> "My team is creating bi-weekly HTML Dumps for all of the wikis, except for
> wikidata as part of the paid API project."
>
> I have so many questions:
>  - What is the "paid API" project? Are we planning to make money out of our
> API? Now are we selling our dumps?
>  - If so, why is this not communicated before? Why are we kept in the dark?
>  - Does the board know and approve it?
>  - How is this going to align with our core values like openness and
> transparency?
>  - The ticket implicitly says these are going to be stored on AWS ("S3
> bucket"). Is this thought through? Specially the ethical problems of
> feeding Jeff Bezos' empire? (If you have seen this episode of Hasan
> Minhaj's on ethical issues of using AWS [2]). Why can't we do/host this on
> Wikimedia infrastructure? Has this been evaluated?
>  - Why is the community not consulted about this?
>
> Maybe I missed announcements, consultations or anything, forgive me for my
> ignorance. Any pointers is enough. I also understand diversifying our
> revenue is a good tool for rainy days but a consultation with the community
> wouldn't be too bad.
>
> [1]: https://phabricator.wikimedia.org/T254275
> [2]: https://www.youtube.com/watch?v=5maXvZ5fyQY
>
> Best
> --
> Amir (he/him)
> ___
> 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] Paid API?

2020-06-14 Thread Ariel Glenn WMF
I know that the dumps will be freely available to all.

Beyond that, I hope one of the people in the project will reply to your
concerns.

I do suggest that people comment or ask questions on the task itself, as I
have no idea if any of the people on the brand new team involved with that
project see these emails.

Ariel

On Sun, Jun 14, 2020 at 9:33 PM Amir Sarabadani  wrote:

> Hello,
> Today I stumbled upon this public phabricator ticket [1] created by someone
> from WMF starting with:
> "My team is creating bi-weekly HTML Dumps for all of the wikis, except for
> wikidata as part of the paid API project."
>
> I have so many questions:
>  - What is the "paid API" project? Are we planning to make money out of our
> API? Now are we selling our dumps?
>  - If so, why is this not communicated before? Why are we kept in the dark?
>  - Does the board know and approve it?
>  - How is this going to align with our core values like openness and
> transparency?
>  - The ticket implicitly says these are going to be stored on AWS ("S3
> bucket"). Is this thought through? Specially the ethical problems of
> feeding Jeff Bezos' empire? (If you have seen this episode of Hasan
> Minhaj's on ethical issues of using AWS [2]). Why can't we do/host this on
> Wikimedia infrastructure? Has this been evaluated?
>  - Why is the community not consulted about this?
>
> Maybe I missed announcements, consultations or anything, forgive me for my
> ignorance. Any pointers is enough. I also understand diversifying our
> revenue is a good tool for rainy days but a consultation with the community
> wouldn't be too bad.
>
> [1]: https://phabricator.wikimedia.org/T254275
> [2]: https://www.youtube.com/watch?v=5maXvZ5fyQY
>
> Best
> --
> Amir (he/him)
> ___
> 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,