There always be gaps in ownership and there will be some critical software
left to individuals to keep the lights on. It's an ideal we need to move
towards but we might never reach.
That being said, it really doesn't need to be this bad.
Here is a non-exhaustive list of critical tech currently in production
without any maintainers:
- All of the authorization stack (2FA, Central Auth (otherwise known as
SUL), authentication in mw, OAuth, etc.)
- All of the multimedia stack (from upload, to the video player, to the
mw file backend, media handler, metadata extraction, etc.)
- FlaggedRevs aka Pending changes, a critical tool in the workflow of
patrollers
- Abusefilter, the tool that prevents vandalism from being saved. I
can't stress how important this is.
- SecurePoll, critical to community resilience.
- Deletion workflow
- Mailman (mailing lists), the very same infra that is sending and
storing this email.
- User preferences
- Gadgets infra
- Beta cluster: The most important human testing infra before bugs hit
production.
- SpamBlacklist/TitleBlacklist
You can go and check: https://www.mediawiki.org/wiki/Developers/Maintainers
and https://phabricator.wikimedia.org/project/board/3144/query/open/ to see
frustrations and open requests for years.
And even if a software would have an owner, it used to be that the team was
under so much pressure to produce new things instead of maintenance that
the software would practically be without a maintainer (or worse, as even
volunteers couldn't unofficially take the role). I can example a few.
Am Mo., 17. Apr. 2023 um 02:51 Uhr schrieb Gerg? Tisza <gtisza@gmail.com>:
> 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.
> _______________________________________________
> 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/QT4X6VIKMCLCY4ADZYRRNWSG73W6XKJI/
> To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
--
Amir (he/him)
left to individuals to keep the lights on. It's an ideal we need to move
towards but we might never reach.
That being said, it really doesn't need to be this bad.
Here is a non-exhaustive list of critical tech currently in production
without any maintainers:
- All of the authorization stack (2FA, Central Auth (otherwise known as
SUL), authentication in mw, OAuth, etc.)
- All of the multimedia stack (from upload, to the video player, to the
mw file backend, media handler, metadata extraction, etc.)
- FlaggedRevs aka Pending changes, a critical tool in the workflow of
patrollers
- Abusefilter, the tool that prevents vandalism from being saved. I
can't stress how important this is.
- SecurePoll, critical to community resilience.
- Deletion workflow
- Mailman (mailing lists), the very same infra that is sending and
storing this email.
- User preferences
- Gadgets infra
- Beta cluster: The most important human testing infra before bugs hit
production.
- SpamBlacklist/TitleBlacklist
You can go and check: https://www.mediawiki.org/wiki/Developers/Maintainers
and https://phabricator.wikimedia.org/project/board/3144/query/open/ to see
frustrations and open requests for years.
And even if a software would have an owner, it used to be that the team was
under so much pressure to produce new things instead of maintenance that
the software would practically be without a maintainer (or worse, as even
volunteers couldn't unofficially take the role). I can example a few.
Am Mo., 17. Apr. 2023 um 02:51 Uhr schrieb Gerg? Tisza <gtisza@gmail.com>:
> 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.
> _______________________________________________
> 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/QT4X6VIKMCLCY4ADZYRRNWSG73W6XKJI/
> To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
--
Amir (he/him)