Far from a pipe dream, a strategy of keeping useful functionality maintained and working through known problems, sounds like a much better use of IT resource than one of neglecting deployed software to prioritise the latest fads.
WSC On Mon, 17 Apr 2023, 1:04 pm , <wikimedia-l-requ...@lists.wikimedia.org> > > 1. Re: [Wikitech-l] Re: Reflecting on my listening tour (Gergő Tisza) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 16 Apr 2023 17:50:57 -0700 > From: Gergő Tisza <gti...@gmail.com> > Subject: [Wikimedia-l] Re: [Wikitech-l] Re: Reflecting on my listening > tour > To: Wikimedia Mailing List <wikimedia-l@lists.wikimedia.org> > Message-ID: > < > caevcxn0ra1t9erczymurd-prc4psrl_tt26z1twmvthzatc...@mail.gmail.com> > Content-Type: multipart/alternative; > boundary="0000000000006a8f6905f97d969b" > > On Sat, Apr 15, 2023 at 7:49 AM AntiCompositeNumber < > anticompositenum...@gmail.com> wrote: > > > Agreed. It has long been the case that infrastructure critical to the > > operation of the various wikis has been left without a clear > > maintainer, or has been maintained only in the volunteer time of a > > single staffer already fulfilling a full-time role. Teams would be > > dissolved or reassigned to completely different projects after > > completion, without the ability and/or willingness to even review > > patches. That assumes that the team doing the work wasn't made up of > > contractors who departed the Foundation when the project was > > "completed", taking their knowledge of it with them. > > > > This was a major factor in causing the technical debt problem, and > > must be addressed to have any chance of solving it. > > > > At some point we will have to admit that we have created a feature set many > times larger than we have the capacity to actively maintain and improve. > Either we make software development cheaper somehow (move the WMF to > Romania or something), or we cut some of the non-software spending (but we > already spend 50%+ of movement funds on software, and we'd have to increase > capacity way more than by a factor of two to maintain all our code), or we > undeploy most current features, or we'll have to put up with most things > being unmaintained, which is the status quo. That's not to say we can't be > smarter about it (e.g. microservices are a great way to have maintenance > overhead spin even more out of control) or that maintenance efforts > couldn't be better prioritized (e.g. the lack of maintainership of our > authentication stack is somewhat wild), but fundamentally changing the > current mode of operation (where most things are deployed and > then abandoned to work on the next thing) is a pipe dream IMO. > -------------- next part -------------- > A message part incompatible with plain text digests has been removed ... > Name: not available > Type: text/html > Size: 2167 bytes > Desc: not available > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > 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/ > To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org > > > ------------------------------ > > End of Wikimedia-l Digest, Vol 788, Issue 1 > ******************************************* >
_______________________________________________ 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/OWHMBGNMGZVPAQJ2FNE24ZWKEAPCM6PP/ To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
