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

that entails? My impression is that we don't have one. All we hear is "it needs to be planned", but there is no transparency on what that planning involves or when it actually happens. The main problem I see is that we end up in this kind of situation. Scaling and bug fixing critical features should be part of the annual budget. Each line of code deployed to production wikis should have an owner and associated maintenance budget each year. Without this, the team will not even commit reviews - see the thread on wikitech a few months back where a volunteer programmer willing to work on Upload Wizard was basically told "We will not review your code. Go fork." Also improvements to the Upload Wizard. There are quite a few open items in Phab on this. I really hope you will have better luck than others with bringing this issue up in the priority list for next year - multimedia support is growing more outdated by the minute. Strainu Pe joi, 30 decembrie 2021, Samuel Klein <meta.sj(a)gmail.com> a scris: possibly in isolation?) may not be the mechanism for prioritizing large changes, but the latter also deserves a community-curated priority queue. To complement the staff-maintained priorities in phab ~ surprised if the bottleneck were people or budget. We do need a shared understanding of what issues are most important and most urgent, and how to solve them. For instance, a way to turn Amir's recent email about the problem (and related phab tickets) into a family of persistent, implementable specs and proposals and their articulated obstacles. dependencies of agreed-upon tasks, but weak for discussing what is important, what we know about it, how to address it. And weak for discussing ecosystem-design issues that are important and need persistent updating but don't have a simple checklist of steps. that entails? Some examples from recent discussions (most from the wm-l thread below): online file formats wrote: for multimedia stack. I myself wrote a detailed rant on how broken it is [1] but three notes: for it (which means it has to be done during the annual planning) and if gets approved, you need to start it with the fiscal year (meaning July 2022) and then hire (meaning, write JD, do recruitment, interview lots of people, get them hired) which can take from several months to years. Once they are hired, you need to onboard them and let them learn about our technical infrastructure which takes at least two good months. Software engineering is not magic, it takes time, blood and sweat. [2] budget, OKR, etc. etc. Are we sure moving the focus of teams is a good idea? Most teams are already focusing on vital parts of wikimedia and changing the focus will turn this into a whack-a-mole game where we fix multimedia but now we have critical issues in security or performance. least address the worst parts for now. make requests for improvements in multimedia in the wishlist survey or you think it's not. If you think it's not, then it's offtopic to this thread. https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org… essential functions like uploading files which is the core mission of Wikimedia Commons