Perhaps i am hyperfocused on technical debt in the sense of improving the
abstractions used in mediawiki. The phrasing around sustainability
especially leads me in that direction. However, technical debt is certainly
a broad concept and can mean a lot of things.
The common thread in the examples you cited seem to be things that have
fallen through the ownership cracks. I'm not sure its the case that
engineers aren't incentivized to fix these, so much as there are no natural
engineers to be incentivized due to team structure (scribunto is an
exception but i would disagree with that task's inclusion for reasons that
get off topic). On the other hand, perhaps a different incentivization
structure would encourage people to branch out more.
I think it is especially telling that 3 (or 4 even) of these tasks are
multimedia related, given that wmf hasn't had a multimedia team in a very
long time [SDC does not count], and definitely not one focused on the
backend. There are quite a few multimedia related areas in desperate need
of love (it is 2023 and video uploads are limited to 4gb with the flakiest
upload process known to man).
It was also pointed out to me on irc, that many critical workflows in the
community depend on toolforge tools that have very limited volunteer
maintainership. A sort of
https://xkcd.com/2347/ situation. Just because
they're not "production" we often pretend they don't exist. Regardless
of
how we label them, in the end it doesn't make a difference to the end user,
and the fragility of that ecosystem is a form of technical debt that is
often overlooked.
So i guess it all depends on what is meant by "technical debt"
--
Brian
On Friday, April 14, 2023, Andre Klapper <aklapper(a)wikimedia.org> wrote:
On Thu, 2023-04-13 at 20:06 -0700, bawolff wrote:
"I
think there are lots of promising opportunities to incentivise
people to pay off technical debt and make our existing stack more
sustainable. Right now there are no incentives for engineers in
this regard."
Interesting. Personally to me, it can sometimes feel like we never
stop talking about technical debt. While I think paying off technical
debt is important, at times I feel like we've swung in the opposite
direction where we are essentially rewriting things for the sake of
rewriting things.
"Technical debt" spontaneously brings the following items to my little
mind. They should not be about rewriting but rather "maintenance":
* librsvg for SVG rendering is a five year old version:
https://phabricator.wikimedia.org/T193352 /
https://phabricator.wikimedia.org/T265549
* Graph extension on old Vega version 2.6.3: see subtasks of
https://phabricator.wikimedia.org/T292341
* Scribunto extension on old Lua version 5.1 (last 5.1.x release was
in 2012):
https://phabricator.wikimedia.org/T178146
* 3D extension on a five year old three.js library in
https://phabricator.wikimedia.org/T277930#7636129
* Removing the OpenStackManager extension from
wikitech.wm.org:
https://phabricator.wikimedia.org/T161553
* Removing WVUI from MediaWiki
core:
https://phabricator.wikimedia.org/T310244
* Replacing jsduck with JSDoc3 across all Wikimedia code bases:
https://phabricator.wikimedia.org/T138401
* Undeploy VipsScaler from Wikimedia wikis:
https://phabricator.wikimedia.org/T290759
*
https://phabricator.wikimedia.org/T151393 (a non-public task)
This is not a complete list. Plus there are also separate "waiting for
someone to make a decision" and "improving communicating & documenting
already-made decisions" categories which would be different lists.
Of course there might be valid reasons not to look into some of this
technical debt (other higher priorities, high risk, complexity, etc).
Cheers,
andre
--
Andre Klapper (he/him) | Bugwrangler / Developer Advocate
https://blogs.gnome.org/aklapper/
_______________________________________________
Wikitech-l mailing list -- wikitech-l(a)lists.wikimedia.org
To unsubscribe send an email to wikitech-l-leave(a)lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists
.wikimedia.org/