Hi,
On 1/1/22 12:10, Asaf Bartov wrote:
It seems to me there are *very few* people who could change status quo, not much more than a handful: the Foundation's executive leadership (in its annual planning work, coming up this first quarter of 2022), and the Board of Trustees.
If the goal is to get paid WMF staff to fix the issues, then you're correct. However, I do not believe that as a solution is healthy long-term. The WMF isn't perfect and I don't think it's desirable to have a huge WMF that tries to do everything and has a monopoly on technical prioritization.
The technical stack must be co-owned by volunteers and paid staff from different orgs at all levels. It's significantly more straightforward now for trusted volunteers to get NDA/deployment access than it used to be, there are dedicated training sessions, etc.
Given that the multimedia stack is neglected and the WMF has given no indication it intends to work on/fix the problem, we should be recruiting people outside the WMF's paid staff who are interested in working on this and give them the necessary access/mentorship to get it done. Given the amount of work on e.g. T40010[1] to develop an alternative SVG renderer, I'm sure those people exist.
Take moving Thumbor to Buster[2] for example. That requires forward-porting some Debian packages written Python, and then testing in WMCS that there's no horrible regressions in newer imagemagick, librsvg, etc. I'm always happy to mentor people w/r to Debian packaging (and have done so in the past), and there are a decent amount of people in our community who know Python, and likely others from the Commons community who would be willing to help with testing and dealing with whatever fallout.
So I think the status quo can be changed by just about anyone who is motivated to do so, not by trying to convince the WMF to change its prioritization, but just by doing the work. We should be empowering those people rather than continuing to further entrench a WMF technical monopoly.
[1] https://phabricator.wikimedia.org/T40010 [2] https://phabricator.wikimedia.org/T216815
-- Legoktm
Its one thing allowing access and supporting volunteers, its another to be abrogating it's responsibility to ensure the stable running of the projecst for which its collecting millions of dollars in donations every year.
WMF key purpose is to provide the infrastructure need for every project to operate, at the moment there is no apparent effort from the WMF to do that for Wikimedia Commons despites it being the vital source for every projects multimedia. This isnt one off missed opportunity, its failed in that responsibility for year after year and now we as contributors are baring the fruits of that neglect.
On Tue, 11 Jan 2022 at 14:01, Kunal Mehta legoktm@debian.org wrote:
Hi,
On 1/1/22 12:10, Asaf Bartov wrote:
It seems to me there are *very few* people who could change status quo, not much more than a handful: the Foundation's executive leadership (in its annual planning work, coming up this first quarter of 2022), and the Board of Trustees.
If the goal is to get paid WMF staff to fix the issues, then you're correct. However, I do not believe that as a solution is healthy long-term. The WMF isn't perfect and I don't think it's desirable to have a huge WMF that tries to do everything and has a monopoly on technical prioritization.
The technical stack must be co-owned by volunteers and paid staff from different orgs at all levels. It's significantly more straightforward now for trusted volunteers to get NDA/deployment access than it used to be, there are dedicated training sessions, etc.
Given that the multimedia stack is neglected and the WMF has given no indication it intends to work on/fix the problem, we should be recruiting people outside the WMF's paid staff who are interested in working on this and give them the necessary access/mentorship to get it done. Given the amount of work on e.g. T40010[1] to develop an alternative SVG renderer, I'm sure those people exist.
Take moving Thumbor to Buster[2] for example. That requires forward-porting some Debian packages written Python, and then testing in WMCS that there's no horrible regressions in newer imagemagick, librsvg, etc. I'm always happy to mentor people w/r to Debian packaging (and have done so in the past), and there are a decent amount of people in our community who know Python, and likely others from the Commons community who would be willing to help with testing and dealing with whatever fallout.
So I think the status quo can be changed by just about anyone who is motivated to do so, not by trying to convince the WMF to change its prioritization, but just by doing the work. We should be empowering those people rather than continuing to further entrench a WMF technical monopoly.
[1] https://phabricator.wikimedia.org/T40010 [2] https://phabricator.wikimedia.org/T216815
-- Legoktm _______________________________________________ Commons-l mailing list -- commons-l@lists.wikimedia.org To unsubscribe send an email to commons-l-leave@lists.wikimedia.org
Honestly, I find the "not in the annual plan" thing more damning than the actual issue at hand.
The core competency of WMF is supposed to be keeping the site running. WMF does a lot of things, some of them very useful, others less so, but at its core its mission is to keep the site going. Everything else should be secondary to that.
It should be obvious that running a 300 TB+ media store servicing 70 billion requests a month requires occasional investment and maintenance
And yet, this was not only not in this year's annual plan, it has been ignored in the annual plan for many many years. We didn't get to this state by just 1 year of neglect.
Which raises the question - If wmf is not in the business of keeping the Wikimedia sites going, what is it in the business of?
On Tue, Jan 11, 2022 at 6:01 AM Kunal Mehta legoktm@debian.org wrote:
Hi,
On 1/1/22 12:10, Asaf Bartov wrote:
It seems to me there are *very few* people who could change status quo, not much more than a handful: the Foundation's executive leadership (in its annual planning work, coming up this first quarter of 2022), and the Board of Trustees.
If the goal is to get paid WMF staff to fix the issues, then you're correct. However, I do not believe that as a solution is healthy long-term. The WMF isn't perfect and I don't think it's desirable to have a huge WMF that tries to do everything and has a monopoly on technical prioritization.
The technical stack must be co-owned by volunteers and paid staff from different orgs at all levels. It's significantly more straightforward now for trusted volunteers to get NDA/deployment access than it used to be, there are dedicated training sessions, etc.
Given that the multimedia stack is neglected and the WMF has given no indication it intends to work on/fix the problem, we should be recruiting people outside the WMF's paid staff who are interested in working on this and give them the necessary access/mentorship to get it done. Given the amount of work on e.g. T40010[1] to develop an alternative SVG renderer, I'm sure those people exist.
Take moving Thumbor to Buster[2] for example. That requires forward-porting some Debian packages written Python, and then testing in WMCS that there's no horrible regressions in newer imagemagick, librsvg, etc. I'm always happy to mentor people w/r to Debian packaging (and have done so in the past), and there are a decent amount of people in our community who know Python, and likely others from the Commons community who would be willing to help with testing and dealing with whatever fallout.
So I think the status quo can be changed by just about anyone who is motivated to do so, not by trying to convince the WMF to change its prioritization, but just by doing the work. We should be empowering those people rather than continuing to further entrench a WMF technical monopoly.
[1] https://phabricator.wikimedia.org/T40010 [2] https://phabricator.wikimedia.org/T216815
-- Legoktm _______________________________________________ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
I agree a bit with both Kunal and Asaf here,
I do not think our goal is to get it done **by paid WMF staff**, but it is also true that today that is the only viable alternative to get major technical work done. I do not think it is entirely fair to state that "status quo can be changed by just about anyone who is motivated to do so (...) just by doing the work". It is not a lack of motivation that hinders our movement technically, but a lack of resources and shared governance. I am not sure if the implication is that the movement should be expecting free (expensive) labor to fix these issues, but even then there is a very high bar for engagement with the technical community in order to have access and a significant bottleneck in both technical review of changes and engagement with technical and other communities for changes that impact them.
It is not only unfair to expect this to be solved by volunteer developers, it is not working. Why should we expect this will change?
Open source and accepting volunteer contributions is nowhere near where our goal should be. We need better governance and distribution of resources and responsibilities to volunteer **and professional** organizations that can bridge the gaps in our technological stack.
How we move from a state where WMF is doing all the technical development and deciding technical choices is a bigger issue. And perhaps it is in that issue that we will find an answer on how to improve the state of our tech ecosystem. How do we get from a WMF-centered development model to a decentralized one?
It is a bit disappointing the lack of emphasis our movement placed in this discussion in our strategy process thus far; and how we have set aside the little that did make to the recommendations in this area since they were published.
Chico Venancio
Em ter., 11 de jan. de 2022 às 03:01, Kunal Mehta legoktm@debian.org escreveu:
Hi,
On 1/1/22 12:10, Asaf Bartov wrote:
It seems to me there are *very few* people who could change status quo, not much more than a handful: the Foundation's executive leadership (in its annual planning work, coming up this first quarter of 2022), and the Board of Trustees.
If the goal is to get paid WMF staff to fix the issues, then you're correct. However, I do not believe that as a solution is healthy long-term. The WMF isn't perfect and I don't think it's desirable to have a huge WMF that tries to do everything and has a monopoly on technical prioritization.
The technical stack must be co-owned by volunteers and paid staff from different orgs at all levels. It's significantly more straightforward now for trusted volunteers to get NDA/deployment access than it used to be, there are dedicated training sessions, etc.
Given that the multimedia stack is neglected and the WMF has given no indication it intends to work on/fix the problem, we should be recruiting people outside the WMF's paid staff who are interested in working on this and give them the necessary access/mentorship to get it done. Given the amount of work on e.g. T40010[1] to develop an alternative SVG renderer, I'm sure those people exist.
Take moving Thumbor to Buster[2] for example. That requires forward-porting some Debian packages written Python, and then testing in WMCS that there's no horrible regressions in newer imagemagick, librsvg, etc. I'm always happy to mentor people w/r to Debian packaging (and have done so in the past), and there are a decent amount of people in our community who know Python, and likely others from the Commons community who would be willing to help with testing and dealing with whatever fallout.
So I think the status quo can be changed by just about anyone who is motivated to do so, not by trying to convince the WMF to change its prioritization, but just by doing the work. We should be empowering those people rather than continuing to further entrench a WMF technical monopoly.
[1] https://phabricator.wikimedia.org/T40010 [2] https://phabricator.wikimedia.org/T216815
-- Legoktm _______________________________________________ Commons-l mailing list -- commons-l@lists.wikimedia.org To unsubscribe send an email to commons-l-leave@lists.wikimedia.org