Hoi, There should be several mechanisms determining what work gets done. What Asaf describes is a budget based process. Another mechanism is centred around responsibility.
The granularity of responsibility does not negate that the buck stops at a certain level. When responsibility has no consequences, what follows is finger pointing. Management, board maintain that a budget is required and departments maintain that they have no budget. In the absence of risk control , it follows that risk can grow to potentially disastrous levels. This has been recognised for both Commons and Wikidata; there is no backup for Commons and the software that runs Wikidata has the potential to break its functionality. A complicating factor is the divide in functionality maintained by the WMF and what the community produces. For the latter there is no chain of responsibility. In addition to all this there is a sense of ownership and priority; WMF maintains Wikipedia with English Wikipedia as its focus. This is made worse by a "community" of self appointed experts who will not accept that results of the past will not predict what transpires in the future. As for the WMF board, I was a candidate for the board and was quickly told that board members do not define any agenda, they assess plans and results presented by the WMF. Health and money became an issue at my home, it is why I did not campaign for a seat. So how to move on. First, the WMF has to take ownership of the complete technical environment used by our communities. A security analysis is to be performed for the graded risks to our projects. Given ownership, it is no longer feasible for any level of management to hide behind budgets or lack of budgets. Once it is clear that a particular functionality is in danger of long term breakage, an initial project plan is to be published like was done for Wikidata. This provides awareness of the critical issues we face and it is a deciding argument for out of budget activities. It also provides arguments for realignment of priorities in existing budgets and provides the basis for overall refinement. Deciding what to do in the case of major breakage is relatively straight forward. It becomes problematic when minor breakage is to be considered, when it is only a small part of our community that suffers. WMF uses the agile approach and it has a mechanism called "user stories". So when something breaks or is likely to break, the question is what user stories are affected, how much of an impact it has on our public and how much impact it has on our editors. Once we gain a grip on what fails us, we can refine it by adding project and language as complicating factors. Thanks, GerardM .. PS happy new year On Sat, 1 Jan 2022 at 21:11, Asaf Bartov <asaf.bar...@gmail.com> wrote: > Writing in my volunteer capacity: > > On Sat, 1 Jan 2022, 08:43 Amir Sarabadani <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
_______________________________________________ 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/NLOGLZBH35ZVWXDGSPMJGJOZ4L2GAYS6/ To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
