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 <em...@mikepeel.net> 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 <ladsgr...@gmail.com > > <mailto:ladsgr...@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-le...@lists.wikimedia.org > _______________________________________________ > 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/YMNOHZ2MJBLZVTXURTPJ2L5ANVZUOE47/ To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
