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 <bawolff@gmail.com> 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 <aklapper@wikimedia.org> 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 -- wikitech-l@lists.wikimedia.org
>> To unsubscribe send an email to wikitech-l-leave@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-leave@lists.wikimedia.org
--
Boodarwun
Gnangarra
'ngany dabakarn koorliny arn boodjera dardoon ngalang Nyungar koortaboodjar'
> (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 <bawolff@gmail.com> 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 <aklapper@wikimedia.org> 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 -- wikitech-l@lists.wikimedia.org
>> To unsubscribe send an email to wikitech-l-leave@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-leave@lists.wikimedia.org
--
Boodarwun
Gnangarra
'ngany dabakarn koorliny arn boodjera dardoon ngalang Nyungar koortaboodjar'