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
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 ladsgroup@gmail.com 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.
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, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
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 < ladsgroup@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.
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, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Was discussed here
https://meta.wikimedia.org/wiki/Strategy/Wikimedia_movement/2018-20/Recommen...
and
https://meta.wikimedia.org/wiki/Talk:Strategy/Wikimedia_movement/2018-20/Rec...
James
On Sun, Jun 14, 2020 at 1:37 PM Yair Rand yyairrand@gmail.com 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 < ladsgroup@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.
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, 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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Further details are forthcoming from WMF staff.
J
On Sun, Jun 14, 2020 at 1:42 PM James Heilman jmh649@gmail.com wrote:
Was discussed here
https://meta.wikimedia.org/wiki/Strategy/Wikimedia_movement/2018-20/Recommen...
and
https://meta.wikimedia.org/wiki/Talk:Strategy/Wikimedia_movement/2018-20/Rec...
James
On Sun, Jun 14, 2020 at 1:37 PM Yair Rand yyairrand@gmail.com 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 < ladsgroup@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.
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, 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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
-- James Heilman MD, CCFP-EM, Wikipedian
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 jmh649@gmail.com wrote:
Further details are forthcoming from WMF staff.
J
On Sun, Jun 14, 2020 at 1:42 PM James Heilman jmh649@gmail.com wrote:
Was discussed here
https://meta.wikimedia.org/wiki/Strategy/Wikimedia_movement/2018-20/Recommen...
and
https://meta.wikimedia.org/wiki/Talk:Strategy/Wikimedia_movement/2018-20/Rec...
James
On Sun, Jun 14, 2020 at 1:37 PM Yair Rand yyairrand@gmail.com 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 < ladsgroup@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.
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
,
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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
-- 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, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
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/Recommen... :
** 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/Recommen... :
* 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 ladsgroup@gmail.com 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 jmh649@gmail.com wrote:
Further details are forthcoming from WMF staff.
J
On Sun, Jun 14, 2020 at 1:42 PM James Heilman jmh649@gmail.com wrote:
Was discussed here
https://meta.wikimedia.org/wiki/Strategy/Wikimedia_movement/2018-20/Recommen...
and
https://meta.wikimedia.org/wiki/Talk:Strategy/Wikimedia_movement/2018-20/Rec...
James
On Sun, Jun 14, 2020 at 1:37 PM Yair Rand yyairrand@gmail.com 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 < ladsgroup@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.
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
,
<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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
,
mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
-- 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, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
-- 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, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
You can find some more discussion at https://meta.wikimedia.org/wiki/Talk:Strategy/Wikimedia_movement/2018-20/Rec...
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.)
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 gtisza@gmail.com wrote:
You can find some more discussion at
https://meta.wikimedia.org/wiki/Talk:Strategy/Wikimedia_movement/2018-20/Rec...
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, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
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 chriskeatingwiki@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 gtisza@gmail.com wrote:
You can find some more discussion at
https://meta.wikimedia.org/wiki/Talk:Strategy/Wikimedia_movement/2018-20/Rec...
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, 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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
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 chriskeatingwiki@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 gtisza@gmail.com wrote:
You can find some more discussion at
https://meta.wikimedia.org/wiki/Talk:Strategy/Wikimedia_movement/2018-20/Rec...
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, 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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
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 chriskeatingwiki@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 gtisza@gmail.com wrote:
You can find some more discussion at
https://meta.wikimedia.org/wiki/Talk:Strategy/Wikimedia_movement/2018-20/Rec...
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, 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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
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 meta.sj@gmail.com 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 chriskeatingwiki@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 gtisza@gmail.com wrote:
You can find some more discussion at
https://meta.wikimedia.org/wiki/Talk:Strategy/Wikimedia_movement/2018-20/Rec...
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, 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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
-- Samuel Klein @metasj w:user:sj +1 617 529 4266 _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Hello, Why i'm recieving this message : Message not delivered There was a problem delivering your message to *donate@wikimedia.com*. See the technical details below.
* Mohammed Bachounda http://bachounda.com/* 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 jseddon@wikimedia.org 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 meta.sj@gmail.com 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 <
chriskeatingwiki@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 gtisza@gmail.com wrote:
You can find some more discussion at
https://meta.wikimedia.org/wiki/Talk:Strategy/Wikimedia_movement/2018-20/Rec...
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,
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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
-- Samuel Klein @metasj w:user:sj +1 617 529
4266
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
-- Seddon
*Senior Community Relations Specialist* *Advancement (Fundraising), Wikimedia Foundation* _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
It's donate@wikimedia.org.
On Thu, Jul 9, 2020, 19:05 Mohammed Bachounda bachounda@gmail.com wrote:
Hello, Why i'm recieving this message : Message not delivered There was a problem delivering your message to *donate@wikimedia.com*. See the technical details below.
- Mohammed Bachounda http://bachounda.com/*
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 jseddon@wikimedia.org 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 meta.sj@gmail.com 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 <
chriskeatingwiki@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 gtisza@gmail.com
wrote:
You can find some more discussion at
https://meta.wikimedia.org/wiki/Talk:Strategy/Wikimedia_movement/2018-20/Rec...
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,
<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@lists.wikimedia.org Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
-- Samuel Klein @metasj w:user:sj +1 617 529
4266
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
-- Seddon
*Senior Community Relations Specialist* *Advancement (Fundraising), Wikimedia Foundation* _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Yes it's - donation not working for me
* Mohammed Bachounda http://bachounda.com/* 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 william@wchan.hk wrote:
It's donate@wikimedia.org.
On Thu, Jul 9, 2020, 19:05 Mohammed Bachounda bachounda@gmail.com wrote:
Hello, Why i'm recieving this message : Message not delivered There was a problem delivering your message to *donate@wikimedia.com*.
See
the technical details below.
- Mohammed Bachounda http://bachounda.com/*
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 jseddon@wikimedia.org 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 meta.sj@gmail.com
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 <
chriskeatingwiki@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 gtisza@gmail.com
wrote:
You can find some more discussion at
https://meta.wikimedia.org/wiki/Talk:Strategy/Wikimedia_movement/2018-20/Rec...
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,
<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@lists.wikimedia.org Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org
?subject=unsubscribe>
-- Samuel Klein @metasj w:user:sj +1 617 529
4266
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
-- Seddon
*Senior Community Relations Specialist* *Advancement (Fundraising), Wikimedia Foundation* _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-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@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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
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 ladsgroup@gmail.com 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.
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, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
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 ad@huikeshoven.org 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 ladsgroup@gmail.com 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.
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, 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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
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 toddmallen@gmail.com 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 ad@huikeshoven.org 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 ladsgroup@gmail.com 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.
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, 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@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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
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... * 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 ladsgroup@gmail.com 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 toddmallen@gmail.com 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 ad@huikeshoven.org
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 ladsgroup@gmail.com 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.
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,
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@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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
-- 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, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
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 ladsgroup@gmail.com 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 toddmallen@gmail.com 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 ad@huikeshoven.org 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 ladsgroup@gmail.com 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.
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, 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@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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
-- 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, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
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 <benjaminikuta@gmail.com
:
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 ladsgroup@gmail.com 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 toddmallen@gmail.com 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 ad@huikeshoven.org
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 ladsgroup@gmail.com 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.
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
,
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@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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
-- 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,
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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
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, benjaminikuta@gmail.com 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 ladsgroup@gmail.com 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 toddmallen@gmail.com 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 ad@huikeshoven.org
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 ladsgroup@gmail.com 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.
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
,
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@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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
-- 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,
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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Thu, 9 Jul 2020 at 18:20, Amir Sarabadani ladsgroup@gmail.com 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
On Thu, 9 Jul 2020 at 21:15, Dan Garry (Deskana) djgwiki@gmail.com wrote:
ECR and GKE.
Correction: I meant GCR, not GKE.
Dan
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) djgwiki@gmail.com wrote:
On Thu, 9 Jul 2020 at 18:20, Amir Sarabadani ladsgroup@gmail.com 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, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
+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@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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
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@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@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@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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
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@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@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@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@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@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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
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@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@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@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@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@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@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@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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
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 jseddon@wikimedia.org 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 < vstavridoucoleman@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@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@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@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@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@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@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@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*
+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, < vstavridoucoleman@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@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@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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Hi Victoria,
I hope you're doing well. Please see below.
On Mon, Jul 20, 2020 at 12:19 PM Victoria Coleman vstavridoucoleman@gmail.com 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 legoktm@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@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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
wikimedia-l@lists.wikimedia.org