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 <
vstavridoucoleman(a)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
<rupert.thurner(a)gmail.com>
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 <
vstavridoucoleman(a)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 <legoktm(a)member.fsf.org>
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(a)lists.wikimedia.org
>> Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l ,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l(a)lists.wikimedia.org
Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l(a)lists.wikimedia.org
Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l(a)lists.wikimedia.org
Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
--
Seddon
*Senior Community Relations Specialist*
*Advancement (Fundraising), Wikimedia Foundation*