Got to agree there. P
From: WereSpielChequers [mailto:werespielchequers@gmail.com]
Sent: 17 April 2023 14:50
To: Wikimedia Mailing List
Subject: [Wikimedia-l] Re: reflecting on my Wiki tour
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
*******************************************
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
Virus-free. <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> www.avg.com
From: WereSpielChequers [mailto:werespielchequers@gmail.com]
Sent: 17 April 2023 14:50
To: Wikimedia Mailing List
Subject: [Wikimedia-l] Re: reflecting on my Wiki tour
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
*******************************************
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
Virus-free. <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> www.avg.com