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

[Amir Sarabadani]

This is not really about Selena's email but it's so nerdy I still want to
talk about what tech debt is and what it isn't.

The word tech debt at the beginning meant a very specific thing: When an
engineer takes a shortcut to deliver a feature faster. Daniel has a pretty
good essay on tech debt: https://www.mediawiki.org/wiki/The_Tech_Debt_Trap

But the term slowly became so overused that engineers used it to refer to
any invisible work they couldn't tie into a feature. At this point, people
refer to tech debt as the general maintenance practically. And that led to
non-tech people to slowly disregard maintenance work because everything is
tech debt now.

What tech debt is not (this is not a MECE list):

   - Keep the lights on: OS upgrades, security updates, hw maintenance,
   incidents, ...
   - Bitrot: The code stays the same but the underlying technology changes,
   the usage pattern changes, requirements changes, etc.
   - Over-engineering: This is way more common than you think. Building an
   overly complex palace that no one can maintain anymore because no one
   understands it and everyone is afraid to remove anything. This is sorta the
   opposite of tech debt, people spent more resources than they should and
   it's still hurting us.
   - Plain bad engineering: People make mistakes, typos are easily fixable
   while architectural mistakes are not, sometimes we know it because of
   hindsight, sometimes it was obvious from the beginning.
   - Limiting architecture: Many architectural decisions come in the form
   of trade-offs, a classic example is performance vs. security. If someone
   wants something and it's not possible due to architectural limitations, it
   doesn't necessarily mean a bad thing. We sacrificed something in favor of
   the other.
   - Code hygiene: Improvements on readability and maintainability of the
   code.
   - Scale/Performance/Security considerations: I have seen that people see
   a prototype and want it in Wikipedia right now. I understand it but any
   solution on such a large scale comes with all sorts of edge cases and
   hidden costs. People bash MediaWiki for being too complex and messy but
   anything you build at the scale of Wikipedia is going to be complex and
   messy. If a solution takes years, sometimes that's the only option.

What I want to say is that while we do have a tech debt problem in
Wikimedia, we also have a lot of bitrot problems too, or any other "slowing
down development" kind of problem. Some cases it's fixable, in some cases
it is not. What is needed is more resources on maintenance which is
happening and is making me extremely happy. Whether we call that paying
back tech debt or not.


Am Fr., 14. Apr. 2023 um 23:44 Uhr schrieb Brian Wolff :

> Perhaps i am hyperfocused on technical debt in the sense of improving the
> abstractions used in mediawiki. The phrasing around sustainability
> especially leads me in that direction. However, technical debt is certainly
> a broad concept and can mean a lot of things.
>
> The common thread in the examples you cited seem to be things that have
> fallen through the ownership cracks. I'm not sure its the case that
> engineers aren't incentivized to fix these, so much as there are no natural
> engineers to be incentivized due to team structure (scribunto is an
> exception but i would disagree with that task's inclusion for reasons that
> get off topic). On the other hand, perhaps a different incentivization
> structure would encourage people to branch out more.
>
> I think it is especially telling that 3 (or 4 even) of these tasks are
> multimedia related, given that wmf hasn't had a multimedia team in a very
> long time [SDC does not count], and definitely not one focused on the
> backend. There are quite a few multimedia related areas in desperate need
> of love (it is 2023 and video uploads are limited to 4gb with the flakiest
> upload process known to man).
>
>
> It was also pointed out to me on irc, that many critical workflows in the
> community depend on toolforge tools that have very limited volunteer
> maintainership. A sort of https://xkcd.com/2347/ situation. Just because
> they're not "production" we often pretend they don't exist. Regardless of
> how we label them, in the end it doesn't make a difference to the end user,
> and the fragility of that ecosystem is a form of technical debt that is
> often overlooked.
>
>
> So i guess it all depends on what is meant by "technical debt"
> --
> Brian
>
> On Friday, April 14, 2023, Andre Klapper  wrote:
>
>> On Thu, 2023-04-13 at 20:06 -0700, bawolff wrote:
>> > > "I think there are lots of promising opportunities to incentivise
>> > > people to pay off technical debt and make our existing stack more
>> > > sustainable. Right now there are no incentives for engineers in
>> > > this regard."
>> >
>> > Interesting. Personally to me, it can sometimes feel like we never
>> > stop talking about technical debt. While I think paying off technical
>> > debt

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

[Gnangarra]

Hi Brian


> (it is 2023 and video uploads are limited to 4gb with the flakiest upload
> process known to man).


I'm not so troubled by the 4GB limit if you look at
https://commons.wikimedia.org/wiki/Category:Wikimania_2021_Building_1_sessions
those are stil substancial and important videos lsrgest file is 2.6gb and
its a 70 minute presentation.  a small step to 5GB or even 7 GB would be
more than enough in the short term, if there was a team supporting
multimedia then these larger event videos could be loaded via a bypass
through an internal support process as it'd be just for major events.

Its the flakiest and unreliable train service of converting to webm then
uploading that is the major block which needs to be addressed in the
immediate term.

What gets sacrificed at the altar of funding to bring multimedia to
forefront of priorities, I have seen waste in some of the strategy
development areas but recent events have reduced that to bring the overall
budget back.  Perhaps dipping into that future fund should be on the cards
with no multimedia the movement will be left behind and any catchup will
cost even more.



>
On Sat, 15 Apr 2023 at 05:44, Brian Wolff  wrote:

> Perhaps i am hyperfocused on technical debt in the sense of improving the
> abstractions used in mediawiki. The phrasing around sustainability
> especially leads me in that direction. However, technical debt is certainly
> a broad concept and can mean a lot of things.
>
> The common thread in the examples you cited seem to be things that have
> fallen through the ownership cracks. I'm not sure its the case that
> engineers aren't incentivized to fix these, so much as there are no natural
> engineers to be incentivized due to team structure (scribunto is an
> exception but i would disagree with that task's inclusion for reasons that
> get off topic). On the other hand, perhaps a different incentivization
> structure would encourage people to branch out more.
>
> I think it is especially telling that 3 (or 4 even) of these tasks are
> multimedia related, given that wmf hasn't had a multimedia team in a very
> long time [SDC does not count], and definitely not one focused on the
> backend. There are quite a few multimedia related areas in desperate need
> of love (it is 2023 and video uploads are limited to 4gb with the flakiest
> upload process known to man).
>
>
> It was also pointed out to me on irc, that many critical workflows in the
> community depend on toolforge tools that have very limited volunteer
> maintainership. A sort of https://xkcd.com/2347/ situation. Just because
> they're not "production" we often pretend they don't exist. Regardless of
> how we label them, in the end it doesn't make a difference to the end user,
> and the fragility of that ecosystem is a form of technical debt that is
> often overlooked.
>
>
> So i guess it all depends on what is meant by "technical debt"
> --
> Brian
>
> On Friday, April 14, 2023, Andre Klapper  wrote:
>
>> On Thu, 2023-04-13 at 20:06 -0700, bawolff wrote:
>> > > "I think there are lots of promising opportunities to incentivise
>> > > people to pay off technical debt and make our existing stack more
>> > > sustainable. Right now there are no incentives for engineers in
>> > > this regard."
>> >
>> > Interesting. Personally to me, it can sometimes feel like we never
>> > stop talking about technical debt. While I think paying off technical
>> > debt is important, at times I feel like we've swung in the opposite
>> > direction where we are essentially rewriting things for the sake of
>> > rewriting things.
>>
>> "Technical debt" spontaneously brings the following items to my little
>> mind. They should not be about rewriting but rather "maintenance":
>>
>>  * librsvg for SVG rendering is a five year old version:
>>https://phabricator.wikimedia.org/T193352 /
>>https://phabricator.wikimedia.org/T265549
>>  * Graph extension on old Vega version 2.6.3: see subtasks of
>>https://phabricator.wikimedia.org/T292341
>>  * Scribunto extension on old Lua version 5.1 (last 5.1.x release was
>>in 2012): https://phabricator.wikimedia.org/T178146
>>  * 3D extension on a five year old three.js library in
>>https://phabricator.wikimedia.org/T277930#7636129
>>  * Removing the OpenStackManager extension from wikitech.wm.org:
>>https://phabricator.wikimedia.org/T161553
>>  * Removing WVUI from MediaWiki
>>core: https://phabricator.wikimedia.org/T310244
>>  * Replacing jsduck with JSDoc3 across all Wikimedia code bases:
>>https://phabricator.wikimedia.org/T138401
>>  * Undeploy VipsScaler from Wikimedia wikis:
>>https://phabricator.wikimedia.org/T290759
>>  * https://phabricator.wikimedia.org/T151393 (a non-public task)
>>
>> This is not a complete list. Plus there are also separate "waiting for
>> someone to make a decision" and "improving communicating & documenting
>> already-made decisions" categories which would be different lists.
>>
>> Of course there might be valid

[Wikimedia-l] Re: Wiki Loves Monuments 2022 award ceremony announcement

[Olga Viota]

Thanks for share the news!

El vie., 14 de abril de 2023 2:59 p. m., Ndahiro Derrick Alter <
ndahiroder...@gmail.com> escribió:

> Thanks for updates Ciell , I am eagerly waiting for the winning photos for
> 2022 😍
>
> On Fri, 14 Apr 2023 at 19:13 Ciell Wikipedia 
> wrote:
>
>> Hi everyone,
>>
>> I am excited to share with you that next Tuesday April 18, the winners of
>> Wiki Loves Monuments 2022 will be announced.
>> Wiki Loves Monuments is a federated photo competition around built
>> heritage, which is held annually since 2010.
>>
>> As always, we'll be hosting our award ceremony through our social media
>> channels on Twitter  and Instagram
>> , where we will have a
>> countdown from the number 25 to number 1.
>> We have scheduled two countdown windows: we will announce the honorary
>> mentions on Monday April 17, starting at 6pm UTC with number 25 and
>> counting down to number 16 at 10.30pm, announcing one image per 30 minutes.
>> We'll have a little break after that and will return with the number 15 at
>> 7am on Tuesday April 18 and again announcing one winner per half hour, to
>> finish with the celebration of the international winner of Wiki Loves
>> Monuments 2022 at 2pm UTC.
>>
>> Please keep an eye out for our posts, and join us in admiring these
>> beautiful images of built heritage around the world, and congratulating the
>> winners.
>> A gallery with all the winning photos will be published on our own blog
>>  and on the WMF Diff site
>> afterwards.
>>
>> Our thanks go to the national organisers, the national juries and, of
>> course, the 2022 WLM international jury, without whom none of this would
>> have been possible.
>>
>> On behalf of the Wiki Loves Monuments international organising team,
>>
>> Best,
>> Ciell
>> ___
>> 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/RMJ3JJGCHZQUKLO6P63FMNN6JZ3P7OXY/
>> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
>
> --
> derrick
> ___
> 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/2DDBU3FTOYHO7TWD4L4IZECMRMED7JU7/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
___
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/A4ESHTW2BWWNECEICJU2AA5VL5MLTSNX/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

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

[Brian Wolff]

Perhaps i am hyperfocused on technical debt in the sense of improving the
abstractions used in mediawiki. The phrasing around sustainability
especially leads me in that direction. However, technical debt is certainly
a broad concept and can mean a lot of things.

The common thread in the examples you cited seem to be things that have
fallen through the ownership cracks. I'm not sure its the case that
engineers aren't incentivized to fix these, so much as there are no natural
engineers to be incentivized due to team structure (scribunto is an
exception but i would disagree with that task's inclusion for reasons that
get off topic). On the other hand, perhaps a different incentivization
structure would encourage people to branch out more.

I think it is especially telling that 3 (or 4 even) of these tasks are
multimedia related, given that wmf hasn't had a multimedia team in a very
long time [SDC does not count], and definitely not one focused on the
backend. There are quite a few multimedia related areas in desperate need
of love (it is 2023 and video uploads are limited to 4gb with the flakiest
upload process known to man).


It was also pointed out to me on irc, that many critical workflows in the
community depend on toolforge tools that have very limited volunteer
maintainership. A sort of https://xkcd.com/2347/ situation. Just because
they're not "production" we often pretend they don't exist. Regardless of
how we label them, in the end it doesn't make a difference to the end user,
and the fragility of that ecosystem is a form of technical debt that is
often overlooked.


So i guess it all depends on what is meant by "technical debt"
--
Brian

On Friday, April 14, 2023, Andre Klapper  wrote:

> On Thu, 2023-04-13 at 20:06 -0700, bawolff wrote:
> > > "I think there are lots of promising opportunities to incentivise
> > > people to pay off technical debt and make our existing stack more
> > > sustainable. Right now there are no incentives for engineers in
> > > this regard."
> >
> > Interesting. Personally to me, it can sometimes feel like we never
> > stop talking about technical debt. While I think paying off technical
> > debt is important, at times I feel like we've swung in the opposite
> > direction where we are essentially rewriting things for the sake of
> > rewriting things.
>
> "Technical debt" spontaneously brings the following items to my little
> mind. They should not be about rewriting but rather "maintenance":
>
>  * librsvg for SVG rendering is a five year old version:
>https://phabricator.wikimedia.org/T193352 /
>https://phabricator.wikimedia.org/T265549
>  * Graph extension on old Vega version 2.6.3: see subtasks of
>https://phabricator.wikimedia.org/T292341
>  * Scribunto extension on old Lua version 5.1 (last 5.1.x release was
>in 2012): https://phabricator.wikimedia.org/T178146
>  * 3D extension on a five year old three.js library in
>https://phabricator.wikimedia.org/T277930#7636129
>  * Removing the OpenStackManager extension from wikitech.wm.org:
>https://phabricator.wikimedia.org/T161553
>  * Removing WVUI from MediaWiki
>core: https://phabricator.wikimedia.org/T310244
>  * Replacing jsduck with JSDoc3 across all Wikimedia code bases:
>https://phabricator.wikimedia.org/T138401
>  * Undeploy VipsScaler from Wikimedia wikis:
>https://phabricator.wikimedia.org/T290759
>  * https://phabricator.wikimedia.org/T151393 (a non-public task)
>
> This is not a complete list. Plus there are also separate "waiting for
> someone to make a decision" and "improving communicating & documenting
> already-made decisions" categories which would be different lists.
>
> Of course there might be valid reasons not to look into some of this
> technical debt (other higher priorities, high risk, complexity, etc).
>
> Cheers,
> andre
>
> --
> Andre Klapper (he/him) | Bugwrangler / Developer Advocate
> https://blogs.gnome.org/aklapper/
> ___
> Wikitech-l mailing list -- wikitec...@lists.wikimedia.org
> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists
> .wikimedia.org/
___
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/BZP2SHMGT4KYUJ4DPIUVMTZRJEW5QXGE/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: Wiki Loves Monuments 2022 award ceremony announcement

[Ndahiro Derrick Alter]

Thanks for updates Ciell , I am eagerly waiting for the winning photos for
2022 😍

On Fri, 14 Apr 2023 at 19:13 Ciell Wikipedia 
wrote:

> Hi everyone,
>
> I am excited to share with you that next Tuesday April 18, the winners of
> Wiki Loves Monuments 2022 will be announced.
> Wiki Loves Monuments is a federated photo competition around built
> heritage, which is held annually since 2010.
>
> As always, we'll be hosting our award ceremony through our social media
> channels on Twitter  and Instagram
> , where we will have a
> countdown from the number 25 to number 1.
> We have scheduled two countdown windows: we will announce the honorary
> mentions on Monday April 17, starting at 6pm UTC with number 25 and
> counting down to number 16 at 10.30pm, announcing one image per 30 minutes.
> We'll have a little break after that and will return with the number 15 at
> 7am on Tuesday April 18 and again announcing one winner per half hour, to
> finish with the celebration of the international winner of Wiki Loves
> Monuments 2022 at 2pm UTC.
>
> Please keep an eye out for our posts, and join us in admiring these
> beautiful images of built heritage around the world, and congratulating the
> winners.
> A gallery with all the winning photos will be published on our own blog
>  and on the WMF Diff site afterwards.
>
> Our thanks go to the national organisers, the national juries and, of
> course, the 2022 WLM international jury, without whom none of this would
> have been possible.
>
> On behalf of the Wiki Loves Monuments international organising team,
>
> Best,
> Ciell
> ___
> 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/RMJ3JJGCHZQUKLO6P63FMNN6JZ3P7OXY/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

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

[Wikimedia-l] Re: The Board Sister Project Faskforce is looking for the voluntary advisory members

[Samuel Klein]

Wonderful to see this.

On Fri, Apr 14, 2023 at 11:16 AM Victoria Doronina 
wrote:

> Dear all,
>
> I am writing on behalf of the Community Affairs Committee of the Wikimedia
> Foundation Board of Trustees [1] to invite you to work with us as a Volunteer
> Advisory Member of the Board’s newest task force–the Sister Projects Task
> Force. The Sister Projects Task Force will be a group of community
> members and Foundation trustees working together on a strategy to support
> the life cycle of non-Wikipedia projects across the movement.
>
> The Community Affairs Committee charter calls on addressing “the review of
> the existing sister projects and new sister site applications, including
> creating a formalized procedure, from application to approval/rejection”
> [2] as one of the responsibilities of the Committee. We are forming the
> Sister Projects Task Force to deliver on this commitment. This Task Force
> will create processes to support the development of sister projects, which
> enrich and expand the way we share knowledge with the world.
>
> We need your expertise to make this happen. We welcome applicants from
> different sister projects, regions and languages, bringing different
> perspectives to the table. You can read more about the selection process
> and apply to join us on Meta [3]. Apply until 15 May 2023.
>
> Please share this email with anyone you think may be interested in
> applying.
>
> Best regards,
>
> Victoria Doronina
>
> Wikimedia Foundation trustee, Lead of the Wikimedia Foundation Board
> Sister Projects Task Force (SiPTaF)
>
> [1]
> https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Community_Affairs_Committee
>
> [2]
> https://foundation.wikimedia.org/wiki/Community_Affairs_Committee_Charter#Responsibilities
>
> [3]
> https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Community_Affairs_Committee/Sister_Projects_Task_Force
>
>
> --
>  Victoria Doronina
>   Trustee
>
> Wikimedia Foundation 
>
> Imagine a world in which every single human being can freely share in the
> sum of all knowledge. Help us make it a reality.
> ___
> 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/ZRV7MGHF4IH6LCN3DF6FF6IFMHXJTXZO/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org



-- 
Samuel Klein  @metasj   w:user:sj  +1 617 529 4266
___
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/NNLJGKDTHCXVMSYAYWKDGVL6XL3WO6D4/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Wiki Loves Monuments 2022 award ceremony announcement

[Ciell Wikipedia]

Hi everyone,

I am excited to share with you that next Tuesday April 18, the winners of
Wiki Loves Monuments 2022 will be announced.
Wiki Loves Monuments is a federated photo competition around built
heritage, which is held annually since 2010.

As always, we'll be hosting our award ceremony through our social media
channels on Twitter  and Instagram
, where we will have a
countdown from the number 25 to number 1.
We have scheduled two countdown windows: we will announce the honorary
mentions on Monday April 17, starting at 6pm UTC with number 25 and
counting down to number 16 at 10.30pm, announcing one image per 30 minutes.
We'll have a little break after that and will return with the number 15 at
7am on Tuesday April 18 and again announcing one winner per half hour, to
finish with the celebration of the international winner of Wiki Loves
Monuments 2022 at 2pm UTC.

Please keep an eye out for our posts, and join us in admiring these
beautiful images of built heritage around the world, and congratulating the
winners.
A gallery with all the winning photos will be published on our own blog
 and on the WMF Diff site afterwards.

Our thanks go to the national organisers, the national juries and, of
course, the 2022 WLM international jury, without whom none of this would
have been possible.

On behalf of the Wiki Loves Monuments international organising team,

Best,
Ciell
___
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/RMJ3JJGCHZQUKLO6P63FMNN6JZ3P7OXY/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

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

[Andre Klapper]

On Thu, 2023-04-13 at 20:06 -0700, bawolff wrote:
> > "I think there are lots of promising opportunities to incentivise
> > people to pay off technical debt and make our existing stack more
> > sustainable. Right now there are no incentives for engineers in
> > this regard."
> 
> Interesting. Personally to me, it can sometimes feel like we never
> stop talking about technical debt. While I think paying off technical
> debt is important, at times I feel like we've swung in the opposite
> direction where we are essentially rewriting things for the sake of
> rewriting things.

"Technical debt" spontaneously brings the following items to my little
mind. They should not be about rewriting but rather "maintenance":

 * librsvg for SVG rendering is a five year old version:
   https://phabricator.wikimedia.org/T193352 /
   https://phabricator.wikimedia.org/T265549
 * Graph extension on old Vega version 2.6.3: see subtasks of
   https://phabricator.wikimedia.org/T292341
 * Scribunto extension on old Lua version 5.1 (last 5.1.x release was
   in 2012): https://phabricator.wikimedia.org/T178146
 * 3D extension on a five year old three.js library in
   https://phabricator.wikimedia.org/T277930#7636129
 * Removing the OpenStackManager extension from wikitech.wm.org:
   https://phabricator.wikimedia.org/T161553
 * Removing WVUI from MediaWiki
   core: https://phabricator.wikimedia.org/T310244
 * Replacing jsduck with JSDoc3 across all Wikimedia code bases:
   https://phabricator.wikimedia.org/T138401
 * Undeploy VipsScaler from Wikimedia wikis:
   https://phabricator.wikimedia.org/T290759
 * https://phabricator.wikimedia.org/T151393 (a non-public task)

This is not a complete list. Plus there are also separate "waiting for
someone to make a decision" and "improving communicating & documenting
already-made decisions" categories which would be different lists.

Of course there might be valid reasons not to look into some of this
technical debt (other higher priorities, high risk, complexity, etc).

Cheers,
andre

-- 
Andre Klapper (he/him) | Bugwrangler / Developer Advocate
https://blogs.gnome.org/aklapper/
___
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/CPV223QA263TSB6MHOM4IGKMREWS4EKV/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: May 12⋮14⋮17 >> Queering Wikipedia 2023 Conference

[Željko Blaće]

On Thu, Apr 13, 2023 at 10:38 AM Victoria Doronina 
wrote:

> Hello Zeljko,
>
> I see that this is the second call for proposals. Are you interested in
> the Board representation on the conference?  For example, a Q and A session?
>

Yes we are interested, but ideally not quite as loose as just Q&A session.
It would be good to know who of the Board members could commit
to both dates of conference and would be able to speak in regards
to their specific work and responsibilities, rather than to keep it generic
as are regular Board online consultation hours.
Could we discuss this in an online call next week with Board members
who are interested and would have something specific to share?

Best Z. Blace

Best
>
> VIctoria
>
> On Wed, Apr 12, 2023 at 10:01 PM Željko Blaće  wrote:
>
>> In the countdown to the last 30 days to QW2023
>> we will be publishing updates on our
>> event plans, program, participants,
>> information and inspiration
>> to join us.
>> Also
>> please consider
>> to spread the word
>> follow our socials/federate
>> https://wikis.world/@QueeringW
>> https://meta.wikimedia.org/wiki/QW2023/Volunteer
>>
>> Z. Blace - for QW2023 organizing team
>> ___
>> 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/3UTRFR3LG732QM2YW6LG3HFTVXQRK3VQ/
>> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
>>
> ___
> 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/V4Q3DPKZUJDTW7NDHODMM3E44T7TDCRQ/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
___
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/VFEFTOJ6HLPFI6B4G3THRHVHTOAIAKSD/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] The Board Sister Project Faskforce is looking for the voluntary advisory members

[Victoria Doronina]

Dear all,

I am writing on behalf of the Community Affairs Committee of the Wikimedia
Foundation Board of Trustees [1] to invite you to work with us as a Volunteer
Advisory Member of the Board’s newest task force–the Sister Projects Task
Force. The Sister Projects Task Force will be a group of community members
and Foundation trustees working together on a strategy to support the life
cycle of non-Wikipedia projects across the movement.

The Community Affairs Committee charter calls on addressing “the review of
the existing sister projects and new sister site applications, including
creating a formalized procedure, from application to approval/rejection”
[2] as one of the responsibilities of the Committee. We are forming the
Sister Projects Task Force to deliver on this commitment. This Task Force
will create processes to support the development of sister projects, which
enrich and expand the way we share knowledge with the world.

We need your expertise to make this happen. We welcome applicants from
different sister projects, regions and languages, bringing different
perspectives to the table. You can read more about the selection process
and apply to join us on Meta [3]. Apply until 15 May 2023.

Please share this email with anyone you think may be interested in applying.

Best regards,

Victoria Doronina

Wikimedia Foundation trustee, Lead of the Wikimedia Foundation Board Sister
Projects Task Force (SiPTaF)

[1]
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Community_Affairs_Committee

[2]
https://foundation.wikimedia.org/wiki/Community_Affairs_Committee_Charter#Responsibilities

[3]
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Community_Affairs_Committee/Sister_Projects_Task_Force


-- 
 Victoria Doronina
  Trustee

Wikimedia Foundation 

Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us make it a reality.
___
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/ZRV7MGHF4IH6LCN3DF6FF6IFMHXJTXZO/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] upcoming collaboration around the Wikimedia Foundation's annual plan

[Kelsi Stine-Rowe]

Dear All,

As noted in past messages

[1], the Wikimedia Foundation will release a draft of its annual plan for
the July 2023 - June 2024 fiscal year on Meta-Wiki

[2] next week to begin planning collectively with the Wikimedia movement.
Some auxiliary materials, such as the Product and Technology buckets

[3] and objectives and key results

[4] as well as our research on external trends

[5] are already available.

We want to invite all Wikimedians to share their inputs, thoughts,
priorities and work with us to plan together. There will be opportunities
to collaborate on-wiki and during live conversations. More information is
available here

[6].

Best,

Kelsi Stine-Rowe

[1]
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Chief_Executive_Officer/Updates/Year_One_Update

[2]
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024

[3]
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/Draft/Product_%26_Technology

[4]
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/Draft/Product_%26_Technology/OKRs

[5]
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/Draft/External_Trends
[6]
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/Collaboration

-- 

Kelsi Stine-Rowe (she/her)

Senior Project Manager

Wikimedia Foundation 

"Imagine a world in which every single human being can freely share in the
sum of all knowledge. That's our commitment."
___
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/PUQQFAFPDZV5BOTIMGCM6KGOV47VDWU7/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org