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.bartov(a)gmail.com> wrote:
Writing in my volunteer capacity:
On Sat, 1 Jan 2022, 08:43 Amir Sarabadani <ladsgroup(a)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(a)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…
To unsubscribe send an email to wikimedia-l-leave(a)lists.wikimedia.org