[Wikimedia-l] Re: [Commons-l] Uplifting the multimedia stack (was: Community Wishlist Survery)

[Željko Blaće]

On Mon, Jan 3, 2022 at 11:10 PM F. Xavier Dengra i Grau via Wikimedia-l <
wikimedia-l@lists.wikimedia.org> wrote:

> It is definitely so sad to see those many abandoned tickets in
> Phabricator, like the ones Galder has been sharing along this thread. The
> same for the very interesting -and quite easy to implement- proposals that
> had lots of votes in the previous Community Wishlists but that never
> succeeded.
>

Hey Havier, I agree. Many do. Community Wishlists has its limitations and
unfortunately it was historically not super clear of what can (not) be done
and how. Check my initial rent on this. It is now on a good path not to
promise too much to too many people
#WMcommunityWishlistNotPANACEAnorEXTRACTIVISM ;-)


> It is difficult to convince users in some Village Pumps to participate in
> the new Community Wishlists, as the improvements that we see do not relate
> much with many of the language-related needs. Not to mention what's going
> on with the sister projects: for Wikiquote or Wikibooks it has been crystal
> clear for the small communities that we are merely server-supported,
> without any other special, significant improvement foreseen nor for the
> past decade nor for the years to come. I feel often insulted when I see the
> "scary" banners to push people to donate in this small wiki projects -in
> which we barely can provide contents with an interface of 2008.
>

This is a much shared feeling. Only quirky proposal I can imagine right now
is for the 'Wikimedia movement' to 'forbid' WMF use of anything but
MediaWiki for its outward facing PR, so even the PR department would have
to look at UI and deal with the same urgency as everyone else using it
onWiki projects ;-) #jokeNOjoke


> Necessary and valuable tech proposals for our poor infrastructure are
> completely left behind while the WMF is publishing press releases about a
> 120-million $ revenue. Meanwhile, some wikipedians increasingly take
> advantage of this big money as an opportunity to convert their hobby into a
> job by asking more and more grants in Meta to do paid-editing, WiRs or
> "cultural" projects (that before were fully succesfully
> volunteered-driven). Priorities and the consequences of having too much
> money.
>

We do not know each other but obviously some concerns are shared. I would
love you to come to the next WREN meeting and check out the folx to meet
there.
Most of us feel similar, but have different realities and possibilities for
agency. As (often non-developers) GLAM folx are doing what is their best
possible contribution.
Mind you many WiRs bring in both value and finances where WMF did not. In
Croatia there was zero investment for 18 years and first (+ still most
significant) was done by the Clubture.org, a 20 years old grassroot network
of independent cultural operators (including workshops in early pandemic
when WMF halted everything) which in its own right struggles with
sustainability and (Wikipedia) recognition ;-) So rather than
under-informed antagonizing, please consider joining us for the next WREN
meeting and lets see what can be done better in coordination or maybe even
future collaboration.

Best Z. Blace


Xavier Dengra
>
> Sent with ProtonMail  Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> El dilluns, 3 de gener 2022 a les 9:44 PM, Galder Gonzalez Larrañaga <
> galder...@hotmail.com> va escriure:
>
> I would like to be optimistic, but...
> https://phabricator.wikimedia.org/T289101
>
> 2022(e)ko urt. 3(a) 15:28 erabiltzaileak hau idatzi du (Brion Vibber <
> bvib...@wikimedia.org>):
>
> (Anyway I'm just grumping. I hear positive things about plans for this
> year and I'm heartened to see more folks involved in planning the next
> stages!)
>
> -- brion
>
> On Mon, Jan 3, 2022, 6:10 AM Brion Vibber  wrote:
>
> On Thu, Dec 30, 2021, 10:27 AM Samuel Klein  wrote:
>
> Separate thread.  I'm not sure which list is appropriate.
> *... but not all the way to sentience
> .*
>
> The annual community wishlist survey (implemented by a small team,
> possibly in isolation?) may not be the mechanism for prioritizing large
> changes, but the latter also deserves a community-curated priority queue.
> To complement the staff-maintained priorities in phab ~
>
> For core challenges (like Commons stability and capacity), I'd be
> surprised if the bottleneck were people or budget.
>
>
> Currently there are zero people and no budget for multimedia, aside from
> whatever work I and others manage to get done here there. And I'm afraid I
> don't scale.
>
> It's Wikimedia Foundation's job to assign budget and people here. I've
> been hoping for years that this will happen, and continue to hope.
>
>
> -- brion
>
> We do need a shared understanding of what issues are most important and
> most urgent, and how to solve them. For instance, a way to turn Amir's
> recent email about the problem (and related phab tickets) into a family of
> persistent, 

[Wikimedia-l] Re: [Commons-l] Uplifting the multimedia stack (was: Community Wishlist Survery)

[Yaroslav Blanter]

On Mon, Jan 3, 2022 at 11:09 PM F. Xavier Dengra i Grau via Wikimedia-l <
wikimedia-l@lists.wikimedia.org> wrote:

> Not to mention what's going on with the sister projects: for Wikiquote or
> Wikibooks it has been crystal clear for the small communities that we are
> merely server-supported, without any other special, significant improvement
> foreseen nor for the past decade nor for the years to come. I feel often
> insulted when I see the "scary" banners to push people to donate in this
> small wiki projects -in which we barely can provide contents with an
> interface of 2008.
>

On Wikivoyage, we get zero technical support from the WMF. Just none The
above map issue is an illustration of the problem. Whatever we can do, we
do ourselves (sometimes there is coordination between different languages,
sometimes not). Whaever we can not do ourselves is just not getting done.

Best
Yaroslav



> ‐‐‐ Original Message ‐‐‐
> El dilluns, 3 de gener 2022 a les 9:44 PM, Galder Gonzalez Larrañaga <
> galder...@hotmail.com> va escriure:
>
> I would like to be optimistic, but...
> https://phabricator.wikimedia.org/T289101
>
> 2022(e)ko urt. 3(a) 15:28 erabiltzaileak hau idatzi du (Brion Vibber <
> bvib...@wikimedia.org>):
>
> (Anyway I'm just grumping. I hear positive things about plans for this
> year and I'm heartened to see more folks involved in planning the next
> stages!)
>
> -- brion
>
> On Mon, Jan 3, 2022, 6:10 AM Brion Vibber  wrote:
>
> On Thu, Dec 30, 2021, 10:27 AM Samuel Klein  wrote:
>
> Separate thread.  I'm not sure which list is appropriate.
> *... but not all the way to sentience
> .*
>
> The annual community wishlist survey (implemented by a small team,
> possibly in isolation?) may not be the mechanism for prioritizing large
> changes, but the latter also deserves a community-curated priority queue.
> To complement the staff-maintained priorities in phab ~
>
> For core challenges (like Commons stability and capacity), I'd be
> surprised if the bottleneck were people or budget.
>
>
> Currently there are zero people and no budget for multimedia, aside from
> whatever work I and others manage to get done here there. And I'm afraid I
> don't scale.
>
> It's Wikimedia Foundation's job to assign budget and people here. I've
> been hoping for years that this will happen, and continue to hope.
>
>
> -- brion
>
> We do need a shared understanding of what issues are most important and
> most urgent, and how to solve them. For instance, a way to turn Amir's
> recent email about the problem (and related phab tickets) into a family of
> persistent, implementable specs and proposals and their articulated
> obstacles.
>
> An issue tracker like phab is good for tracking the progress and
> dependencies of agreed-upon tasks, but weak for discussing what is
> important, what we know about it, how to address it. And weak for
> discussing ecosystem-design issues that are important and need persistent
> updating but don't have a simple checklist of steps.
>
> So where is the best current place to discuss scaling Commons, and all
> that entails?  Some examples from recent discussions (most from the wm-l
> thread below):
> - *Uploads*: Support for large file uploads / Keeping bulk upload tools
> online
> - *Video*: Debugging + rolling out the videojs
>  player
> - *Formats*: Adding support for CML
>  and dozens of other
>  common high-demand file
> formats
> - *Thumbs*: Updating thumbor 
> and librsvg 
> - *Search*: WCQS still  down
> , noauth option
>  wanted for tools
> - *General*: Finish implementing redesign
>  of the image table
>
> SJ
>
> On Wed, Dec 29, 2021 at 6:26 AM Amir Sarabadani 
> wrote:
>
> I'm not debating your note. It is very valid that we lack proper support
> for multimedia stack. I myself wrote a detailed rant on how broken it is
> [1] but three notes:
>  - Fixing something like this takes time, you need to assign the budget
> for it (which means it has to be done during the annual planning) and if
> gets approved, you need to start it with the fiscal year (meaning July
> 2022) and then hire (meaning, write JD, do recruitment, interview lots of
> people, get them hired) which can take from several months to years. Once
> they are hired, you need to onboard them and let them learn about our
> technical infrastructure which takes at least two good months. Software
> engineering is not magic, it takes time, blood and sweat. [2]
>  - Making another team focus on multimedia requires changes in planning,
> budget, OKR, etc. etc. Are we sure moving the focus of teams is a 

[Wikimedia-l] Re: Is (Wikipedian-in-residence, a proposal) to update?

[Željko Blaće]

On Tue, Jan 4, 2022 at 6:33 AM Samuel Klein  wrote:

> ZB -- Just seeing this excellent idea.  Yes, it is a good time to revisit
> and envision what might be possible if this were a much broader and more
> universal practice, with a wide range of templates.
>

Glad to hear you think so. Few people in the WREN list also expressed
interest so maybe we start in the upcoming meeting?


> I would suggest combining it with a global scholarship program for younger
> students -- a multilingual internationally known wikimedia scholarship
> program, with matching funds and support via regional partners, would
> elevate the principles, the focus on improving public knowledge, and the
> practice of self-organization and learning-by-participating that makes us
> tick.
>

OK - I did not hear of it, but curious for sure.

Best Z. Blace


> SJ
>
> On Wed, Dec 22, 2021 at 1:28 AM Željko Blaće  wrote:
>
>> Before this last 21st day in the 21st year of 21st century
>> is globally over, I try to re-initiate re-thinking
>> on this 15 years old proposal for a Wikipedian-in-residence
>>
>> http://original-research.blogspot.com/2006/12/wikipedian-in-residence-proposal.html
>> but also articles in (only) 27 language Wikipedias,
>>
>> Meta, Outreach wiki and elsewhere
>> for updating the notion of WIR and roles it performs in Wikimedia,
>> an ecosystem of diverse entities, dynamics and relations.
>>
>> As Wikimedians with wider perspective than a single wiki project, often
>> more than a single language and for sure more than single community, gear
>> up to discuss and act on 2030 strategy, that includes new initiatives, new
>> formations of decentering resources, new content, forms and methods of
>> working, with new priorities, conditions, tools, services and what
>> not…there is also a value in reflecting and reimagining what is already
>> established but often overlooked practice.
>>
>> Some of the WIR practitioners have been self-reflecting on and off
>> publicly https://wikistrategies.net/5-things-wikipedian-in-residence/
>> and engaging with communities https://www.youtube.com/watch?v=tc9YgFm2eso
>> there was also network establishment.
>> 3 years ago WREN UG (Wikimedians in Residence Exchange Network User
>> Group) was recognized with the aim to protect the common elements of the
>> role and for creating a peer support network of new and experienced WIRs
>> for collaboration and to encourage a global professional environment which
>> inspires institutions to appoint persons to engage with Wikimedia.
>>
>> In recent times Wikipedian-in-Residence, is more often
>> Wikimedian-in-Residence, in rapid growth of Commons and Wikidata (but also
>> in 2021 first one in Wiktionary) and sometimes Wikimedian-at-Large, in more
>> generalized practice of strategy or direction setting work.
>> Additionally in time of pandemic when doing physical events is
>> challenging and many of the (potential) partner organizations are closing
>> down or limiting public events to bare essential, short and transient it is
>> more important than ever that individuals (rather than cohorts of editathon
>> enthusiasts) keep revisiting institutions and work with them in a most
>> flexible mode and scale.
>>
>> Finally to start both re-visioning and maybe even re-positioning WIRs in
>> Wikimedia we should think of what this network of ‘free agents’ can bring
>> towards 2030, beyond what WMF, affiliates, UGs, HUBs, WikiProjects and
>> other organizational forms can. Also think how much more useful this
>> initial inspiration of artists, writers and researchers in residence could
>> be if these creative and critical roles in the art and cultural sector get
>> embraced and encouraged more often and more intentionally.
>>
>> Z. Blace
>> ___
>> 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/LLPODGYR7UVIP2KESHKUPJK2QR7MYYMK/
>> 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/B2CIMUXQDLD4VS2XJBE7QVL2HTTP3IKN/
> 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 

[Wikimedia-l] Re: Is (Wikipedian-in-residence, a proposal) to update?

[Samuel Klein]

ZB -- Just seeing this excellent idea.  Yes, it is a good time to revisit
and envision what might be possible if this were a much broader and more
universal practice, with a wide range of templates.

I would suggest combining it with a global scholarship program for younger
students -- a multilingual internationally known wikimedia scholarship
program, with matching funds and support via regional partners, would
elevate the principles, the focus on improving public knowledge, and the
practice of self-organization and learning-by-participating that makes us
tick.

SJ

On Wed, Dec 22, 2021 at 1:28 AM Željko Blaće  wrote:

> Before this last 21st day in the 21st year of 21st century
> is globally over, I try to re-initiate re-thinking
> on this 15 years old proposal for a Wikipedian-in-residence
>
> http://original-research.blogspot.com/2006/12/wikipedian-in-residence-proposal.html
> but also articles in (only) 27 language Wikipedias,
>
> Meta, Outreach wiki and elsewhere
> for updating the notion of WIR and roles it performs in Wikimedia,
> an ecosystem of diverse entities, dynamics and relations.
>
> As Wikimedians with wider perspective than a single wiki project, often
> more than a single language and for sure more than single community, gear
> up to discuss and act on 2030 strategy, that includes new initiatives, new
> formations of decentering resources, new content, forms and methods of
> working, with new priorities, conditions, tools, services and what
> not…there is also a value in reflecting and reimagining what is already
> established but often overlooked practice.
>
> Some of the WIR practitioners have been self-reflecting on and off
> publicly https://wikistrategies.net/5-things-wikipedian-in-residence/ and
> engaging with communities https://www.youtube.com/watch?v=tc9YgFm2eso
> there was also network establishment.
> 3 years ago WREN UG (Wikimedians in Residence Exchange Network User Group)
> was recognized with the aim to protect the common elements of the role and
> for creating a peer support network of new and experienced WIRs for
> collaboration and to encourage a global professional environment which
> inspires institutions to appoint persons to engage with Wikimedia.
>
> In recent times Wikipedian-in-Residence, is more often
> Wikimedian-in-Residence, in rapid growth of Commons and Wikidata (but also
> in 2021 first one in Wiktionary) and sometimes Wikimedian-at-Large, in more
> generalized practice of strategy or direction setting work.
> Additionally in time of pandemic when doing physical events is challenging
> and many of the (potential) partner organizations are closing down or
> limiting public events to bare essential, short and transient it is more
> important than ever that individuals (rather than cohorts of editathon
> enthusiasts) keep revisiting institutions and work with them in a most
> flexible mode and scale.
>
> Finally to start both re-visioning and maybe even re-positioning WIRs in
> Wikimedia we should think of what this network of ‘free agents’ can bring
> towards 2030, beyond what WMF, affiliates, UGs, HUBs, WikiProjects and
> other organizational forms can. Also think how much more useful this
> initial inspiration of artists, writers and researchers in residence could
> be if these creative and critical roles in the art and cultural sector get
> embraced and encouraged more often and more intentionally.
>
> Z. Blace
> ___
> 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/LLPODGYR7UVIP2KESHKUPJK2QR7MYYMK/
> 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/B2CIMUXQDLD4VS2XJBE7QVL2HTTP3IKN/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: [Affiliates] Re: Wikimedia Indonesia annual and audit report

[Biyanto Rebin]

Hello Tito,

Thank you so much for reading our report! It means a lot to us.
If you have any suggestions or things that we need to improve on or
collaboration among us, please let us know.

Best,
Biyanto


Pada tanggal Jum, 31 Des 2021 pukul 20.40 Tito Dutta 
menulis:

> Hello Biyanto,
> The report looks pretty amazing, and it is very well-designed. It is
> always a pleasure to go through your report, and the way you wonderfully
> present it.
> Thanks to you and your team for sharing.
> ইতি,
> টিটো দত্ত/User:Titodutta
> (মাতৃভাষা থাক জীবন জুড়ে)
>
>
> শুক্র, ৩১ ডিসেম্বর, ২০২১ তারিখে ৬:৫২ PM টায় তারিখে Biyanto Rebin <
> biyanto.re...@wikimedia.or.id> লিখেছেন:
>
>> Hello all,
>>
>> On behalf of Wikimedia Indonesia, I am so thrilled to announce that we
>> have already received our audit report. You can read our annual report in 
>> bilingual
>> report 
>> (Indonesian-English) and video format report
>>  in Indonesian only. You
>> can read our audit report via this link.
>> 
>>
>>
>> Happy new year for all of us.
>> Have a wonderful year ahead!
>>
>> Best,
>>
>>
>>
>> Biyanto Rebin | Ketua Umum (*Chair of the Board of Executive*)
>>
>> Wikimedia Indonesia
>>
>> Surel | E-mail : biyanto.re...@wikimedia.or.id
>>
>> Akun pengguna | User name: Biyanto Rebin (WMID)
>> 
>>
>> -
>>
>> Wikimedia Indonesia adalah organisasi nirlaba dan merupakan mitra lokal
>> dari Wikimedia Foundation, pengelola situs populer dunia Wikipedia dan
>> proyek-proyek wiki lainnya. Wikimedia Indonesia berdedikasi untuk mendorong
>> pertumbuhan, pengembangan, dan penyebaran pengetahuan dalam bahasa
>> Indonesia dan bahasa daerah yang dipertuturkan di Indonesia secara bebas
>> dan gratis.
>>
>>
>> Dukung upaya kami membebaskan pengetahuan
>> 
>>
>> https://wikimedia.or.id/sumbangan/
>> ___
>> 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/7XWWJXUFHSK5EGTTD2HVK43HAVHHOICA/
>> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
>
> ___
> Affiliates mailing list -- affilia...@lists.wikimedia.org
> To unsubscribe send an email to affiliates-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/EYYZ6WLAMOZQA3VABDIHFM2PJR5WYQQ6/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: [Commons-l] Uplifting the multimedia stack (was: Community Wishlist Survery)

[F. Xavier Dengra i Grau via Wikimedia-l]

It is definitely so sad to see those many abandoned tickets in Phabricator, 
like the ones Galder has been sharing along this thread. The same for the very 
interesting -and quite easy to implement- proposals that had lots of votes in 
the previous Community Wishlists but that never succeeded.

It is difficult to convince users in some Village Pumps to participate in the 
new Community Wishlists, as the improvements that we see do not relate much 
with many of the language-related needs. Not to mention what's going on with 
the sister projects: for Wikiquote or Wikibooks it has been crystal clear for 
the small communities that we are merely server-supported, without any other 
special, significant improvement foreseen nor for the past decade nor for the 
years to come. I feel often insulted when I see the "scary" banners to push 
people to donate in this small wiki projects -in which we barely can provide 
contents with an interface of 2008.

Necessary and valuable tech proposals for our poor infrastructure are 
completely left behind while the WMF is publishing press releases about a 
120-million $ revenue. Meanwhile, some wikipedians increasingly take advantage 
of this big money as an opportunity to convert their hobby into a job by asking 
more and more grants in Meta to do paid-editing, WiRs or "cultural" projects 
(that before were fully succesfully volunteered-driven). Priorities and the 
consequences of having too much money.

Xavier Dengra

Sent with [ProtonMail](https://protonmail.com/) Secure Email.

‐‐‐ Original Message ‐‐‐
El dilluns, 3 de gener 2022 a les 9:44 PM, Galder Gonzalez Larrañaga 
 va escriure:

> I would like to be optimistic, but... 
> https://phabricator.wikimedia.org/T289101
>
> 2022(e)ko urt. 3(a) 15:28 erabiltzaileak hau idatzi du (Brion Vibber 
> ):
>
>> (Anyway I'm just grumping. I hear positive things about plans for this year 
>> and I'm heartened to see more folks involved in planning the next stages!)
>>
>> -- brion
>>
>> On Mon, Jan 3, 2022, 6:10 AM Brion Vibber  wrote:
>>
>>> On Thu, Dec 30, 2021, 10:27 AM Samuel Klein  wrote:
>>>
 Separate thread. I'm not sure which list is appropriate.
 ... but not all the way to 
 [sentience](https://en.wikipedia.org/wiki/The_Uplift_War).

 The annual community wishlist survey (implemented by a small team, 
 possibly in isolation?) may not be the mechanism for prioritizing large 
 changes, but the latter also deserves a community-curated priority queue. 
 To complement the staff-maintained priorities in phab ~

 For core challenges (like Commons stability and capacity), I'd be 
 surprised if the bottleneck were people or budget.
>>>
>>> Currently there are zero people and no budget for multimedia, aside from 
>>> whatever work I and others manage to get done here there. And I'm afraid I 
>>> don't scale.
>>>
>>> It's Wikimedia Foundation's job to assign budget and people here. I've been 
>>> hoping for years that this will happen, and continue to hope.
>>>
>>> -- brion
>>>
 We do need a shared understanding of what issues are most important and 
 most urgent, and how to solve them. For instance, a way to turn Amir's 
 recent email about the problem (and related phab tickets) into a family of 
 persistent, implementable specs and proposals and their articulated 
 obstacles.

 An issue tracker like phab is good for tracking the progress and 
 dependencies of agreed-upon tasks, but weak for discussing what is 
 important, what we know about it, how to address it. And weak for 
 discussing ecosystem-design issues that are important and need persistent 
 updating but don't have a simple checklist of steps.

 So where is the best current place to discuss scaling Commons, and all 
 that entails? Some examples from recent discussions (most from the wm-l 
 thread below):
 - Uploads: Support for large file uploads / Keeping bulk upload tools 
 online
 - Video: Debugging + rolling out the 
 [videojs](https://phabricator.wikimedia.org/T248418) player
 - Formats: Adding support for 
 [CML](https://phabricator.wikimedia.org/T18491) and [dozens of 
 other](https://phabricator.wikimedia.org/T297514) common high-demand file 
 formats
 - Thumbs: Updating [thumbor](https://phabricator.wikimedia.org/T216815) 
 and [librsvg](https://phabricator.wikimedia.org/T193352)
 - Search: WCQS 
 [still](https://phabricator.wikimedia.org/T297454)[down](https://phabricator.wikimedia.org/T297454),
  noauth [option](https://phabricator.wikimedia.org/T297995) wanted for 
 tools
 - General: Finish implementing 
 [redesign](https://phabricator.wikimedia.org/T28741) of the image table

 SJ

 On Wed, Dec 29, 2021 at 6:26 AM Amir Sarabadani  
 wrote:

> I'm not debating your note. It is very valid that we lack proper support 
> for multimedia stack. I myself wrote a 

[Wikimedia-l] Re: [Commons-l] Uplifting the multimedia stack (was: Community Wishlist Survery)

[Galder Gonzalez Larrañaga]

I would like to be optimistic, but... https://phabricator.wikimedia.org/T2891012022(e)ko urt. 3(a) 15:28 erabiltzaileak hau idatzi du (Brion Vibber ):(Anyway I'm just grumping. I hear positive things about plans for this year and I'm heartened to see more folks involved in planning the next stages!)-- brionOn Mon, Jan 3, 2022, 6:10 AM Brion Vibber  wrote:On Thu, Dec 30, 2021, 10:27 AM Samuel Klein  wrote:Separate thread.  I'm not sure which list is appropriate. ... but not all the way to sentience.The annual community wishlist survey (implemented by a small team, possibly in isolation?) may not be the mechanism for prioritizing large changes, but the latter also deserves a community-curated priority queue.  To complement the staff-maintained priorities in phab ~For core challenges (like Commons stability and capacity), I'd be surprised if the bottleneck were people or budget. Currently there are zero people and no budget for multimedia, aside from whatever work I and others manage to get done here there. And I'm afraid I don't scale.It's Wikimedia Foundation's job to assign budget and people here. I've been hoping for years that this will happen, and continue to hope.-- brion We do need a shared understanding of what issues are most important and most urgent, and how to solve them. For instance, a way to turn Amir's recent email about the problem (and related phab tickets) into a family of persistent, implementable specs and proposals and their articulated obstacles.An issue tracker like phab is good for tracking the progress and dependencies of agreed-upon tasks, but weak for discussing what is important, what we know about it, how to address it. And weak for discussing ecosystem-design issues that are important and need persistent updating but don't have a simple checklist of steps.So where is the best current place to discuss scaling Commons, and all that entails?  Some examples from recent discussions (most from the wm-l thread below):- Uploads: Support for large file uploads / Keeping bulk upload tools online- Video: Debugging + rolling out the videojs player- Formats: Adding support for CML and dozens of other common high-demand file formats- Thumbs: Updating thumbor and librsvg- Search: WCQS still down, noauth option wanted for tools- General: Finish implementing redesign of the image tableSJOn Wed, Dec 29, 2021 at 6:26 AM Amir Sarabadani  wrote:I'm not debating your note. It is very valid that we lack proper support for multimedia stack. I myself wrote a detailed rant on how broken it is [1] but three notes: - Fixing something like this takes time, you need to assign the budget for it (which means it has to be done during the annual planning) and if gets approved, you need to start it with the fiscal year (meaning July 2022) and then hire (meaning, write JD, do recruitment, interview lots of people, get them hired) which can take from several months to years. Once they are hired, you need to onboard them and let them learn about our technical infrastructure which takes at least two good months. Software engineering is not magic, it takes time, blood and sweat. [2] - Making another team focus on multimedia requires changes in planning, budget, OKR, etc. etc. Are we sure moving the focus of teams is a good idea? Most teams are already focusing on vital parts of wikimedia and changing the focus will turn this into a whack-a-mole game where we fix multimedia but now we have critical issues in security or performance. - Voting Wishlist survey is a good band-aid in the meantime. To at least address the worst parts for now.I don't understand your point tbh, either you think it's a good idea to make requests for improvements in multimedia in the wishlist survey or you think it's not. If you think it's not, then it's offtopic to this thread.[1] https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/WMPZHMXSLQJ6GONAVTFLDFFMPNJDVORS/[2] There is a classic book in this topic called "The Mythical Man-month"On Wed, Dec 29, 2021 at 11:41 AM Gnangarra  wrote:we have to vote for regular maintenance and support for essential functions like uploading files which is the core mission of Wikimedia Commons
___
Commons-l mailing list -- common...@lists.wikimedia.org
To unsubscribe send an email to commons-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/MXW26DJMJ3TBTFY3JIX4VTUAHXW7FXKW/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: [Commons-l] Uplifting the multimedia stack (was: Community Wishlist Survery)

[Brion Vibber]

(Anyway I'm just grumping. I hear positive things about plans for this year
and I'm heartened to see more folks involved in planning the next stages!)

-- brion

On Mon, Jan 3, 2022, 6:10 AM Brion Vibber  wrote:

> On Thu, Dec 30, 2021, 10:27 AM Samuel Klein  wrote:
>
>> Separate thread.  I'm not sure which list is appropriate.
>> *... but not all the way to sentience
>> .*
>>
>> The annual community wishlist survey (implemented by a small team,
>> possibly in isolation?) may not be the mechanism for prioritizing large
>> changes, but the latter also deserves a community-curated priority queue.
>> To complement the staff-maintained priorities in phab ~
>>
>> For core challenges (like Commons stability and capacity), I'd be
>> surprised if the bottleneck were people or budget.
>>
>
> Currently there are zero people and no budget for multimedia, aside from
> whatever work I and others manage to get done here there. And I'm afraid I
> don't scale.
>
> It's Wikimedia Foundation's job to assign budget and people here. I've
> been hoping for years that this will happen, and continue to hope.
>
>
> -- brion
>
> We do need a shared understanding of what issues are most important and
>> most urgent, and how to solve them. For instance, a way to turn Amir's
>> recent email about the problem (and related phab tickets) into a family of
>> persistent, implementable specs and proposals and their articulated
>> obstacles.
>>
>> An issue tracker like phab is good for tracking the progress and
>> dependencies of agreed-upon tasks, but weak for discussing what is
>> important, what we know about it, how to address it. And weak for
>> discussing ecosystem-design issues that are important and need persistent
>> updating but don't have a simple checklist of steps.
>>
>> So where is the best current place to discuss scaling Commons, and all
>> that entails?  Some examples from recent discussions (most from the wm-l
>> thread below):
>> - *Uploads*: Support for large file uploads / Keeping bulk upload tools
>> online
>> - *Video*: Debugging + rolling out the videojs
>>  player
>> - *Formats*: Adding support for CML
>>  and dozens of other
>>  common high-demand file
>> formats
>> - *Thumbs*: Updating thumbor 
>> and librsvg 
>> - *Search*: WCQS still  down
>> , noauth option
>>  wanted for tools
>> - *General*: Finish implementing redesign
>>  of the image table
>>
>> SJ
>>
>> On Wed, Dec 29, 2021 at 6:26 AM Amir Sarabadani 
>> wrote:
>>
>>> I'm not debating your note. It is very valid that we lack proper support
>>> for multimedia stack. I myself wrote a detailed rant on how broken it is
>>> [1] but three notes:
>>>  - Fixing something like this takes time, you need to assign the budget
>>> for it (which means it has to be done during the annual planning) and if
>>> gets approved, you need to start it with the fiscal year (meaning July
>>> 2022) and then hire (meaning, write JD, do recruitment, interview lots of
>>> people, get them hired) which can take from several months to years. Once
>>> they are hired, you need to onboard them and let them learn about our
>>> technical infrastructure which takes at least two good months. Software
>>> engineering is not magic, it takes time, blood and sweat. [2]
>>>  - Making another team focus on multimedia requires changes in planning,
>>> budget, OKR, etc. etc. Are we sure moving the focus of teams is a good
>>> idea? Most teams are already focusing on vital parts of wikimedia and
>>> changing the focus will turn this into a whack-a-mole game where we fix
>>> multimedia but now we have critical issues in security or performance.
>>>  - Voting Wishlist survey is a good band-aid in the meantime. To at
>>> least address the worst parts for now.
>>>
>>> I don't understand your point tbh, either you think it's a good idea to
>>> make requests for improvements in multimedia in the wishlist survey or you
>>> think it's not. If you think it's not, then it's offtopic to this thread.
>>>
>>> [1]
>>> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/WMPZHMXSLQJ6GONAVTFLDFFMPNJDVORS/
>>> [2] There is a classic book in this topic called "The Mythical Man-month"
>>>
>>> On Wed, Dec 29, 2021 at 11:41 AM Gnangarra  wrote:
>>>
 we have to vote for regular maintenance and support for
 essential functions like uploading files which is the core mission of
 Wikimedia Commons

>>> ___
>> Commons-l mailing list -- common...@lists.wikimedia.org
>> To unsubscribe send an email to 

[Wikimedia-l] Re: [Commons-l] Uplifting the multimedia stack (was: Community Wishlist Survery)

[Brion Vibber]

On Thu, Dec 30, 2021, 10:27 AM Samuel Klein  wrote:

> Separate thread.  I'm not sure which list is appropriate.
> *... but not all the way to sentience
> .*
>
> The annual community wishlist survey (implemented by a small team,
> possibly in isolation?) may not be the mechanism for prioritizing large
> changes, but the latter also deserves a community-curated priority queue.
> To complement the staff-maintained priorities in phab ~
>
> For core challenges (like Commons stability and capacity), I'd be
> surprised if the bottleneck were people or budget.
>

Currently there are zero people and no budget for multimedia, aside from
whatever work I and others manage to get done here there. And I'm afraid I
don't scale.

It's Wikimedia Foundation's job to assign budget and people here. I've been
hoping for years that this will happen, and continue to hope.


-- brion

We do need a shared understanding of what issues are most important and
> most urgent, and how to solve them. For instance, a way to turn Amir's
> recent email about the problem (and related phab tickets) into a family of
> persistent, implementable specs and proposals and their articulated
> obstacles.
>
> An issue tracker like phab is good for tracking the progress and
> dependencies of agreed-upon tasks, but weak for discussing what is
> important, what we know about it, how to address it. And weak for
> discussing ecosystem-design issues that are important and need persistent
> updating but don't have a simple checklist of steps.
>
> So where is the best current place to discuss scaling Commons, and all
> that entails?  Some examples from recent discussions (most from the wm-l
> thread below):
> - *Uploads*: Support for large file uploads / Keeping bulk upload tools
> online
> - *Video*: Debugging + rolling out the videojs
>  player
> - *Formats*: Adding support for CML
>  and dozens of other
>  common high-demand file
> formats
> - *Thumbs*: Updating thumbor 
> and librsvg 
> - *Search*: WCQS still  down
> , noauth option
>  wanted for tools
> - *General*: Finish implementing redesign
>  of the image table
>
> SJ
>
> On Wed, Dec 29, 2021 at 6:26 AM Amir Sarabadani 
> wrote:
>
>> I'm not debating your note. It is very valid that we lack proper support
>> for multimedia stack. I myself wrote a detailed rant on how broken it is
>> [1] but three notes:
>>  - Fixing something like this takes time, you need to assign the budget
>> for it (which means it has to be done during the annual planning) and if
>> gets approved, you need to start it with the fiscal year (meaning July
>> 2022) and then hire (meaning, write JD, do recruitment, interview lots of
>> people, get them hired) which can take from several months to years. Once
>> they are hired, you need to onboard them and let them learn about our
>> technical infrastructure which takes at least two good months. Software
>> engineering is not magic, it takes time, blood and sweat. [2]
>>  - Making another team focus on multimedia requires changes in planning,
>> budget, OKR, etc. etc. Are we sure moving the focus of teams is a good
>> idea? Most teams are already focusing on vital parts of wikimedia and
>> changing the focus will turn this into a whack-a-mole game where we fix
>> multimedia but now we have critical issues in security or performance.
>>  - Voting Wishlist survey is a good band-aid in the meantime. To at least
>> address the worst parts for now.
>>
>> I don't understand your point tbh, either you think it's a good idea to
>> make requests for improvements in multimedia in the wishlist survey or you
>> think it's not. If you think it's not, then it's offtopic to this thread.
>>
>> [1]
>> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/WMPZHMXSLQJ6GONAVTFLDFFMPNJDVORS/
>> [2] There is a classic book in this topic called "The Mythical Man-month"
>>
>> On Wed, Dec 29, 2021 at 11:41 AM Gnangarra  wrote:
>>
>>> we have to vote for regular maintenance and support for
>>> essential functions like uploading files which is the core mission of
>>> Wikimedia Commons
>>>
>> ___
> Commons-l mailing list -- common...@lists.wikimedia.org
> To unsubscribe send an email to commons-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 

[Wikimedia-l] Re: Community Wishlist Survey 2022 is coming. Help us and prepare

[Andreas Kolbe]

Hi Antoine,

I believe you have to distinguish between the roughly 300+ WMF employees
and the roughly 200+ people like yourself who work for the WMF as
contractors. (You are identified as a contractor on the Staff and
contractors page.)

The Form 990 figures I quoted were for the number of actual employees, and
their associated salary costs. This does not include contractors. It
explains why the number of employees reported in the Form 990 is generally
lower than the number of people listed or referred to on the Staff and
Contractors page.

Contractors are covered in a different part of the Form 990: Part IX,
column (A), lines 11 a–g ("Fees for services (non-employees)"). In the
audited financial statements, these costs become "Professional service
expenses", the reported 2020/2021 total being $12.1 million, up from $11.7
million for 2019/2020. Assuming there are currently 200 or more
contractors, contractors are thus paid at most around $60,000 on average.

Employees, on the other hand, earn far more: the WMF reported that 165
employees (well over half) were on salaries of more than $100,000 in 2019.
In 2015, that number had been 79, less than half that. (This info is found
in Part VII, line 2 of the Form 990.)

The fact that salaried employees are paid more on average than contractors
is partly (but not solely) due to many contractors living outside the US,
where living costs are generally cheaper. Another reason why salary costs
for employees work out at such a much higher average is that they enjoy
substantial benefits, which are included in the total salary costs reported
in a Form 990.

The salary costs that an organisation like the Internet Archive, the EFF or
the Wikimedia Foundation reports in the Form 990 include, in addition to
actual salaries and wages, pension plans, other employee benefits and
payroll taxes – the figures in Part IX, column (A), lines 5–10.

The Internet Archive, for example, reported salary costs of $10,924,995 for
169 employees, for an average of $65,000 per head. Of these $10,924,995,
pension plans, benefits and taxes together amounted to $1.4 million (there
was no pension plan), or about 13% of total salary costs. Payroll taxes
were 0.7 million, or half of that.

The Electronic Frontier Foundation reported salary costs of $12,407,966 for
102 employees, for an average of $122,000 per head. Of these $12,407,966,
pension plans, benefits and taxes together amounted to 1.85 million, or
about 15% of salary costs. Payroll taxes were $0.7 million, or 38% of that.

The Wikimedia Foundation reported salary costs of $55,634,913 for 291
employees, for an average of $191,000 per head. Of these $55,634,913,
pension plans, benefits and taxes together amounted to $10.3 million (the
biggest single item being "other employee benefits", at $6.6 million), or
about 18.5% of total salary costs. Payroll taxes were $2.5 million, or 24%
of that. So in the case of the WMF, more than three-quarters of the
additional amount is not tax, but really does benefit the employee, be it
through a pension scheme or some other kind of benefit.

As for updating the Staff and Contractors page, I think that at least the
list of employees (as opposed to contractors) should always be up to date
and complete. This should not be difficult for the administration to
accomplish.

Do you know how many employees there currently are?

Best,
Andreas

On Mon, Jan 3, 2022 at 9:28 AM Antoine Musso  wrote:

> On 30/12/2021 15:36, Andreas Kolbe wrote:
> [...]
>
> WMF salary costs have increased further since 2019. The 2020/21 financial
> statements[5] released earlier this month gave a "Salaries and wages"
> figure of $67,857,676, an increase of 22% over the year prior.
>
> Assuming a total of around 300 employees for that year, based on the
> number of employees shown in this April 2021 archive of the Staff and
> Contractors page,[6] I estimate the annual cost per WMF employee is now
> around $225K (I'm happy to be corrected on this if any of my figures or
> assumptions should turn out to be mistaken).
>
> Contractors (176 listed on the current WMF staff and contractors page[7])
> are somewhat cheaper, of course.
> [...]
> [5]
> https://foundation.wikimedia.org/w/index.php?title=File:Wikimedia_Foundation_FY2020-2021_Audit_Report.pdf=5
> [6] https://archive.today/rFGMv
> [7] https://wikimediafoundation.org/role/staff-contractors/
>
> Hello Andreas,
>
> The Staff and Contractors page ( https://archive.today/rFGMv ) states
> there is more than 450 persons. That page is no more updated in a timely
> fashion and some employees are explicitly not listed on that page for a
> variety of reasons. I think we can just not keep up updating all our
> employees lists and that page is lagging a bit.
>
> As I get it from internal lists, the foundation is nearing 600 employees
> and contractors (and we have five people starting today).
>
> The form 990 has employee count based on the calendar year (291 from
> January 1st 2019 to December 30th 

[Wikimedia-l] Re: Community Wishlist Survey 2022 is coming. Help us and prepare

[Antoine Musso]

On 30/12/2021 15:36, Andreas Kolbe wrote:
[...]
WMF salary costs have increased further since 2019. The 2020/21 
financial statements[5] released earlier this month gave a "Salaries 
and wages" figure of $67,857,676, an increase of 22% over the year prior.


Assuming a total of around 300 employees for that year, based on the 
number of employees shown in this April 2021 archive of the Staff and 
Contractors page,[6] I estimate the annual cost per WMF employee is 
now around $225K (I'm happy to be corrected on this if any of my 
figures or assumptions should turn out to be mistaken).


Contractors (176 listed on the current WMF staff and contractors 
page[7]) are somewhat cheaper, of course.

[...]
[5] 
https://foundation.wikimedia.org/w/index.php?title=File:Wikimedia_Foundation_FY2020-2021_Audit_Report.pdf=5 


[6] https://archive.today/rFGMv 
[7] https://wikimediafoundation.org/role/staff-contractors/ 



Hello Andreas,

The Staff and Contractors page ( https://archive.today/rFGMv 
 ) states there is more than 450 persons. 
That page is no more updated in a timely fashion and some employees are 
explicitly not listed on that page for a variety of reasons. I think we 
can just not keep up updating all our employees lists and that page is 
lagging a bit.


As I get it from internal lists, the foundation is nearing 600 employees 
and contractors (and we have five people starting today).


The form 990 has employee count based on the calendar year (291 from 
January 1st 2019 to December 30th 2019) while the expenses would be 
reported based on the fiscal year (July 1st 2019 to June 30 2020). If we 
got a few dozens of people hired in the first part of 2020 they are not 
shown in the head count but do reflect in the expense line yet. Finance 
and or HR at the foundation would be able to address your question.


I am entirely sure we are not making $190k per year on average nor 
$225k, those would be the total compensation / cost for the c levels or 
of the very top compensated persons (they are listed in the form 990 and 
also listed at 
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_salaries 
 .


/Antoine "hashar" Musso//
//Wikimedia Release Engineering/



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

[Wikimedia-l] Re: ? structural problems overview (WAS: Uplifting the multimedia stack (was: Community Wishlist Survery))

[Željko Blaće]

Hm...actually I am hopeful of changes in 2022, at least at the level of
most engaged Wikimedians with bottom-up organizing efforts like SWAN, HUBs
and other initiatives (some of de-centering is starting to emerge), as well
as the very top as the new WMF CEO is bound to make just by having to fill
so many places and starting to structurally address issues *(with both
fresh eyes and background in development)...

What I worry about is that many in the middle are harder to move as they do
not see personal agency (maybe burdened by history) or are super strategic
over personal commitments if employed (maybe burdened by lack of
flexibility in WMF).

What could be a useful overview of Structural problems in Wikimedia in
order for Wikimedians to navigate and engage better?

I am sure this was addressed at some point in some of the strategy building
processes both for the 2030 Movement and 2025 WMF strategy, but it is
probably not summarized, framed as such and made prominent *(mabe it is
called challenges and tucked under the first follow-up 'solution'
initiative).

If anyone feels like sharing those as links or notes please do:
https://etherpad.wikimedia.org/p/WM-structural-problems-overview


On Sun, Jan 2, 2022 at 11:48 PM Galder Gonzalez Larrañaga <
galder...@hotmail.com> wrote:

> I would be great to continue discussing this on Meta if someone would
> solve the issues. I doubt this is going to happen. Ever.
> --
> *From:* Željko Blaće 
> *Sent:* Sunday, January 2, 2022 12:17 PM
> *To:* Wikimedia Mailing List 
> *Cc:* Wikimedia Commons Discussion List ;
> Wikitech-l 
> *Subject:* [Wikimedia-l] ? structural problems overview (WAS: Uplifting
> the multimedia stack (was: Community Wishlist Survery))
>
> Dear ALL -
> this was informative discussion on several issues,
> but I fear the mailing-list is likely an inadequate way
> to see all the structural problems and this complexity
> with adequate distance (beyond single issue discussions).
>
> Now I wonder if it makes more sense maybe, to use
> (sorry for being so blunt here) a page on Meta (?!)
> for listing structural problems and organizing online event or two
> (maybe an office hour format) with few people on the WMF side.
>
> Who can list the biggest 'red flags' that manifest
> as huge and hard to solve issues (affecting major resources,
> not just multimedia, though it is very dear to me also).
>
> To be fair to all - not to expect too much, but to gain overview.
> I would love to attend this even if it only helps me understand
> the fragility of the Wikimedia system and all challenges ahead.
>
> Best Z. Blace
>
> ___
> 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/T5KGYOXIH755IE6OK3R2FW6E2SLNNK3P/
> 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/RDHJVIKGKJS5RVSIOBYZ3TYJL4C5UGOB/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org