Mailing List Archive

Re: [Wikimedia-l] Re: Re: Uplifting the multimedia stack (was: Community Wishlist Survery)
Hi Asaf,

That's a good response, but I'm not sure it provides a practical way
forward. How can volunteers bring this issue to the attention of the WMF
leadership to get the allocation of the time of Wikimedia staff who can
take ownership implement changes here?

Presumably emails on these lists have relatively little impact at the
most senior levels, so they aren't a good way forward - and similarly on
Phabricator.

The Wishlist provides a way of showcasing issues and a relatively clear
way forward to get them implemented, but with really limited capacity.

How would a case for technical support be made apart from that? It's not
clear if a simple survey would be sufficient. Would an RfC and
discussion on meta help? Does it need the media to be involved to make
it a public crisis? Or should it be proposed as a grant request, perhaps
for a Wikimedia affiliate to implement? Or is there another avenue that
could be persued? Bearing in mind that there's no practical way for
community members to propose changes to the WMF annual plan for multiple
years now.

Sorry to defocus things and express more frustration, but I think there
should be a clear way forward with this type of issue, which isn't
obvious right now. Personally, my hopes are on the Wishlist, although
I'll be reposting a 14-year-old issue there for the fifth time when that
process opens on the 10th January...

Thanks,
Mike

On 1/1/22 20:10:43, Asaf Bartov wrote:
> Writing in my volunteer capacity:
>
> On Sat, 1 Jan 2022, 08:43 Amir Sarabadani <ladsgroup@gmail.com
> <mailto:ladsgroup@gmail.com>> wrote:
>
>
> Honestly, the situation is more dire than you think. For example,
> until a couple months ago, we didn't have backups for the media
> files. There was a live copy in the secondary datacenter but for
> example if due to a software issue, we lost some files, they were
> gone. I would like to thank Jaime Crespo for pushing for it and
> implementing the backups.
>
> But I beat my drum again, it's not something you can fix overnight.
> I'm sure people are monitoring this mailing list and are aware of
> the problem.
>
>
> [.My goal in this post is to ficus effort and reduce frustration.]
>
> Yes, people reading here are aware, and absolutely none of them expects
> this (i.e. multimedia technical debt and missing features) to be fixed
> overnight.
>
> What's lacking, as you pointed out, is ownership of the problem.  To own
> the problem, one must have *both* technical understanding of the issues
> *and* a mandate to devote resources to addressing them.
>
> It is this *combination* that we don't have at the moment. Lots of
> technical people are aware, and some of them quite willing to work
> toward addressing the issues, but they are not empowered to set
> priorities and commit resources for an effort of that scale, and the
> problems, for the most part, don't easily lend themselves to volunteer
> development.
>
> 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.
>
> Therefore, the greatest contribution the rest of us could make toward
> seeing this work get resourced is to help make the case to the
> executives (including the new CEO, just entering the role) with clear
> and compelling illustrations of the *mission impact* of such investment.
> In parallel, interested engineers and middle managers could help by
> offering rough effort estimates for some components, a roadmap, an
> overview of alternatives considered and a rationale for a recommended
> approach, etc.
>
> But this would all be preparatory and supporting work toward *a
> resourcing decision* being made. So long as such a decision isn't made,
> no significant work on this can happen.
>
> Finally, while it is easy to agree that *this* is necessary and useful
> on its own, to actual resource it in the coming annual plan it would be
> necessary to argue that it is *more* useful and necessary than some
> *other* work, itself also necessary and useful.
>
> Another thing that may help is being explicit about just how important
> this is, even literally saying things like "this would have far more
> impact on our X goal than initiative A, B, or C", naming actual
> resourced or potentially resourced things. It is sometimes difficult for
> managers who aren't practicing Wikimedia volunteers to assess just how
> necessary different necessary things are, from different community
> perspectives.
>
> And of course, one such opinion, or a handful, would not be a solid base
> for resourcing decisions, so perhaps a large-scale ranking survey of
> some sort would be helpful, as SJ implicitly suggested in the original post.
>
> Cheers,
>
>     A.
>     (In my volunteer capacity)
>
> _______________________________________________
> 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/message/XQ2INJOXSLW76CQ7UXN5ZMIADUZM7HWI/
> To unsubscribe send an email to wikimedia-l-leave@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/
Re: [Commons-l] Re: [Wikimedia-l] Re: Re: Uplifting the multimedia stack (was: Community Wishlist Survery) [ In reply to ]
On 2022-01-01 21:37, Mike Peel wrote:
> Hi Asaf,
>
> That's a good response, but I'm not sure it provides a practical way
> forward. How can volunteers bring this issue to the attention of the
> WMF leadership to get the allocation of the time of Wikimedia staff
> who can take ownership implement changes here?

We have thousands of volunteers. And that's a problem. We wish
that we had millions of volunteers.

Even with only thousands of volunteers, bringing more things "to
the attention" of WMF leadership would be disasterous. The
solution must lie in the opposite direction: solving issues without
having to bring them to the attention of the top leadership.

This whole discussion reminds me of inefficiencies of the Soviet
economy. How can central planning be so inefficient? If only
Stalin or Brezhnev knew, he would put things straight, right?
How can we bring more details to the Kremlin's attention?

The western, non-communist approach is to empower
individuals to run enterprises without bringing everything to
the attention of the top leadership. In a free market economy.

But a market economy for us, must mean that resources are
allocated to those who are able to offer solutions that saves
resources for other volunteers. How can we do this without
paying actual money for the solutions? If your video upload
costs you dozens of hours, and I can design a solution that
saves your time, how can your saving benefit me? And after
the new solution is in place, free for all, how will anybody
know that it saves them dozens of hours? This is the big
question that we should focus on answering.



--
Lars Aronsson (lars@aronsson.se)
Linköping, Sweden

_______________________________________________
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/
Re: [Commons-l] Re: [Wikimedia-l] Re: Re: Uplifting the multimedia stack (was: Community Wishlist Survery) [ In reply to ]
One could argue market economy inevitably ends up in monopolies, similarly
projects drawing less attention or offering no short-term benefits die of
starvation. Fixing Wikidata technical weaknesses, for example, didn't draw
enough attention for years.

Vito


Il giorno lun 3 gen 2022 alle ore 02:22 Lars Aronsson <lars@aronsson.se> ha
scritto:

> On 2022-01-01 21:37, Mike Peel wrote:
> > Hi Asaf,
> >
> > That's a good response, but I'm not sure it provides a practical way
> > forward. How can volunteers bring this issue to the attention of the
> > WMF leadership to get the allocation of the time of Wikimedia staff
> > who can take ownership implement changes here?
>
> We have thousands of volunteers. And that's a problem. We wish
> that we had millions of volunteers.
>
> Even with only thousands of volunteers, bringing more things "to
> the attention" of WMF leadership would be disasterous. The
> solution must lie in the opposite direction: solving issues without
> having to bring them to the attention of the top leadership.
>
> This whole discussion reminds me of inefficiencies of the Soviet
> economy. How can central planning be so inefficient? If only
> Stalin or Brezhnev knew, he would put things straight, right?
> How can we bring more details to the Kremlin's attention?
>
> The western, non-communist approach is to empower
> individuals to run enterprises without bringing everything to
> the attention of the top leadership. In a free market economy.
>
> But a market economy for us, must mean that resources are
> allocated to those who are able to offer solutions that saves
> resources for other volunteers. How can we do this without
> paying actual money for the solutions? If your video upload
> costs you dozens of hours, and I can design a solution that
> saves your time, how can your saving benefit me? And after
> the new solution is in place, free for all, how will anybody
> know that it saves them dozens of hours? This is the big
> question that we should focus on answering.
>
>
>
> --
> Lars Aronsson (lars@aronsson.se)
> Linköping, Sweden
>
> _______________________________________________
> 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/
Re: [Wikimedia-l] Re: Re: Uplifting the multimedia stack (was: Community Wishlist Survery) [ In reply to ]
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/
Re: [Wikimedia-l] Re: Re: Uplifting the multimedia stack (was: Community Wishlist Survery) [ In reply to ]
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/
>
Re: [Wikimedia-l] Re: Re: Uplifting the multimedia stack (was: Community Wishlist Survery) [ In reply to ]
(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)
Re: [Commons-l] Re: [Wikimedia-l] Re: Re: Uplifting the multimedia stack (was: Community Wishlist Survery) [ In reply to ]
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
>
Re: [Commons-l] Re: [Wikimedia-l] Re: Re: Uplifting the multimedia stack (was: Community Wishlist Survery) [ In reply to ]
On Tue, 11 Jan 2022 at 12:17, Chico Venancio <chicocvenancio@gmail.com> wrote:
>
> 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.

As someone who has tried to contribute using some of my "Covid time",
and who will shortly be going back to real work, it's also deeply
frustrating if you cannot meaningfully contribute incrementally, but
run into a lack of interest in engaging with issues. If someone has
come along with even a half-decent bug report, it's possible that that
represents about an hour or so of work: detecting the bug, isolating
it, creating a Phab account, writing the report all take time. An hour
of time is actually a lot for someone who commutes to a 9 to 5, let
alone someone with family.

Now, if that person wants to _fix_ the bug, it took me, very
roughly[1], three working days to get to a position where I could even
run Mediawiki locally with the right extensions in Docker[2], figure
out the code, find out enough about PHP to make a change, actually
make the changes, and propose a patch for a simple issue, and respond
to the inevitable CI issues because you can't get the tests to work
locally. If I had been doing that in the time between getting home
from the office and making dinner, that's a month of work, and would
replace all my other interests into the bargain. It's _also_
frustrating when you then get the patch -1'd because you tried to
follow existing code, but that's actually old and busted and you
should use the new hotness that everyone inside the engineering team
might know, but is highly non-obvious to a person who only cloned the
repo on Monday. Every review response or rebase also takes a good
chunk of time, especially if the patch has "gone cold". And then
there's a good chance your it just rots on Gerrit anyway until you
have moved on with your life.

I think (making stuff up alert) a reason people want the WMF to help
here is not just because they collect more than the GDP of Nauru[3]
per year on the implication that they it supports the wikis, but also
because they actually employ people specifically because they _do_
know how to do this stuff effectively, and what is a month of
sacrificed hobbies for one poor sap is half an hour for them. That's a
hell of a force multiplier if there was just slack in the engineering
to allow it. Teach a man to fish and tomorrow he might help you repair
your jetty. Expect a man to figure out how to mine iron for fish hooks
on his own and reverse engineer a fishing rod, and he'll be hungry for
a good while and your jetty is going to stay broken if he wanders off
in search of something other than fish to eat.

Now, sure, you can say "well it's not the WMF's fault that you have a
job/family/commute/other hobbies/a herd of depressed pet llamas in
constant need of hugs, is it?" and yes, you are right, they don't
officially _owe_ anyone anything. However, it's also a shame to
completely write off the ability of llama-owners to contribute, unless
they're willing to put in more time or effort than very many people
have to spare. Honestly, if I hadn't had Covid time, I would have
given up on any patch after the first several hours and just walked
away[4]. And that would have been a shame for me (I'll let others
decide if it would be a shame for the software!)

So I guess the tl;dr here is that actually a relatively small amount
of care[5] from the WMF can multiply the effectiveness of outside
contributions greatly. Those contributions, in turn, can magnify the
ability of the Communities themselves to Get Content Done[6]. And
that's the aim here, is it not? We're all on the same side!

--IL

[1] I mean, what did time even mean in 2021, anyway?!
[2] Since then, Docker has gotten better, though I still can't get
Phan to work with any regularity, and it doesn't really feel like any
"staff" developers actually use the method described in
CONTRIBUTING.md to run up MediaWiki very often.
[3] Yes, really. To be fairrrr, it's a very small island.
[4] In fact, before Covid, I tried to do some patches and did exactly
that, more than once.
[5] Developer Advocacy is a team that exists, but at least in my
personal experience, I have never actually encountered it, except for
bug wrangling.
[6] Perfect example: ProofreadPage is pretty much entirely non-core
tech and yet has facilitated almost all work on Wikisource for a
decade. I'm not sure such a system could be written and deployed
today.
_______________________________________________
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/
Re: [Commons-l] Re: [Wikimedia-l] Re: Re: Uplifting the multimedia stack (was: Community Wishlist Survery) [ In reply to ]
I probably have the best understanding of the thumbnailing system
among volunteers at the moment, but I'm not interested in bailing out
the WMF on this one.

The fundamental purpose of the WMF is to support the continued
operation of the wikis by maintaining technical infrastructure. There
is not a single Wikimedia wiki that does not use Thumbor.
Nevertheless, maintenance was largely left to a single maintainer
working on Thumbor as a side project, in addition to their normal
responsibilities. That was a decision made or supported by WMF
management. When that single maintainer left the Foundation, there was
no one else to maintain the system.

Sure, I or other volunteers could get appropriate access and finish
off the Thumbor python3 and Debian migrations. But that just kicks the
can down the road instead of actually solving the problem. Maintenance
of a critical system would still be dependent on one person (or more
optimistically, a few people) working in their spare time with no plan
for continuity. That just puts us back to the position we were in a
year ago, which we now know is not sustainable.

Critical infrastructure not directly supported by a WMF team, with a
plan for continued maintenance if a core maintainer leaves, has been a
well-documented risk since before the WMF was created. Yet this is not
the first example of WMF management deferring maintenance from
production systems. In the case of Wikimedia Maps, a full production
outage was necessary before WMF management decided Maps was worth
maintaining. DPL echos a similar tale. What else has to fail before
WMF management starts taking this seriously?

ACN

On Tue, Jan 11, 2022 at 8:31 AM Inductiveload <inductiveload@gmail.com> wrote:
>
> On Tue, 11 Jan 2022 at 12:17, Chico Venancio <chicocvenancio@gmail.com> wrote:
> >
> > 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.
>
> As someone who has tried to contribute using some of my "Covid time",
> and who will shortly be going back to real work, it's also deeply
> frustrating if you cannot meaningfully contribute incrementally, but
> run into a lack of interest in engaging with issues. If someone has
> come along with even a half-decent bug report, it's possible that that
> represents about an hour or so of work: detecting the bug, isolating
> it, creating a Phab account, writing the report all take time. An hour
> of time is actually a lot for someone who commutes to a 9 to 5, let
> alone someone with family.
>
> Now, if that person wants to _fix_ the bug, it took me, very
> roughly[1], three working days to get to a position where I could even
> run Mediawiki locally with the right extensions in Docker[2], figure
> out the code, find out enough about PHP to make a change, actually
> make the changes, and propose a patch for a simple issue, and respond
> to the inevitable CI issues because you can't get the tests to work
> locally. If I had been doing that in the time between getting home
> from the office and making dinner, that's a month of work, and would
> replace all my other interests into the bargain. It's _also_
> frustrating when you then get the patch -1'd because you tried to
> follow existing code, but that's actually old and busted and you
> should use the new hotness that everyone inside the engineering team
> might know, but is highly non-obvious to a person who only cloned the
> repo on Monday. Every review response or rebase also takes a good
> chunk of time, especially if the patch has "gone cold". And then
> there's a good chance your it just rots on Gerrit anyway until you
> have moved on with your life.
>
> I think (making stuff up alert) a reason people want the WMF to help
> here is not just because they collect more than the GDP of Nauru[3]
> per year on the implication that they it supports the wikis, but also
> because they actually employ people specifically because they _do_
> know how to do this stuff effectively, and what is a month of
> sacrificed hobbies for one poor sap is half an hour for them. That's a
> hell of a force multiplier if there was just slack in the engineering
> to allow it. Teach a man to fish and tomorrow he might help you repair
> your jetty. Expect a man to figure out how to mine iron for fish hooks
> on his own and reverse engineer a fishing rod, and he'll be hungry for
> a good while and your jetty is going to stay broken if he wanders off
> in search of something other than fish to eat.
>
> Now, sure, you can say "well it's not the WMF's fault that you have a
> job/family/commute/other hobbies/a herd of depressed pet llamas in
> constant need of hugs, is it?" and yes, you are right, they don't
> officially _owe_ anyone anything. However, it's also a shame to
> completely write off the ability of llama-owners to contribute, unless
> they're willing to put in more time or effort than very many people
> have to spare. Honestly, if I hadn't had Covid time, I would have
> given up on any patch after the first several hours and just walked
> away[4]. And that would have been a shame for me (I'll let others
> decide if it would be a shame for the software!)
>
> So I guess the tl;dr here is that actually a relatively small amount
> of care[5] from the WMF can multiply the effectiveness of outside
> contributions greatly. Those contributions, in turn, can magnify the
> ability of the Communities themselves to Get Content Done[6]. And
> that's the aim here, is it not? We're all on the same side!
>
> --IL
>
> [1] I mean, what did time even mean in 2021, anyway?!
> [2] Since then, Docker has gotten better, though I still can't get
> Phan to work with any regularity, and it doesn't really feel like any
> "staff" developers actually use the method described in
> CONTRIBUTING.md to run up MediaWiki very often.
> [3] Yes, really. To be fairrrr, it's a very small island.
> [4] In fact, before Covid, I tried to do some patches and did exactly
> that, more than once.
> [5] Developer Advocacy is a team that exists, but at least in my
> personal experience, I have never actually encountered it, except for
> bug wrangling.
> [6] Perfect example: ProofreadPage is pretty much entirely non-core
> tech and yet has facilitated almost all work on Wikisource for a
> decade. I'm not sure such a system could be written and deployed
> today.
> _______________________________________________
> 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/
Re: [Wikimedia-l] Re: Re: Uplifting the multimedia stack (was: Community Wishlist Survery) [ In reply to ]
În mar., 11 ian. 2022 la 08:01, Kunal Mehta <legoktm@debian.org> a scris:
>
> 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.
>

Counterexample:
https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/message/G2QTRJFAUKLE45SFTFUHOOTOBR6G3DP3/
(this was the situation that I quoted in my first email on this thread
as the WMF refusing to even do reviews).

Maybe it's just the multimedia part that it's in this desperate
situation, but I can totally see volunteer developers getting
discouraged quickly if their patches are outright ignored.

Strainu
_______________________________________________
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/