(Speaking in my volunteer capacity) I doubt there is any malicious intent by WMF. I personally think the underlying problem is time. Let me explain.
Fixing a big issue in software takes time (I wrote a long essay about it in this thread) so it makes sense WMF annual planning to focus on issues before they get to a level that hinders community's work. The problem is that an issue doesn't get enough attention if it's not severe enough to affect users so the cycle of frustration continues. For example, I sent an email in February 2021, at the start of annual planning, to one of the directors at product outlining all of the issues of multimedia stack. Because at that point, it wasn't this bad, it didn't make it to FY21-22 plans. Now I feel like a cassandra. We have similar issues in lots of other places that will lead to frustration. Load balancers (pybal), dumps, beta cluster, flagged revs, patrolling tools, etc. etc.
On Tue, Jan 11, 2022 at 8:21 AM bawolff bawolff+wn@gmail.com wrote:
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/
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/
Amir
you raise a good point how do things get into the next budget, the simple answer is first to have people/teams responsible for each of the projects. Having someone accountable stops the ball being dropped as easily, it means WMF starts looking at needs on longer timetables. We've seen this with everything else the WMF does but not where it matters the most the points which each community relies on.
In the end we should go begging to WMF for platforms to maintained. nor should we be fighting against a wishlist gadgets just to get heard even when that list rejects us because its too big an issue.
On Tue, 11 Jan 2022 at 16:51, Amir Sarabadani ladsgroup@gmail.com wrote:
(Speaking in my volunteer capacity) I doubt there is any malicious intent by WMF. I personally think the underlying problem is time. Let me explain.
Fixing a big issue in software takes time (I wrote a long essay about it in this thread) so it makes sense WMF annual planning to focus on issues before they get to a level that hinders community's work. The problem is that an issue doesn't get enough attention if it's not severe enough to affect users so the cycle of frustration continues. For example, I sent an email in February 2021, at the start of annual planning, to one of the directors at product outlining all of the issues of multimedia stack. Because at that point, it wasn't this bad, it didn't make it to FY21-22 plans. Now I feel like a cassandra. We have similar issues in lots of other places that will lead to frustration. Load balancers (pybal), dumps, beta cluster, flagged revs, patrolling tools, etc. etc.
On Tue, Jan 11, 2022 at 8:21 AM bawolff bawolff+wn@gmail.com wrote:
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/
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/
-- Amir (he/him)
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
wikimedia-l@lists.wikimedia.org