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