It seems a death spiral is possible here:
- We look at our seemingly overwhelming mountain of tech debt, and declare ourselves without sufficient resources
- Tech debt accumulates, with fewer and fewer voluntary collaborators being involved, because life is too short to deal with the mountain of some else's tech debt
- We get lower funding, because we don't seem to be accomplishing as much as we used to
It may be that the name ("Quality") is poorly chosen, as it leads to this death spiral thinking. It may be that we should think reframe this as "Developer Experience" in a nod to @Sherah (WMF)'s earlier comment. In what ways can we make improving our code safer and more fun? How can we improve the motivation for people not paid by WMF to improve the code we deploy? Are WMF employees the only people that can possibly understand how many of our deployed systems work?
In our recent IRC conversation on this topic (Phab:E269), we talked about how it's important to use the Dev Summit as a place to discuss tech debt issues. @Legoktm pointed out "I think it is important that we don't lose the architecture part of the summit. Most of our day-to-day work/priorities are dictated by the products (in the user-facing sense) that we work on, and the summit is the one of the few places we get to work on the actual architecture/tech-debt" Let's spend some of our time figuring out how to pay down our tech debt.
As far as the "who pays for it?" topic, let's get each team working on new features to account for how they are going to clean up messes in their environment. Let's get out of the habit of hand-wringing about our current plight, imagining ourselves lying in filth (possibly self-created), whining about how someone else is not offering to clean up the environment we operate in.
Thankfully, MediaWiki isn't "filth", it's actually very good software that has served the movement well. We have a really good problem to solve: improve the software running on a website that is already in the global top 10. Not everything in it is written as we would write it from scratch today, but many of the people who built the original versions are still working with us and can teach us how they did it, and help us avoid making the mistakes they made. We can use this as an opportunity to celebrate our collective achievement; that we have something good enough to improve. Let's make sure that the product of future improvement will be something worthy of more improvement.