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-request@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 <gtisza@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_tT26Z1twmvTHzaTchDg@mail.gmail.com>
> Content-Type: multipart/alternative;
> boundary="0000000000006a8f6905f97d969b"
>
> On Sat, Apr 15, 2023 at 7:49?AM AntiCompositeNumber <
> anticompositenumber@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-leave@lists.wikimedia.org
>
>
> ------------------------------
>
> End of Wikimedia-l Digest, Vol 788, Issue 1
> *******************************************
>
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-request@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 <gtisza@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_tT26Z1twmvTHzaTchDg@mail.gmail.com>
> Content-Type: multipart/alternative;
> boundary="0000000000006a8f6905f97d969b"
>
> On Sat, Apr 15, 2023 at 7:49?AM AntiCompositeNumber <
> anticompositenumber@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-leave@lists.wikimedia.org
>
>
> ------------------------------
>
> End of Wikimedia-l Digest, Vol 788, Issue 1
> *******************************************
>