[Wikimedia-l] Re: [Commons-l] Re: Re: [Wikitech-l] Re: Uplifting the multimedia stack (was: Community Wishlist Survery)

[Chico Venancio]

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 
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 -- common...@lists.wikimedia.org
> To unsubscribe send an email to commons-l-le...@lists.wikimedia.org
>
___
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/PN3ADOXTXB32JWE5IYWLESFX5KDAB5TK/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: [Commons-l] Re: Re: [Wikitech-l] Re: Uplifting the multimedia stack (was: Community Wishlist Survery)

[Gnangarra]

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  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 -- common...@lists.wikimedia.org
> To unsubscribe send an email to commons-l-le...@lists.wikimedia.org
>


-- 
GN.
___
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/W6YRS4UII3H4H2SQHZWLBGUOBBC3C65H/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: [Commons-l] Re: Re: [Wikitech-l] Re: Uplifting the multimedia stack (was: Community Wishlist Survery)

[Gnangarra]

I see part of the problem is that the contributors experiencing the biggest
impact arent the same contributors that have the technical skill sets to
appropriately explain and understand the issues. Adding the the need to be
able to make comparisons between other areas of need just makes its even
more difficult.  None of us want to be putting forward arguments that say
that the WMF should neglect supporting Wikidata functions so that repairs
can be made to Commons functions, this is a loss for everyone.

I know that the experience of the volunteers who spent 3 months in limbo
trying to get the 2021 Wikimania videos converted and uploaded  will feed
back through to WMF hierarchy highlighting, but whether that taken has a
priority needing to be fixed or bug to swatted is unknown.  The underlying
issue isnt so much that we need to fix software(though we do) as it is that
we have structural problems in the way the WMF technical team interacts
with each project. With that its ability to keep with the growth and
maintenance necessary to function effectively.

The point I raised is that like many other aspects the software and
technical support along with its communication channels havent effectively
kept up with the needs of the community, not even the wishlist itself can
keep up with it.  This is why I said we need to pause and rethink the whole
process, focus on clearing whats on the phabricator while we do so.

The frustration comes from being able to upload a video to the likes of
youtube or vimeo in about 15-20 minutes, where as its takes 30 hours to
convert to webm on proprietary software which I have to pay for and then
10-12 attempts over the space of a week or two to upload the video to
commons.  The available tools like Videoconvertor, and Video2Commons are so
unstable that they dont survive the 30 hour conversion process.


On Sun, 2 Jan 2022 at 04:38, 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?
>
> 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  > > 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