[Wikimedia-l] Re: [Wikitech-l] Re: Reflecting on my listening tour

2023-04-17 Thread Dan Garry (Deskana) 
I agree with much of what Amir has said here, except one little bit...

On Mon, 17 Apr 2023 at 20:52, Amir Sarabadani  wrote:

> 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.
>

I think pressure on a team to deliver new things is *one* reason why this
situation has come about, but it's far from being the only one. Here's a
few others off the top of my head:

   - Owning so many things that even if there was zero pressure to deliver
   new features, the team still couldn't maintain everything that they own.
   - Incredibly powerful and incredibly complex features that teams are
   afraid of touching lest they break them and make community members angry.
   - Conservatism and fear of community outrage causing reluctance to
   deprecate functionality.
   - Lack of understanding of the impact of the feature.
   - Lack of a clear roadmap (a list of bug reports and feature requests is
   not a roadmap).

There's more but those are some that come to the top of my head. And, not
everyone one of those always applies to every situation, e.g. I definitely
don't think all of the items in your list should be deprecated!

This causes the path of least resistance to be, for everyone involved, to
leave things in limbo and hope for the best.

Dan
___
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/Y4YKOLNJKWAUQFNOVMZSKDSZRORSWFNB/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] You are invited to the conversation hour with Community Resilience and Sustainability

2023-04-17 Thread Jackie Koerner 
Hi all,

You are invited to the quarterly Conversation hour led by Maggie Dennis,
Vice President of Community Resilience and Sustainability, on May 2, 2023
at 18:00 UTC .

Maggie and others from the team will discuss Trust and Safety, the
Universal Code of Conduct, Committee Support, and Human Rights.

If you are a Wikimedian in good standing (not Foundation or community
banned), write to let us know you will be attending the conversation and
share your questions. More information about attending this conversation
hour

and notes from previous conversation hours can be found on Meta-wiki
.

Best,
-- 

Jackie Koerner (she/her) Communication Specialist, Community Resilience and
Sustainability Location: Midwestern US (UTC-5/Daylight savings UTC-6)

Wikimedia Foundation 
___
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/WZDBEYDCHIFQO4KNSAU3XJEB6DDDHW64/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: [Wikitech-l] Re: Reflecting on my listening tour

2023-04-17 Thread Amir Sarabadani 
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 :

> 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.
> ___
> 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-le...@lists.wikimedia.org



-- 
Amir (he/him)
___
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/L5A4MWM6HS6U3EVNORVIFMR3NQT7O6V5/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: reflecting on my Wiki tour

2023-04-17 Thread Peter Southwood 
Got to agree there. P

 

From: WereSpielChequers [mailto:werespielchequ...@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 ,  


   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 
Subject: [Wikimedia-l] Re: [Wikitech-l] Re: Reflecting on my listening
tour
To: Wikimedia Mailing List 
Message-ID:

Content-Type: multipart/alternative;
boundary="6a8f6905f97d969b"

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
***

 


 

 

Virus-free. 

 www.avg.com

 

___
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/5PDNAPWLYXTX3UUEVR6EMBKOTDNHOMEZ/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: reflecting on my Wiki tour

2023-04-17 Thread WereSpielChequers 
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 , 

>
>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 
> Subject: [Wikimedia-l] Re: [Wikitech-l] Re: Reflecting on my listening
> tour
> To: Wikimedia Mailing List 
> Message-ID:
> <
> caevcxn0ra1t9erczymurd-prc4psrl_tt26z1twmvthzatc...@mail.gmail.com>
> Content-Type: multipart/alternative;
> boundary="6a8f6905f97d969b"
>
> 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