The Community Wishlist Survey 2022 https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2022 starts in less than two weeks (Monday 10 January 2022, 18:00 UTC https://www.timeanddate.com/worldclock/fixedtime.html?iso=20220110T1800). We, the team organizing the Survey, need your help.
- Translate important messages https://meta.wikimedia.org/w/index.php?title=Special:Translate&group=agg-Community_Wishlist_Survey&action=page and/or - Promote the Survey https://meta.wikimedia.org/wiki/Community_Wishlist_Survey/Help_us among anyone and everyone you know who has an account on wiki. Promote the Survey on social media, via instant messaging apps, in other groups and chats, in your WikiProject, Wikimedia affiliate - wherever contributors with registered accounts may be. - You may also start thinking about ideas for technical improvements or even writing them down in the CWS sandbox https://meta.wikimedia.org/wiki/Community_Wishlist_Survey/Sandbox.
*Why are we asking?*
- We have improved the documentation https://meta.wikimedia.org/wiki/Community_Wishlist_Survey/FAQ. It's friendlier and easier to use. This will mean little if it's only in English. - Thousands of volunteers haven't participated in the Survey yet. We'd like to improve that, too. Three years ago, 1387 people participated. Last year, there were 1773 of them. We hope that in the upcoming edition, there will be even more - if you help us with translations. Also, you are better than us in contacting Wikimedians outside of wikis. We have prepared some images to share. More to come.
*What is the Community Wishlist Survey?*
It's an annual survey that allows contributors to the Wikimedia projects to propose and vote for tools and platform improvements. Long years of experience in editing or technical skills are not required.
Thank you for your time and attention. To those who have participated in the Survey - many thanks for your dedication.
See you in January!
Szymon Grabarczuk (he/him)
Community Relations Specialist
Wikimedia Foundation
Kaya
Instead of putting resources into making more tools, how about putting more resources into sustainability. For a large part of the last 12 months Commons has been unable to upload large files, bulk upload tools falling over have been hampering efforts to engage with GLAMs. Every other aspect of the WMF work has been put on hold while reviews into the systems take place. I think it's time to put new development on hold or at least limit priority and capacity then focus efforts on updating and upgrading existing tools. If those tools cant be fixed, rewrite them from scratch
Gnangarra
On Wed, 29 Dec 2021 at 12:08, Szymon Grabarczuk sgrabarczuk@wikimedia.org wrote:
The Community Wishlist Survey 2022 https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2022 starts in less than two weeks (Monday 10 January 2022, 18:00 UTC https://www.timeanddate.com/worldclock/fixedtime.html?iso=20220110T1800). We, the team organizing the Survey, need your help.
- Translate important messages
- Promote the Survey
https://meta.wikimedia.org/wiki/Community_Wishlist_Survey/Help_us among anyone and everyone you know who has an account on wiki. Promote the Survey on social media, via instant messaging apps, in other groups and chats, in your WikiProject, Wikimedia affiliate - wherever contributors with registered accounts may be.
- You may also start thinking about ideas for technical improvements
or even writing them down in the CWS sandbox https://meta.wikimedia.org/wiki/Community_Wishlist_Survey/Sandbox.
*Why are we asking?*
- We have improved the documentation
https://meta.wikimedia.org/wiki/Community_Wishlist_Survey/FAQ. It's friendlier and easier to use. This will mean little if it's only in English.
- Thousands of volunteers haven't participated in the Survey yet. We'd
like to improve that, too. Three years ago, 1387 people participated. Last year, there were 1773 of them. We hope that in the upcoming edition, there will be even more - if you help us with translations. Also, you are better than us in contacting Wikimedians outside of wikis. We have prepared some images to share. More to come.
*What is the Community Wishlist Survey?*
It's an annual survey that allows contributors to the Wikimedia projects to propose and vote for tools and platform improvements. Long years of experience in editing or technical skills are not required.
Thank you for your time and attention. To those who have participated in the Survey - many thanks for your dedication.
See you in January!
Szymon Grabarczuk (he/him)
Community Relations Specialist
Wikimedia Foundation _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Is the community wishlist not for for projects run by volunteers? Volunteers do what they choose, employees do what they are paid for. Keeping the Wikis functional should be the work of employees and the WMF.
Cheers,
Peter
From: Gnangarra [mailto:gnangarra@gmail.com] Sent: 29 December 2021 07:37 To: Wikimedia Mailing List Subject: [Wikimedia-l] Re: Community Wishlist Survey 2022 is coming. Help us and prepare
Kaya
Instead of putting resources into making more tools, how about putting more resources into sustainability. For a large part of the last 12 months Commons has been unable to upload large files, bulk upload tools falling over have been hampering efforts to engage with GLAMs. Every other aspect of the WMF work has been put on hold while reviews into the systems take place. I think it's time to put new development on hold or at least limit priority and capacity then focus efforts on updating and upgrading existing tools. If those tools cant be fixed, rewrite them from scratch
Gnangarra
On Wed, 29 Dec 2021 at 12:08, Szymon Grabarczuk sgrabarczuk@wikimedia.org wrote:
The Community Wishlist Survey 2022 https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2022 starts in less than two weeks (Monday 10 January 2022, 18:00 UTC https://www.timeanddate.com/worldclock/fixedtime.html?iso=20220110T1800 ). We, the team organizing the Survey, need your help.
* Translate important messages https://meta.wikimedia.org/w/index.php?title=Special:Translate&group=agg-Community_Wishlist_Survey&action=page and/or * Promote the Survey https://meta.wikimedia.org/wiki/Community_Wishlist_Survey/Help_us among anyone and everyone you know who has an account on wiki. Promote the Survey on social media, via instant messaging apps, in other groups and chats, in your WikiProject, Wikimedia affiliate - wherever contributors with registered accounts may be. * You may also start thinking about ideas for technical improvements or even writing them down in the CWS sandbox https://meta.wikimedia.org/wiki/Community_Wishlist_Survey/Sandbox .
Why are we asking?
* We have improved the documentation https://meta.wikimedia.org/wiki/Community_Wishlist_Survey/FAQ . It's friendlier and easier to use. This will mean little if it's only in English. * Thousands of volunteers haven't participated in the Survey yet. We'd like to improve that, too. Three years ago, 1387 people participated. Last year, there were 1773 of them. We hope that in the upcoming edition, there will be even more - if you help us with translations. Also, you are better than us in contacting Wikimedians outside of wikis. We have prepared some images to share. More to come.
What is the Community Wishlist Survey?
It's an annual survey that allows contributors to the Wikimedia projects to propose and vote for tools and platform improvements. Long years of experience in editing or technical skills are not required.
Thank you for your time and attention. To those who have participated in the Survey - many thanks for your dedication.
See you in January!
Szymon Grabarczuk (he/him)
Community Relations Specialist
Wikimedia Foundation
_______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
The wishlist are things the WMF puts resources to including staff time
On Thu, 30 Dec 2021 at 17:46, Peter Southwood peter.southwood@telkomsa.net wrote:
Is the community wishlist not for for projects run by volunteers? Volunteers do what they choose, employees do what they are paid for. Keeping the Wikis functional should be the work of employees and the WMF.
Cheers,
Peter
*From:* Gnangarra [mailto:gnangarra@gmail.com] *Sent:* 29 December 2021 07:37 *To:* Wikimedia Mailing List *Subject:* [Wikimedia-l] Re: Community Wishlist Survey 2022 is coming. Help us and prepare
Kaya
Instead of putting resources into making more tools, how about putting more resources into sustainability. For a large part of the last 12 months Commons has been unable to upload large files, bulk upload tools falling over have been hampering efforts to engage with GLAMs. Every other aspect of the WMF work has been put on hold while reviews into the systems take place. I think it's time to put new development on hold or at least limit priority and capacity then focus efforts on updating and upgrading existing tools. If those tools cant be fixed, rewrite them from scratch
Gnangarra
On Wed, 29 Dec 2021 at 12:08, Szymon Grabarczuk sgrabarczuk@wikimedia.org wrote:
The Community Wishlist Survey 2022 https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2022 starts in less than two weeks (Monday 10 January 2022, 18:00 UTC https://www.timeanddate.com/worldclock/fixedtime.html?iso=20220110T1800). We, the team organizing the Survey, need your help.
- Translate important messages
- Promote the Survey
https://meta.wikimedia.org/wiki/Community_Wishlist_Survey/Help_us among anyone and everyone you know who has an account on wiki. Promote the Survey on social media, via instant messaging apps, in other groups and chats, in your WikiProject, Wikimedia affiliate - wherever contributors with registered accounts may be.
- You may also start thinking about ideas for technical improvements
or even writing them down in the CWS sandbox https://meta.wikimedia.org/wiki/Community_Wishlist_Survey/Sandbox.
*Why are we asking?*
- We have improved the documentation
https://meta.wikimedia.org/wiki/Community_Wishlist_Survey/FAQ. It's friendlier and easier to use. This will mean little if it's only in English.
- Thousands of volunteers haven't participated in the Survey yet. We'd
like to improve that, too. Three years ago, 1387 people participated. Last year, there were 1773 of them. We hope that in the upcoming edition, there will be even more - if you help us with translations. Also, you are better than us in contacting Wikimedians outside of wikis. We have prepared some images to share. More to come.
*What is the Community Wishlist Survey?*
It's an annual survey that allows contributors to the Wikimedia projects to propose and vote for tools and platform improvements. Long years of experience in editing or technical skills are not required.
Thank you for your time and attention. To those who have participated in the Survey - many thanks for your dedication.
See you in January!
*Szymon Grabarczuk *(he/him)
Community Relations Specialist
Wikimedia Foundation
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
--
GN.
2021*
*Celebrating 20 years of Wikipedia*
Wikimania: *Error! Filename not specified.**Error! Filename not specified.**Error! Filename not specified.**Error! Filename not specified.**Error! Filename not specified.* https://wikimania.wikimedia.org/wiki/User:Gnangarra
Noongarpedia: *Error! Filename not specified.**Error! Filename not specified.**Error! Filename not specified.**Error! Filename not specified.**Error! Filename not specified.**Error! Filename not specified.*https://incubator.wikimedia.org/wiki/Wp/nys/Main_Page My print shop: *Error! Filename not specified.**Error! Filename not specified.**Error! Filename not specified.**Error! Filename not specified.**Error! Filename not specified.* https://www.redbubble.com/people/Gnangarra/shop?asc=u
Virus-free. www.avg.com http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Nice. This looks much better than before. Previously it felt so many people had high hopes for projects that are outside of capacities that are committed to this project. I feel this needs to be a super clear fact from the start and not ask for the global community to commit XYZ number of hours in the actions of promoting, translating, proposing and decision making processes when developers can commit far less back to the same community. Otherwise it feels like unbalanced work from a more holistic perspective, but this is also non-exceptional...no?
The wishlist survey is defined as:
The Community Wishlist Survey is an annual survey that allows
contributors to the Wikimedia projects to propose and vote for tools and platform improvements
That doesn't necessarily translate into just "new tools". The community can wish for better support of multimedia stack and improvements on the multimedia platform and If it gets enough votes, I'm hopeful it'll be picked up.
On Wed, Dec 29, 2021 at 8:02 AM Željko Blaće zblace@mi2.hr wrote:
Nice. This looks much better than before. Previously it felt so many people had high hopes for projects that are outside of capacities that are committed to this project. I feel this needs to be a super clear fact from the start and not ask for the global community to commit XYZ number of hours in the actions of promoting, translating, proposing and decision making processes when developers can commit far less back to the same community. Otherwise it feels like unbalanced work from a more holistic perspective, but this is also non-exceptional...no? _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
I have to agree with Gnangarra: Why should keeping one of our major projects running require a global popularity vote? The way how the various problems on Commons are (not!) handled by WMF and others is not acceptable anymore. We don't need a poll to detect that! It's not a wish we have, it's a demand we make: Get Commons fixed now, as soon as possible! And I don't care who does: WMF, WMDE, anybody else. It's nice to have additional ressources for popular community wishes but clean up your own backyard first! Best,DerHexer (Top 10 contributor on Commons, Commons administrator, Steward)
Am Mittwoch, 29. Dezember 2021, 10:32:22 MEZ hat Amir Sarabadani ladsgroup@gmail.com Folgendes geschrieben:
The wishlist survey is defined as:> The Community Wishlist Survey is an annual survey that allows contributors to the Wikimedia projects to propose and vote for tools and platform improvements That doesn't necessarily translate into just "new tools". The community can wish for better support of multimedia stack and improvements on the multimedia platform and If it gets enough votes, I'm hopeful it'll be picked up.
On Wed, Dec 29, 2021 at 8:02 AM Željko Blaće zblace@mi2.hr wrote:
Nice. This looks much better than before. Previously it felt so many people had high hopes for projects that are outside of capacities that are committed to this project. I feel this needs to be a super clear fact from the start and not ask for the global community to commit XYZ number of hours in the actions of promoting, translating, proposing and decision making processes when developers can commit far less back to the same community. Otherwise it feels like unbalanced work from a more holistic perspective, but this is also non-exceptional...no? _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
I agree with the issues here, but I don't think that the solution should be to get rid of the wishlist. Instead, it really should be expanded so it can handle many more of the wishes, since there are many good ones that keep getting proposed but just don't get enough votes to be in the top ten.
Thanks, Mike
On 29/12/21 10:11:14, DerHexer via Wikimedia-l wrote:
I have to agree with Gnangarra: Why should keeping one of our major projects running require a global popularity vote? The way how the various problems on Commons are (not!) handled by WMF and others is not acceptable anymore. We don't need a poll to detect that! It's not a wish we have, it's a demand we make: Get Commons fixed now, as soon as possible! And I don't care who does: WMF, WMDE, anybody else.
It's nice to have additional ressources for popular community wishes but clean up your own backyard first!
Best, DerHexer (Top 10 contributor on Commons, Commons administrator, Steward)
Am Mittwoch, 29. Dezember 2021, 10:32:22 MEZ hat Amir Sarabadani ladsgroup@gmail.com Folgendes geschrieben:
The wishlist survey is defined as:
The Community Wishlist Survey is an annual survey that allows
contributors to the Wikimedia projects to propose and vote for tools and platform improvements
That doesn't necessarily translate into just "new tools". The community can wish for better support of multimedia stack and improvements on the multimedia platform and If it gets enough votes, I'm hopeful it'll be picked up.
On Wed, Dec 29, 2021 at 8:02 AM Željko Blaće <zblace@mi2.hr mailto:zblace@mi2.hr> wrote:
Nice. This looks much better than before. Previously it felt so many people had high hopes for projects that are outside of capacities that are committed to this project. I feel this needs to be a super clear fact from the start and not ask for the global community to commit XYZ number of hours in the actions of promoting, translating, proposing and decision making processes when developers can commit far less back to the same community. Otherwise it feels like unbalanced work from a more holistic perspective, but this is also non-exceptional...no? _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org <mailto:wikimedia-l@lists.wikimedia.org>, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines <https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines> and https://meta.wikimedia.org/wiki/Wikimedia-l <https://meta.wikimedia.org/wiki/Wikimedia-l> Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/W2DTMUUD76RCBVPOJ3VGSJKPYL7V6EZF/ <https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/W2DTMUUD76RCBVPOJ3VGSJKPYL7V6EZF/> To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org <mailto:wikimedia-l-leave@lists.wikimedia.org>
-- Amir (he/him)
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org mailto:wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines <https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines >and https://meta.wikimedia.org/wiki/Wikimedia-l https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/ZSZM4BRNWV3NIQ6RH66QBFFINLKMOIKG/ To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org mailto:wikimedia-l-leave@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/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
If the Wishlist Survey 2022 goes on, my proposal will be simple: make the first 50 wishes. We have money. We need it. And we are not doing essential things. Also, solving platform issues shouldn't be something to vote on. I don't understand why we have to vote to have solutions to even basic infrastructure issues.
Best, Galder ________________________________ From: Mike Peel email@mikepeel.net Sent: Wednesday, December 29, 2021 7:23 PM To: DerHexer via Wikimedia-l wikimedia-l@lists.wikimedia.org Subject: [Wikimedia-l] Re: Community Wishlist Survey 2022 is coming. Help us and prepare
I agree with the issues here, but I don't think that the solution should be to get rid of the wishlist. Instead, it really should be expanded so it can handle many more of the wishes, since there are many good ones that keep getting proposed but just don't get enough votes to be in the top ten.
Thanks, Mike
On 29/12/21 10:11:14, DerHexer via Wikimedia-l wrote:
I have to agree with Gnangarra: Why should keeping one of our major projects running require a global popularity vote? The way how the various problems on Commons are (not!) handled by WMF and others is not acceptable anymore. We don't need a poll to detect that! It's not a wish we have, it's a demand we make: Get Commons fixed now, as soon as possible! And I don't care who does: WMF, WMDE, anybody else.
It's nice to have additional ressources for popular community wishes but clean up your own backyard first!
Best, DerHexer (Top 10 contributor on Commons, Commons administrator, Steward)
Am Mittwoch, 29. Dezember 2021, 10:32:22 MEZ hat Amir Sarabadani ladsgroup@gmail.com Folgendes geschrieben:
The wishlist survey is defined as:
The Community Wishlist Survey is an annual survey that allows
contributors to the Wikimedia projects to propose and vote for tools and platform improvements
That doesn't necessarily translate into just "new tools". The community can wish for better support of multimedia stack and improvements on the multimedia platform and If it gets enough votes, I'm hopeful it'll be picked up.
On Wed, Dec 29, 2021 at 8:02 AM Željko Blaće <zblace@mi2.hr mailto:zblace@mi2.hr> wrote:
Nice. This looks much better than before. Previously it felt so many people had high hopes for projects that are outside of capacities that are committed to this project. I feel this needs to be a super clear fact from the start and not ask for the global community to commit XYZ number of hours in the actions of promoting, translating, proposing and decision making processes when developers can commit far less back to the same community. Otherwise it feels like unbalanced work from a more holistic perspective, but this is also non-exceptional...no? _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org <mailto:wikimedia-l@lists.wikimedia.org>, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines <https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines> and https://meta.wikimedia.org/wiki/Wikimedia-l <https://meta.wikimedia.org/wiki/Wikimedia-l> Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/W2DTMUUD76RCBVPOJ3VGSJKPYL7V6EZF/ <https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/W2DTMUUD76RCBVPOJ3VGSJKPYL7V6EZF/> To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org <mailto:wikimedia-l-leave@lists.wikimedia.org>
-- Amir (he/him)
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org mailto:wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines <https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines >and https://meta.wikimedia.org/wiki/Wikimedia-l https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/ZSZM4BRNWV3NIQ6RH66QBFFINLKMOIKG/ To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org mailto:wikimedia-l-leave@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/... To unsubscribe send an email to wikimedia-l-leave@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/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Fair comment. If you want to keep editors, make sure they have functioning tools. Is this not one of the reasons WMF was originally formed?
Cheers,
Peter
From: DerHexer via Wikimedia-l [mailto:wikimedia-l@lists.wikimedia.org] Sent: 29 December 2021 12:11 To: Wikimedia Mailing List Cc: DerHexer Subject: [Wikimedia-l] Re: Community Wishlist Survey 2022 is coming. Help us and prepare
I have to agree with Gnangarra: Why should keeping one of our major projects running require a global popularity vote? The way how the various problems on Commons are (not!) handled by WMF and others is not acceptable anymore. We don't need a poll to detect that! It's not a wish we have, it's a demand we make: Get Commons fixed now, as soon as possible! And I don't care who does: WMF, WMDE, anybody else.
It's nice to have additional ressources for popular community wishes but clean up your own backyard first!
Best,
DerHexer (Top 10 contributor on Commons, Commons administrator, Steward)
Am Mittwoch, 29. Dezember 2021, 10:32:22 MEZ hat Amir Sarabadani ladsgroup@gmail.com Folgendes geschrieben:
The wishlist survey is defined as:
The Community Wishlist Survey is an annual survey that allows contributors to the Wikimedia projects to propose and vote for tools and platform improvements
That doesn't necessarily translate into just "new tools". The community can wish for better support of multimedia stack and improvements on the multimedia platform and If it gets enough votes, I'm hopeful it'll be picked up.
On Wed, Dec 29, 2021 at 8:02 AM Željko Blaće zblace@mi2.hr wrote:
Nice. This looks much better than before. Previously it felt so many people had high hopes for projects that are outside of capacities that are committed to this project. I feel this needs to be a super clear fact from the start and not ask for the global community to commit XYZ number of hours in the actions of promoting, translating, proposing and decision making processes when developers can commit far less back to the same community. Otherwise it feels like unbalanced work from a more holistic perspective, but this is also non-exceptional...no?
_______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
we have to vote for regular maintenance and support for essential functions like uploading files which is the core mission of Wikimedia Commons
On Wed, 29 Dec 2021 at 17:32, Amir Sarabadani ladsgroup@gmail.com wrote:
The wishlist survey is defined as:
The Community Wishlist Survey is an annual survey that allows
contributors to the Wikimedia projects to propose and vote for tools and platform improvements
That doesn't necessarily translate into just "new tools". The community can wish for better support of multimedia stack and improvements on the multimedia platform and If it gets enough votes, I'm hopeful it'll be picked up.
On Wed, Dec 29, 2021 at 8:02 AM Željko Blaće zblace@mi2.hr wrote:
Nice. This looks much better than before. Previously it felt so many people had high hopes for projects that are outside of capacities that are committed to this project. I feel this needs to be a super clear fact from the start and not ask for the global community to commit XYZ number of hours in the actions of promoting, translating, proposing and decision making processes when developers can commit far less back to the same community. Otherwise it feels like unbalanced work from a more holistic perspective, but this is also non-exceptional...no? _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- Amir (he/him)
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
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/... [2] There is a classic book in this topic called "The Mythical Man-month"
On Wed, Dec 29, 2021 at 11:41 AM Gnangarra gnangarra@gmail.com wrote:
we have to vote for regular maintenance and support for essential functions like uploading files which is the core mission of Wikimedia Commons
On Wed, 29 Dec 2021 at 17:32, Amir Sarabadani ladsgroup@gmail.com wrote:
The wishlist survey is defined as:
The Community Wishlist Survey is an annual survey that allows
contributors to the Wikimedia projects to propose and vote for tools and platform improvements
That doesn't necessarily translate into just "new tools". The community can wish for better support of multimedia stack and improvements on the multimedia platform and If it gets enough votes, I'm hopeful it'll be picked up.
On Wed, Dec 29, 2021 at 8:02 AM Željko Blaće zblace@mi2.hr wrote:
Nice. This looks much better than before. Previously it felt so many people had high hopes for projects that are outside of capacities that are committed to this project. I feel this needs to be a super clear fact from the start and not ask for the global community to commit XYZ number of hours in the actions of promoting, translating, proposing and decision making processes when developers can commit far less back to the same community. Otherwise it feels like unbalanced work from a more holistic perspective, but this is also non-exceptional...no? _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- Amir (he/him)
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- GN.
2021*
*Celebrating 20 years of Wikipedia*
Wikimania: https://wikimania.wikimedia.org/wiki/User:Gnangarra Noongarpedia: https://incubator.wikimedia.org/wiki/Wp/nys/Main_Page My print shop: https://www.redbubble.com/people/Gnangarra/shop?asc=u
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
The wishlist has reached the end of useful life, I think before we go down that track again we have to look hard at what purpose it serves and what other parts of the whole IT/programming area needs to be consider. To do that put the wish list on hold, clear the backlog of phabricator tickets and bring what tools we have had created over the last 15 years back to full serviceability or shut them down and replace them.
In saying that, there may still be a much needed tool so limit what gets accepted and ask for needs fixing
On Wed, 29 Dec 2021 at 19:26, Amir Sarabadani ladsgroup@gmail.com 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/... [2] There is a classic book in this topic called "The Mythical Man-month"
On Wed, Dec 29, 2021 at 11:41 AM Gnangarra gnangarra@gmail.com wrote:
we have to vote for regular maintenance and support for essential functions like uploading files which is the core mission of Wikimedia Commons
On Wed, 29 Dec 2021 at 17:32, Amir Sarabadani ladsgroup@gmail.com wrote:
The wishlist survey is defined as:
The Community Wishlist Survey is an annual survey that allows
contributors to the Wikimedia projects to propose and vote for tools and platform improvements
That doesn't necessarily translate into just "new tools". The community can wish for better support of multimedia stack and improvements on the multimedia platform and If it gets enough votes, I'm hopeful it'll be picked up.
On Wed, Dec 29, 2021 at 8:02 AM Željko Blaće zblace@mi2.hr wrote:
Nice. This looks much better than before. Previously it felt so many people had high hopes for projects that are outside of capacities that are committed to this project. I feel this needs to be a super clear fact from the start and not ask for the global community to commit XYZ number of hours in the actions of promoting, translating, proposing and decision making processes when developers can commit far less back to the same community. Otherwise it feels like unbalanced work from a more holistic perspective, but this is also non-exceptional...no? _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- Amir (he/him)
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- GN.
2021* *Celebrating 20 years of Wikipedia*
Wikimania: https://wikimania.wikimedia.org/wiki/User:Gnangarra Noongarpedia: https://incubator.wikimedia.org/wiki/Wp/nys/Main_Page My print shop: https://www.redbubble.com/people/Gnangarra/shop?asc=u
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- Amir (he/him)
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
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. 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 ladsgroup@gmail.com 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/... [2] There is a classic book in this topic called "The Mythical Man-month"
On Wed, Dec 29, 2021 at 11:41 AM Gnangarra gnangarra@gmail.com wrote:
we have to vote for regular maintenance and support for essential functions like uploading files which is the core mission of Wikimedia Commons
So where is the best current place to discuss scaling Commons, and all
that entails?
My impression is that we don't have one. All we hear is "it needs to be planned", but there is no transparency on what that planning involves or when it actually happens.
I'd be surprised if the bottleneck were people or budget
The main problem I see is that we end up in this kind of situation. Scaling and bug fixing critical features should be part of the annual budget. Each line of code deployed to production wikis should have an owner and associated maintenance budget each year. Without this, the team will not even commit reviews - see the thread on wikitech a few months back where a volunteer programmer willing to work on Upload Wizard was basically told "We will not review your code. Go fork."
Some examples from recent discussions
Also improvements to the Upload Wizard. There are quite a few open items in Phab on this.
I really hope you will have better luck than others with bringing this issue up in the priority list for next year - multimedia support is growing more outdated by the minute.
Strainu
Pe joi, 30 decembrie 2021, Samuel Klein meta.sj@gmail.com a scris:
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. 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 ladsgroup@gmail.com
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/...
[2] There is a classic book in this topic called "The Mythical Man-month"
On Wed, Dec 29, 2021 at 11:41 AM Gnangarra gnangarra@gmail.com wrote:
we have to vote for regular maintenance and support for
essential functions like uploading files which is the core mission of Wikimedia Commons
On Fri, Dec 31, 2021 at 12:42 AM Strainu strainu10@gmail.com wrote:
So where is the best current place to discuss scaling Commons, and all
that entails?
My impression is that we don't have one. All we hear is "it needs to be planned", but there is no transparency on what that planning involves or when it actually happens.
I'd be surprised if the bottleneck were people or budget
The main problem I see is that we end up in this kind of situation. Scaling and bug fixing critical features should be part of the annual budget. Each line of code deployed to production wikis should have an owner and associated maintenance budget each year. Without this, the team will not even commit reviews - see the thread on wikitech a few months back where a volunteer programmer willing to work on Upload Wizard was basically told "We will not review your code. Go fork."
There is "code stewardship program" and its goal is to find owners for components that don't have an owner (or undeploy them). Sometimes it's successful, sometimes it's not. I have been asking for a maintainer for FlaggedRevs for four years now, beta cluster is suffering from a similar situation, etc. etc. It takes time to find an owner for everything, to fill the gaps in places we don't have a team to handle those (e.g. Multimedia, you can't just hand over that to team responsible for security for example). More info at https://www.mediawiki.org/wiki/Code_stewardship_reviews
Some examples from recent discussions
Also improvements to the Upload Wizard. There are quite a few open items in Phab on this.
+1
I really hope you will have better luck than others with bringing this issue up in the priority list for next year - multimedia support is growing more outdated by the minute.
Honestly, the situation is more dire than you think. For example, until a couple months ago, we didn't have backups for the media files. There was a live copy in the secondary datacenter but for example if due to a software issue, we lost some files, they were gone. I would like to thank Jaime Crespo for pushing for it and implementing the backups.
But I beat my drum again, it's not something you can fix overnight. I'm sure people are monitoring this mailing list and are aware of the problem.
Best
Strainu
Pe joi, 30 decembrie 2021, Samuel Klein meta.sj@gmail.com a scris:
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. 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 ladsgroup@gmail.com
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/...
[2] There is a classic book in this topic called "The Mythical
Man-month"
On Wed, Dec 29, 2021 at 11:41 AM Gnangarra gnangarra@gmail.com wrote:
we have to vote for regular maintenance and support for
essential functions like uploading files which is the core mission of Wikimedia Commons _______________________________________________ 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/
“until a couple months ago, we didn't have backups for the media files”
How is that even possible?
Cheers, Peter
From: Amir Sarabadani [mailto:ladsgroup@gmail.com] Sent: 01 January 2022 08:42 To: Wikitech-l Cc: Wikimedia Mailing List; Wikimedia Commons Discussion List Subject: [Wikimedia-l] Re: [Wikitech-l] Re: Uplifting the multimedia stack (was: Community Wishlist Survery)
On Fri, Dec 31, 2021 at 12:42 AM Strainu strainu10@gmail.com wrote:
So where is the best current place to discuss scaling Commons, and all that entails?
My impression is that we don't have one. All we hear is "it needs to be planned", but there is no transparency on what that planning involves or when it actually happens.
I'd be surprised if the bottleneck were people or budget
The main problem I see is that we end up in this kind of situation. Scaling and bug fixing critical features should be part of the annual budget. Each line of code deployed to production wikis should have an owner and associated maintenance budget each year. Without this, the team will not even commit reviews - see the thread on wikitech a few months back where a volunteer programmer willing to work on Upload Wizard was basically told "We will not review your code. Go fork."
There is "code stewardship program" and its goal is to find owners for components that don't have an owner (or undeploy them). Sometimes it's successful, sometimes it's not. I have been asking for a maintainer for FlaggedRevs for four years now, beta cluster is suffering from a similar situation, etc. etc. It takes time to find an owner for everything, to fill the gaps in places we don't have a team to handle those (e.g. Multimedia, you can't just hand over that to team responsible for security for example). More info at https://www.mediawiki.org/wiki/Code_stewardship_reviews
Some examples from recent discussions
Also improvements to the Upload Wizard. There are quite a few open items in Phab on this.
+1
I really hope you will have better luck than others with bringing this issue up in the priority list for next year - multimedia support is growing more outdated by the minute.
Honestly, the situation is more dire than you think. For example, until a couple months ago, we didn't have backups for the media files. There was a live copy in the secondary datacenter but for example if due to a software issue, we lost some files, they were gone. I would like to thank Jaime Crespo for pushing for it and implementing the backups.
But I beat my drum again, it's not something you can fix overnight. I'm sure people are monitoring this mailing list and are aware of the problem.
Best
Strainu
Pe joi, 30 decembrie 2021, Samuel Klein meta.sj@gmail.com a scris:
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. 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 ladsgroup@gmail.com 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/... [2] There is a classic book in this topic called "The Mythical Man-month"
On Wed, Dec 29, 2021 at 11:41 AM Gnangarra gnangarra@gmail.com wrote:
we have to vote for regular maintenance and support for essential functions like uploading files which is the core mission of Wikimedia Commons _______________________________________________
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/
Writing in my volunteer capacity:
On Sat, 1 Jan 2022, 08:43 Amir Sarabadani ladsgroup@gmail.com wrote:
Honestly, the situation is more dire than you think. For example, until a couple months ago, we didn't have backups for the media files. There was a live copy in the secondary datacenter but for example if due to a software issue, we lost some files, they were gone. I would like to thank Jaime Crespo for pushing for it and implementing the backups.
But I beat my drum again, it's not something you can fix overnight. I'm sure people are monitoring this mailing list and are aware of the problem.
[My goal in this post is to ficus effort and reduce frustration.]
Yes, people reading here are aware, and absolutely none of them expects this (i.e. multimedia technical debt and missing features) to be fixed overnight.
What's lacking, as you pointed out, is ownership of the problem. To own the problem, one must have *both* technical understanding of the issues *and* a mandate to devote resources to addressing them.
It is this *combination* that we don't have at the moment. Lots of technical people are aware, and some of them quite willing to work toward addressing the issues, but they are not empowered to set priorities and commit resources for an effort of that scale, and the problems, for the most part, don't easily lend themselves to volunteer development.
It seems to me there are *very few* people who could change status quo, not much more than a handful: the Foundation's executive leadership (in its annual planning work, coming up this first quarter of 2022), and the Board of Trustees.
Therefore, the greatest contribution the rest of us could make toward seeing this work get resourced is to help make the case to the executives (including the new CEO, just entering the role) with clear and compelling illustrations of the *mission impact* of such investment. In parallel, interested engineers and middle managers could help by offering rough effort estimates for some components, a roadmap, an overview of alternatives considered and a rationale for a recommended approach, etc.
But this would all be preparatory and supporting work toward *a resourcing decision* being made. So long as such a decision isn't made, no significant work on this can happen.
Finally, while it is easy to agree that *this* is necessary and useful on its own, to actual resource it in the coming annual plan it would be necessary to argue that it is *more* useful and necessary than some *other* work, itself also necessary and useful.
Another thing that may help is being explicit about just how important this is, even literally saying things like "this would have far more impact on our X goal than initiative A, B, or C", naming actual resourced or potentially resourced things. It is sometimes difficult for managers who aren't practicing Wikimedia volunteers to assess just how necessary different necessary things are, from different community perspectives.
And of course, one such opinion, or a handful, would not be a solid base for resourcing decisions, so perhaps a large-scale ranking survey of some sort would be helpful, as SJ implicitly suggested in the original post.
Cheers,
A. (In my volunteer capacity)
Hi Asaf,
That's a good response, but I'm not sure it provides a practical way forward. How can volunteers bring this issue to the attention of the WMF leadership to get the allocation of the time of Wikimedia staff who can take ownership implement changes here?
Presumably emails on these lists have relatively little impact at the most senior levels, so they aren't a good way forward - and similarly on Phabricator.
The Wishlist provides a way of showcasing issues and a relatively clear way forward to get them implemented, but with really limited capacity.
How would a case for technical support be made apart from that? It's not clear if a simple survey would be sufficient. Would an RfC and discussion on meta help? Does it need the media to be involved to make it a public crisis? Or should it be proposed as a grant request, perhaps for a Wikimedia affiliate to implement? Or is there another avenue that could be persued? Bearing in mind that there's no practical way for community members to propose changes to the WMF annual plan for multiple years now.
Sorry to defocus things and express more frustration, but I think there should be a clear way forward with this type of issue, which isn't obvious right now. Personally, my hopes are on the Wishlist, although I'll be reposting a 14-year-old issue there for the fifth time when that process opens on the 10th January...
Thanks, Mike
On 1/1/22 20:10:43, Asaf Bartov wrote:
Writing in my volunteer capacity:
On Sat, 1 Jan 2022, 08:43 Amir Sarabadani <ladsgroup@gmail.com mailto:ladsgroup@gmail.com> wrote:
Honestly, the situation is more dire than you think. For example, until a couple months ago, we didn't have backups for the media files. There was a live copy in the secondary datacenter but for example if due to a software issue, we lost some files, they were gone. I would like to thank Jaime Crespo for pushing for it and implementing the backups. But I beat my drum again, it's not something you can fix overnight. I'm sure people are monitoring this mailing list and are aware of the problem.
[My goal in this post is to ficus effort and reduce frustration.]
Yes, people reading here are aware, and absolutely none of them expects this (i.e. multimedia technical debt and missing features) to be fixed overnight.
What's lacking, as you pointed out, is ownership of the problem. To own the problem, one must have *both* technical understanding of the issues *and* a mandate to devote resources to addressing them.
It is this *combination* that we don't have at the moment. Lots of technical people are aware, and some of them quite willing to work toward addressing the issues, but they are not empowered to set priorities and commit resources for an effort of that scale, and the problems, for the most part, don't easily lend themselves to volunteer development.
It seems to me there are *very few* people who could change status quo, not much more than a handful: the Foundation's executive leadership (in its annual planning work, coming up this first quarter of 2022), and the Board of Trustees.
Therefore, the greatest contribution the rest of us could make toward seeing this work get resourced is to help make the case to the executives (including the new CEO, just entering the role) with clear and compelling illustrations of the *mission impact* of such investment. In parallel, interested engineers and middle managers could help by offering rough effort estimates for some components, a roadmap, an overview of alternatives considered and a rationale for a recommended approach, etc.
But this would all be preparatory and supporting work toward *a resourcing decision* being made. So long as such a decision isn't made, no significant work on this can happen.
Finally, while it is easy to agree that *this* is necessary and useful on its own, to actual resource it in the coming annual plan it would be necessary to argue that it is *more* useful and necessary than some *other* work, itself also necessary and useful.
Another thing that may help is being explicit about just how important this is, even literally saying things like "this would have far more impact on our X goal than initiative A, B, or C", naming actual resourced or potentially resourced things. It is sometimes difficult for managers who aren't practicing Wikimedia volunteers to assess just how necessary different necessary things are, from different community perspectives.
And of course, one such opinion, or a handful, would not be a solid base for resourcing decisions, so perhaps a large-scale ranking survey of some sort would be helpful, as SJ implicitly suggested in the original post.
Cheers,
A. (In my volunteer capacity)
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
I see part of the problem is that the contributors experiencing the biggest impact arent the same contributors that have the technical skill sets to appropriately explain and understand the issues. Adding the the need to be able to make comparisons between other areas of need just makes its even more difficult. None of us want to be putting forward arguments that say that the WMF should neglect supporting Wikidata functions so that repairs can be made to Commons functions, this is a loss for everyone.
I know that the experience of the volunteers who spent 3 months in limbo trying to get the 2021 Wikimania videos converted and uploaded will feed back through to WMF hierarchy highlighting, but whether that taken has a priority needing to be fixed or bug to swatted is unknown. The underlying issue isnt so much that we need to fix software(though we do) as it is that we have structural problems in the way the WMF technical team interacts with each project. With that its ability to keep with the growth and maintenance necessary to function effectively.
The point I raised is that like many other aspects the software and technical support along with its communication channels havent effectively kept up with the needs of the community, not even the wishlist itself can keep up with it. This is why I said we need to pause and rethink the whole process, focus on clearing whats on the phabricator while we do so.
The frustration comes from being able to upload a video to the likes of youtube or vimeo in about 15-20 minutes, where as its takes 30 hours to convert to webm on proprietary software which I have to pay for and then 10-12 attempts over the space of a week or two to upload the video to commons. The available tools like Videoconvertor, and Video2Commons are so unstable that they dont survive the 30 hour conversion process.
On Sun, 2 Jan 2022 at 04:38, Mike Peel email@mikepeel.net wrote:
Hi Asaf,
That's a good response, but I'm not sure it provides a practical way forward. How can volunteers bring this issue to the attention of the WMF leadership to get the allocation of the time of Wikimedia staff who can take ownership implement changes here?
Presumably emails on these lists have relatively little impact at the most senior levels, so they aren't a good way forward - and similarly on Phabricator.
The Wishlist provides a way of showcasing issues and a relatively clear way forward to get them implemented, but with really limited capacity.
How would a case for technical support be made apart from that? It's not clear if a simple survey would be sufficient. Would an RfC and discussion on meta help? Does it need the media to be involved to make it a public crisis? Or should it be proposed as a grant request, perhaps for a Wikimedia affiliate to implement? Or is there another avenue that could be persued? Bearing in mind that there's no practical way for community members to propose changes to the WMF annual plan for multiple years now.
Sorry to defocus things and express more frustration, but I think there should be a clear way forward with this type of issue, which isn't obvious right now. Personally, my hopes are on the Wishlist, although I'll be reposting a 14-year-old issue there for the fifth time when that process opens on the 10th January...
Thanks, Mike
On 1/1/22 20:10:43, Asaf Bartov wrote:
Writing in my volunteer capacity:
On Sat, 1 Jan 2022, 08:43 Amir Sarabadani <ladsgroup@gmail.com mailto:ladsgroup@gmail.com> wrote:
Honestly, the situation is more dire than you think. For example, until a couple months ago, we didn't have backups for the media files. There was a live copy in the secondary datacenter but for example if due to a software issue, we lost some files, they were gone. I would like to thank Jaime Crespo for pushing for it and implementing the backups. But I beat my drum again, it's not something you can fix overnight. I'm sure people are monitoring this mailing list and are aware of the problem.
[My goal in this post is to ficus effort and reduce frustration.]
Yes, people reading here are aware, and absolutely none of them expects this (i.e. multimedia technical debt and missing features) to be fixed overnight.
What's lacking, as you pointed out, is ownership of the problem. To own the problem, one must have *both* technical understanding of the issues *and* a mandate to devote resources to addressing them.
It is this *combination* that we don't have at the moment. Lots of technical people are aware, and some of them quite willing to work toward addressing the issues, but they are not empowered to set priorities and commit resources for an effort of that scale, and the problems, for the most part, don't easily lend themselves to volunteer development.
It seems to me there are *very few* people who could change status quo, not much more than a handful: the Foundation's executive leadership (in its annual planning work, coming up this first quarter of 2022), and the Board of Trustees.
Therefore, the greatest contribution the rest of us could make toward seeing this work get resourced is to help make the case to the executives (including the new CEO, just entering the role) with clear and compelling illustrations of the *mission impact* of such investment. In parallel, interested engineers and middle managers could help by offering rough effort estimates for some components, a roadmap, an overview of alternatives considered and a rationale for a recommended approach, etc.
But this would all be preparatory and supporting work toward *a resourcing decision* being made. So long as such a decision isn't made, no significant work on this can happen.
Finally, while it is easy to agree that *this* is necessary and useful on its own, to actual resource it in the coming annual plan it would be necessary to argue that it is *more* useful and necessary than some *other* work, itself also necessary and useful.
Another thing that may help is being explicit about just how important this is, even literally saying things like "this would have far more impact on our X goal than initiative A, B, or C", naming actual resourced or potentially resourced things. It is sometimes difficult for managers who aren't practicing Wikimedia volunteers to assess just how necessary different necessary things are, from different community perspectives.
And of course, one such opinion, or a handful, would not be a solid base for resourcing decisions, so perhaps a large-scale ranking survey of some sort would be helpful, as SJ implicitly suggested in the original
post.
Cheers,
A. (In my volunteer capacity)
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines
at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/...
To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Commons-l mailing list -- commons-l@lists.wikimedia.org To unsubscribe send an email to commons-l-leave@lists.wikimedia.org
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
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 zblace@mi2.hr Sent: Sunday, January 2, 2022 12:17 PM To: Wikimedia Mailing List wikimedia-l@lists.wikimedia.org Cc: Wikimedia Commons Discussion List commons-l@lists.wikimedia.org; Wikitech-l wikitech-l@lists.wikimedia.org 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
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 < galder158@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 zblace@mi2.hr *Sent:* Sunday, January 2, 2022 12:17 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Cc:* Wikimedia Commons Discussion List commons-l@lists.wikimedia.org; Wikitech-l wikitech-l@lists.wikimedia.org *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/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Hoi, There should be several mechanisms determining what work gets done. What Asaf describes is a budget based process. Another mechanism is centred around responsibility.
The granularity of responsibility does not negate that the buck stops at a certain level. When responsibility has no consequences, what follows is finger pointing. Management, board maintain that a budget is required and departments maintain that they have no budget. In the absence of risk control , it follows that risk can grow to potentially disastrous levels. This has been recognised for both Commons and Wikidata; there is no backup for Commons and the software that runs Wikidata has the potential to break its functionality. A complicating factor is the divide in functionality maintained by the WMF and what the community produces. For the latter there is no chain of responsibility.
In addition to all this there is a sense of ownership and priority; WMF maintains Wikipedia with English Wikipedia as its focus. This is made worse by a "community" of self appointed experts who will not accept that results of the past will not predict what transpires in the future. As for the WMF board, I was a candidate for the board and was quickly told that board members do not define any agenda, they assess plans and results presented by the WMF. Health and money became an issue at my home, it is why I did not campaign for a seat.
So how to move on. First, the WMF has to take ownership of the complete technical environment used by our communities. A security analysis is to be performed for the graded risks to our projects. Given ownership, it is no longer feasible for any level of management to hide behind budgets or lack of budgets. Once it is clear that a particular functionality is in danger of long term breakage, an initial project plan is to be published like was done for Wikidata. This provides awareness of the critical issues we face and it is a deciding argument for out of budget activities. It also provides arguments for realignment of priorities in existing budgets and provides the basis for overall refinement.
Deciding what to do in the case of major breakage is relatively straight forward. It becomes problematic when minor breakage is to be considered, when it is only a small part of our community that suffers. WMF uses the agile approach and it has a mechanism called "user stories". So when something breaks or is likely to break, the question is what user stories are affected, how much of an impact it has on our public and how much impact it has on our editors. Once we gain a grip on what fails us, we can refine it by adding project and language as complicating factors.
Thanks, GerardM .. PS happy new year
On Sat, 1 Jan 2022 at 21:11, Asaf Bartov asaf.bartov@gmail.com wrote:
Writing in my volunteer capacity:
On Sat, 1 Jan 2022, 08:43 Amir Sarabadani ladsgroup@gmail.com wrote:
Honestly, the situation is more dire than you think. For example, until a couple months ago, we didn't have backups for the media files. There was a live copy in the secondary datacenter but for example if due to a software issue, we lost some files, they were gone. I would like to thank Jaime Crespo for pushing for it and implementing the backups.
But I beat my drum again, it's not something you can fix overnight. I'm sure people are monitoring this mailing list and are aware of the problem.
[My goal in this post is to ficus effort and reduce frustration.]
Yes, people reading here are aware, and absolutely none of them expects this (i.e. multimedia technical debt and missing features) to be fixed overnight.
What's lacking, as you pointed out, is ownership of the problem. To own the problem, one must have *both* technical understanding of the issues *and* a mandate to devote resources to addressing them.
It is this *combination* that we don't have at the moment. Lots of technical people are aware, and some of them quite willing to work toward addressing the issues, but they are not empowered to set priorities and commit resources for an effort of that scale, and the problems, for the most part, don't easily lend themselves to volunteer development.
It seems to me there are *very few* people who could change status quo, not much more than a handful: the Foundation's executive leadership (in its annual planning work, coming up this first quarter of 2022), and the Board of Trustees.
Therefore, the greatest contribution the rest of us could make toward seeing this work get resourced is to help make the case to the executives (including the new CEO, just entering the role) with clear and compelling illustrations of the *mission impact* of such investment. In parallel, interested engineers and middle managers could help by offering rough effort estimates for some components, a roadmap, an overview of alternatives considered and a rationale for a recommended approach, etc.
But this would all be preparatory and supporting work toward *a resourcing decision* being made. So long as such a decision isn't made, no significant work on this can happen.
Finally, while it is easy to agree that *this* is necessary and useful on its own, to actual resource it in the coming annual plan it would be necessary to argue that it is *more* useful and necessary than some *other* work, itself also necessary and useful.
Another thing that may help is being explicit about just how important this is, even literally saying things like "this would have far more impact on our X goal than initiative A, B, or C", naming actual resourced or potentially resourced things. It is sometimes difficult for managers who aren't practicing Wikimedia volunteers to assess just how necessary different necessary things are, from different community perspectives.
And of course, one such opinion, or a handful, would not be a solid base for resourcing decisions, so perhaps a large-scale ranking survey of some sort would be helpful, as SJ implicitly suggested in the original post.
Cheers,
A. (In my volunteer capacity)
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Hi,
On 1/1/22 12:10, Asaf Bartov wrote:
It seems to me there are *very few* people who could change status quo, not much more than a handful: the Foundation's executive leadership (in its annual planning work, coming up this first quarter of 2022), and the Board of Trustees.
If the goal is to get paid WMF staff to fix the issues, then you're correct. However, I do not believe that as a solution is healthy long-term. The WMF isn't perfect and I don't think it's desirable to have a huge WMF that tries to do everything and has a monopoly on technical prioritization.
The technical stack must be co-owned by volunteers and paid staff from different orgs at all levels. It's significantly more straightforward now for trusted volunteers to get NDA/deployment access than it used to be, there are dedicated training sessions, etc.
Given that the multimedia stack is neglected and the WMF has given no indication it intends to work on/fix the problem, we should be recruiting people outside the WMF's paid staff who are interested in working on this and give them the necessary access/mentorship to get it done. Given the amount of work on e.g. T40010[1] to develop an alternative SVG renderer, I'm sure those people exist.
Take moving Thumbor to Buster[2] for example. That requires forward-porting some Debian packages written Python, and then testing in WMCS that there's no horrible regressions in newer imagemagick, librsvg, etc. I'm always happy to mentor people w/r to Debian packaging (and have done so in the past), and there are a decent amount of people in our community who know Python, and likely others from the Commons community who would be willing to help with testing and dealing with whatever fallout.
So I think the status quo can be changed by just about anyone who is motivated to do so, not by trying to convince the WMF to change its prioritization, but just by doing the work. We should be empowering those people rather than continuing to further entrench a WMF technical monopoly.
[1] https://phabricator.wikimedia.org/T40010 [2] https://phabricator.wikimedia.org/T216815
-- Legoktm
Its one thing allowing access and supporting volunteers, its another to be abrogating it's responsibility to ensure the stable running of the projecst for which its collecting millions of dollars in donations every year.
WMF key purpose is to provide the infrastructure need for every project to operate, at the moment there is no apparent effort from the WMF to do that for Wikimedia Commons despites it being the vital source for every projects multimedia. This isnt one off missed opportunity, its failed in that responsibility for year after year and now we as contributors are baring the fruits of that neglect.
On Tue, 11 Jan 2022 at 14:01, Kunal Mehta legoktm@debian.org wrote:
Hi,
On 1/1/22 12:10, Asaf Bartov wrote:
It seems to me there are *very few* people who could change status quo, not much more than a handful: the Foundation's executive leadership (in its annual planning work, coming up this first quarter of 2022), and the Board of Trustees.
If the goal is to get paid WMF staff to fix the issues, then you're correct. However, I do not believe that as a solution is healthy long-term. The WMF isn't perfect and I don't think it's desirable to have a huge WMF that tries to do everything and has a monopoly on technical prioritization.
The technical stack must be co-owned by volunteers and paid staff from different orgs at all levels. It's significantly more straightforward now for trusted volunteers to get NDA/deployment access than it used to be, there are dedicated training sessions, etc.
Given that the multimedia stack is neglected and the WMF has given no indication it intends to work on/fix the problem, we should be recruiting people outside the WMF's paid staff who are interested in working on this and give them the necessary access/mentorship to get it done. Given the amount of work on e.g. T40010[1] to develop an alternative SVG renderer, I'm sure those people exist.
Take moving Thumbor to Buster[2] for example. That requires forward-porting some Debian packages written Python, and then testing in WMCS that there's no horrible regressions in newer imagemagick, librsvg, etc. I'm always happy to mentor people w/r to Debian packaging (and have done so in the past), and there are a decent amount of people in our community who know Python, and likely others from the Commons community who would be willing to help with testing and dealing with whatever fallout.
So I think the status quo can be changed by just about anyone who is motivated to do so, not by trying to convince the WMF to change its prioritization, but just by doing the work. We should be empowering those people rather than continuing to further entrench a WMF technical monopoly.
[1] https://phabricator.wikimedia.org/T40010 [2] https://phabricator.wikimedia.org/T216815
-- Legoktm _______________________________________________ Commons-l mailing list -- commons-l@lists.wikimedia.org To unsubscribe send an email to commons-l-leave@lists.wikimedia.org
I agree a bit with both Kunal and Asaf here,
I do not think our goal is to get it done **by paid WMF staff**, but it is also true that today that is the only viable alternative to get major technical work done. I do not think it is entirely fair to state that "status quo can be changed by just about anyone who is motivated to do so (...) just by doing the work". It is not a lack of motivation that hinders our movement technically, but a lack of resources and shared governance. I am not sure if the implication is that the movement should be expecting free (expensive) labor to fix these issues, but even then there is a very high bar for engagement with the technical community in order to have access and a significant bottleneck in both technical review of changes and engagement with technical and other communities for changes that impact them.
It is not only unfair to expect this to be solved by volunteer developers, it is not working. Why should we expect this will change?
Open source and accepting volunteer contributions is nowhere near where our goal should be. We need better governance and distribution of resources and responsibilities to volunteer **and professional** organizations that can bridge the gaps in our technological stack.
How we move from a state where WMF is doing all the technical development and deciding technical choices is a bigger issue. And perhaps it is in that issue that we will find an answer on how to improve the state of our tech ecosystem. How do we get from a WMF-centered development model to a decentralized one?
It is a bit disappointing the lack of emphasis our movement placed in this discussion in our strategy process thus far; and how we have set aside the little that did make to the recommendations in this area since they were published.
Chico Venancio
Em ter., 11 de jan. de 2022 às 03:01, Kunal Mehta legoktm@debian.org escreveu:
Hi,
On 1/1/22 12:10, Asaf Bartov wrote:
It seems to me there are *very few* people who could change status quo, not much more than a handful: the Foundation's executive leadership (in its annual planning work, coming up this first quarter of 2022), and the Board of Trustees.
If the goal is to get paid WMF staff to fix the issues, then you're correct. However, I do not believe that as a solution is healthy long-term. The WMF isn't perfect and I don't think it's desirable to have a huge WMF that tries to do everything and has a monopoly on technical prioritization.
The technical stack must be co-owned by volunteers and paid staff from different orgs at all levels. It's significantly more straightforward now for trusted volunteers to get NDA/deployment access than it used to be, there are dedicated training sessions, etc.
Given that the multimedia stack is neglected and the WMF has given no indication it intends to work on/fix the problem, we should be recruiting people outside the WMF's paid staff who are interested in working on this and give them the necessary access/mentorship to get it done. Given the amount of work on e.g. T40010[1] to develop an alternative SVG renderer, I'm sure those people exist.
Take moving Thumbor to Buster[2] for example. That requires forward-porting some Debian packages written Python, and then testing in WMCS that there's no horrible regressions in newer imagemagick, librsvg, etc. I'm always happy to mentor people w/r to Debian packaging (and have done so in the past), and there are a decent amount of people in our community who know Python, and likely others from the Commons community who would be willing to help with testing and dealing with whatever fallout.
So I think the status quo can be changed by just about anyone who is motivated to do so, not by trying to convince the WMF to change its prioritization, but just by doing the work. We should be empowering those people rather than continuing to further entrench a WMF technical monopoly.
[1] https://phabricator.wikimedia.org/T40010 [2] https://phabricator.wikimedia.org/T216815
-- Legoktm _______________________________________________ Commons-l mailing list -- commons-l@lists.wikimedia.org To unsubscribe send an email to commons-l-leave@lists.wikimedia.org
În mar., 11 ian. 2022 la 08:01, Kunal Mehta legoktm@debian.org a scris:
So I think the status quo can be changed by just about anyone who is motivated to do so, not by trying to convince the WMF to change its prioritization, but just by doing the work. We should be empowering those people rather than continuing to further entrench a WMF technical monopoly.
Counterexample: https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/m... (this was the situation that I quoted in my first email on this thread as the WMF refusing to even do reviews).
Maybe it's just the multimedia part that it's in this desperate situation, but I can totally see volunteer developers getting discouraged quickly if their patches are outright ignored.
Strainu
Hello, I'd like to refer to the original subject of the discussion - tomorrow is the last day for submitting proposals for the Community Wishlist Survey 2022.
Apart from that, everyone is welcome to translate, promote, and discuss proposals: https://diff.wikimedia.org/2022/01/10/what-improvements-in-wikimedia-platfor...
Best wishes,
Szymon Grabarczuk (he/him)
Community Relations Specialist
Wikimedia Foundation
On Wed, Jan 12, 2022 at 2:43 PM Strainu strainu10@gmail.com wrote:
În mar., 11 ian. 2022 la 08:01, Kunal Mehta legoktm@debian.org a scris:
So I think the status quo can be changed by just about anyone who is motivated to do so, not by trying to convince the WMF to change its prioritization, but just by doing the work. We should be empowering those people rather than continuing to further entrench a WMF technical monopoly.
Counterexample:
https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/m... (this was the situation that I quoted in my first email on this thread as the WMF refusing to even do reviews).
Maybe it's just the multimedia part that it's in this desperate situation, but I can totally see volunteer developers getting discouraged quickly if their patches are outright ignored.
Strainu _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
I asked on th talk page, but posting here as well: -- what's the intended interaction b/t proposals from past years and the current list? Do people need to find and repost older proposals they want to see included? Is there a mechanism for refactoring sets of related proposals?
🌍🌏🌎🌑
On Sat., Jan. 22, 2022, 8:08 a.m. Szymon Grabarczuk, < sgrabarczuk@wikimedia.org> wrote:
Hello, I'd like to refer to the original subject of the discussion - tomorrow is the last day for submitting proposals for the Community Wishlist Survey 2022.
Apart from that, everyone is welcome to translate, promote, and discuss proposals: https://diff.wikimedia.org/2022/01/10/what-improvements-in-wikimedia-platfor...
Best wishes,
Szymon Grabarczuk (he/him)
Community Relations Specialist
Wikimedia Foundation
On Wed, Jan 12, 2022 at 2:43 PM Strainu strainu10@gmail.com wrote:
În mar., 11 ian. 2022 la 08:01, Kunal Mehta legoktm@debian.org a scris:
So I think the status quo can be changed by just about anyone who is motivated to do so, not by trying to convince the WMF to change its prioritization, but just by doing the work. We should be empowering those people rather than continuing to further entrench a WMF technical monopoly.
Counterexample:
https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/m... (this was the situation that I quoted in my first email on this thread as the WMF refusing to even do reviews).
Maybe it's just the multimedia part that it's in this desperate situation, but I can totally see volunteer developers getting discouraged quickly if their patches are outright ignored.
Strainu _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@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/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
In the past, we were often told that a specific proposal even if it gains enough support will not be implemented because this is too difficult / not enough resources / whatever. My understanding is that it does not make sense to suggest such proposals again. On the contrary, if the proposal gained a lot of support, could have been implemented but was not implemented I would say yes, report it again.
Best Yaroslav
On Sat, Jan 22, 2022 at 4:30 PM Samuel Klein meta.sj@gmail.com wrote:
I asked on th talk page, but posting here as well: -- what's the intended interaction b/t proposals from past years and the current list? Do people need to find and repost older proposals they want to see included? Is there a mechanism for refactoring sets of related proposals?
🌍🌏🌎🌑
On Sat., Jan. 22, 2022, 8:08 a.m. Szymon Grabarczuk, < sgrabarczuk@wikimedia.org> wrote:
Hello, I'd like to refer to the original subject of the discussion - tomorrow is the last day for submitting proposals for the Community Wishlist Survey 2022.
Apart from that, everyone is welcome to translate, promote, and discuss proposals: https://diff.wikimedia.org/2022/01/10/what-improvements-in-wikimedia-platfor...
Best wishes,
Szymon Grabarczuk (he/him)
Community Relations Specialist
Wikimedia Foundation
On Wed, Jan 12, 2022 at 2:43 PM Strainu strainu10@gmail.com wrote:
În mar., 11 ian. 2022 la 08:01, Kunal Mehta legoktm@debian.org a scris:
So I think the status quo can be changed by just about anyone who is motivated to do so, not by trying to convince the WMF to change its prioritization, but just by doing the work. We should be empowering those people rather than continuing to further entrench a WMF technical monopoly.
Counterexample:
https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/m... (this was the situation that I quoted in my first email on this thread as the WMF refusing to even do reviews).
Maybe it's just the multimedia part that it's in this desperate situation, but I can totally see volunteer developers getting discouraged quickly if their patches are outright ignored.
Strainu _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@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/... To unsubscribe send an email to wikimedia-l-leave@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/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
I appreciate all of the comments; still unsure where to more persistently host the conversation, but for now I posted this still-arbitrary list on Commons https://commons.wikimedia.org/wiki/User:Sj/multimedia. (adding other items mentioned in this thread) SJ
~~~~ - *File formats*: Support high-demand formats – e.g. CSV, CML https://phabricator.wikimedia.org/T18491, + hundreds of other https://phabricator.wikimedia.org/T297514 open tickets - *Uploads*: Improve bulk, large, and video uploads. + *Bulk conversion* for video uploads (videoconverter / video2commons are broken) + *Upload Wizard* upgrades (timeouts https://phabricator.wikimedia.org/T267492, batch renaming, batch imports https://phabricator.wikimedia.org/T281599) - *Downloads*: Fix multi-download (Imker https://commons.wikimedia.org/wiki/Commons:Imker_(batch_download) is broken) + Make public dumps https://phabricator.wikimedia.org/T298394 (stale since 2013) - *Video playback*: Debug + roll out the videojs https://phabricator.wikimedia.org/T248418 player - *Search*: Bring CQS back up https://phabricator.wikimedia.org/T297454. Implement a noauth option https://phabricator.wikimedia.org/T297995 for tools - *General*: Move to a blazegraph alternative (for wqcs) + *Images*: Update thumbor https://phabricator.wikimedia.org/T216815 and librsvg https://phabricator.wikimedia.org/T193352 || redesign https://phabricator.wikimedia.org/T28741 the image table *- Curation*: Simpler content assessment workflow, like en:wp's https://en.wikipedia.org/wiki/Wikipedia:Content_assessment (QI/VP doesn't scale)
Yes, I did not purport to offer an easy solution. I tried to clarify *what needs to happen* for significant progress on these issues, without suggesting that it is easy to make that happen.
As I mentioned, a new CEO is beginning work this week, and one of the (many) items on her to-do list is to improve and rationalize the Foundation's annual planning process, and cross-departmental planning and decision-making. Let's give her some time and wait for some guidance on this question of venue, i.e. how and where communities may *effectively* express needs and affect priorities.
In the meantime, I repeat my suggestion that adding non-technical concise statements of impact to each issue would be a big help. For example, I (and many of you) know the impact of our slow/broken video conversion and upload workflows, but it would be helpful to add to SJ's "*Bulk conversion* for video uploads (videoconverter / video2commons are broken)" an impact statement such as "this is deterring video uploads from casual contributors".
Cheers,
A. (volunteer capacity)
On Sun, Jan 2, 2022 at 10:45 PM Samuel Klein meta.sj@gmail.com wrote:
I appreciate all of the comments; still unsure where to more persistently host the conversation, but for now I posted this still-arbitrary list on Commons https://commons.wikimedia.org/wiki/User:Sj/multimedia. (adding other items mentioned in this thread) SJ
- *File formats*: Support high-demand formats – e.g. CSV, CML <https://phabricator.wikimedia.org/T18491>, + hundreds of other <https://phabricator.wikimedia.org/T297514> open tickets - *Uploads*: Improve bulk, large, and video uploads. + *Bulk conversion* for video uploads (videoconverter / video2commons are broken) + *Upload Wizard* upgrades (timeouts <https://phabricator.wikimedia.org/T267492>, batch renaming, batch imports <https://phabricator.wikimedia.org/T281599>) - *Downloads*: Fix multi-download (Imker <https://commons.wikimedia.org/wiki/Commons:Imker_(batch_download)> is broken) + Make public dumps <https://phabricator.wikimedia.org/T298394> (stale since 2013) - *Video playback*: Debug + roll out the videojs <https://phabricator.wikimedia.org/T248418> player - *Search*: Bring CQS back up <https://phabricator.wikimedia.org/T297454>. Implement a noauth option <https://phabricator.wikimedia.org/T297995> for tools - *General*: Move to a blazegraph alternative (for wqcs) + *Images*: Update thumbor <https://phabricator.wikimedia.org/T216815> and librsvg <https://phabricator.wikimedia.org/T193352> || redesign <https://phabricator.wikimedia.org/T28741> the image table *- Curation*: Simpler content assessment workflow, like en:wp's <https://en.wikipedia.org/wiki/Wikipedia:Content_assessment> (QI/VP doesn't scale) _______________________________________________ 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/FVA4YJN5OHPRSLACPXYD4XITFG7NNKSL/ To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
The issue is still there. And I don't know if a new CEO will make things change: I assume that there are some team leaders reading this mailing list, but we hardly ever see progress. No one seems to be accountable.
Let's remember that we used to have a book creator that was broken on purpose to change to a new PDF creator that isn't still working property: more than three years ago I opened this ticket and I assume that no one is going to solve this ever: https://phabricator.wikimedia.org/T209837. Because we have a LOT of money. Mountains of money. But there is no one driving our luxury car.
Sincerely Galder ________________________________ From: Asaf Bartov asaf.bartov@gmail.com Sent: Sunday, January 2, 2022 10:08 PM To: Wikimedia Mailing List wikimedia-l@lists.wikimedia.org Cc: Wikimedia developers wikitech-l@lists.wikimedia.org; Wikimedia Commons Discussion List commons-l@lists.wikimedia.org Subject: [Wikimedia-l] Re: [Wikitech-l] Re: Uplifting the multimedia stack (was: Community Wishlist Survery)
Yes, I did not purport to offer an easy solution. I tried to clarify *what needs to happen* for significant progress on these issues, without suggesting that it is easy to make that happen.
As I mentioned, a new CEO is beginning work this week, and one of the (many) items on her to-do list is to improve and rationalize the Foundation's annual planning process, and cross-departmental planning and decision-making. Let's give her some time and wait for some guidance on this question of venue, i.e. how and where communities may *effectively* express needs and affect priorities.
In the meantime, I repeat my suggestion that adding non-technical concise statements of impact to each issue would be a big help. For example, I (and many of you) know the impact of our slow/broken video conversion and upload workflows, but it would be helpful to add to SJ's "Bulk conversion for video uploads (videoconverter / video2commons are broken)" an impact statement such as "this is deterring video uploads from casual contributors".
Cheers,
A. (volunteer capacity)
On Sun, Jan 2, 2022 at 10:45 PM Samuel Klein <meta.sj@gmail.commailto:meta.sj@gmail.com> wrote: I appreciate all of the comments; still unsure where to more persistently host the conversation, but for now I posted this still-arbitrary list on Commonshttps://commons.wikimedia.org/wiki/User:Sj/multimedia. (adding other items mentioned in this thread) SJ
~~~~ - File formats: Support high-demand formats – e.g. CSV, CMLhttps://phabricator.wikimedia.org/T18491, + hundreds of otherhttps://phabricator.wikimedia.org/T297514 open tickets - Uploads: Improve bulk, large, and video uploads. + Bulk conversion for video uploads (videoconverter / video2commons are broken) + Upload Wizard upgrades (timeoutshttps://phabricator.wikimedia.org/T267492, batch renaming, batch importshttps://phabricator.wikimedia.org/T281599) - Downloads: Fix multi-download (Imkerhttps://commons.wikimedia.org/wiki/Commons:Imker_(batch_download) is broken) + Make public dumpshttps://phabricator.wikimedia.org/T298394 (stale since 2013) - Video playback: Debug + roll out the videojshttps://phabricator.wikimedia.org/T248418 player - Search: Bring CQS back uphttps://phabricator.wikimedia.org/T297454. Implement a noauth optionhttps://phabricator.wikimedia.org/T297995 for tools - General: Move to a blazegraph alternative (for wqcs) + Images: Update thumborhttps://phabricator.wikimedia.org/T216815 and librsvghttps://phabricator.wikimedia.org/T193352 || redesignhttps://phabricator.wikimedia.org/T28741 the image table - Curation: Simpler content assessment workflow, like en:wp'shttps://en.wikipedia.org/wiki/Wikipedia:Content_assessment (QI/VP doesn't scale)
_______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto:wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.orgmailto:wikimedia-l-leave@lists.wikimedia.org
-- Asaf Bartov <asaf.bartov@gmail.commailto:asaf.bartov@gmail.com>
Hoi, Only Pallas Athena arrived fully mature in armour from the head of Zeus. We will never have a complete plan when all we do is based on the existence of budgets, it failed us miserably. The way forward is to own our infra structure including all software and decide its worth, its risc and if we must have a huge budget for "unexpected" and use it to prevent and mitigate the breakage of user stories.
It is not fair to blame only any CEO, it is fair to expect from a CEO to acknowledge that only working from budgets gets us in the mess we face. We are a community with differing needs, so explaining urgency in the form of user stories really helps. Thanks, Gerard
On Sun, 2 Jan 2022 at 22:09, Asaf Bartov asaf.bartov@gmail.com wrote:
Yes, I did not purport to offer an easy solution. I tried to clarify *what needs to happen* for significant progress on these issues, without suggesting that it is easy to make that happen.
As I mentioned, a new CEO is beginning work this week, and one of the (many) items on her to-do list is to improve and rationalize the Foundation's annual planning process, and cross-departmental planning and decision-making. Let's give her some time and wait for some guidance on this question of venue, i.e. how and where communities may *effectively* express needs and affect priorities.
In the meantime, I repeat my suggestion that adding non-technical concise statements of impact to each issue would be a big help. For example, I (and many of you) know the impact of our slow/broken video conversion and upload workflows, but it would be helpful to add to SJ's "*Bulk conversion* for video uploads (videoconverter / video2commons are broken)" an impact statement such as "this is deterring video uploads from casual contributors".
Cheers,
A. (volunteer capacity)
On Sun, Jan 2, 2022 at 10:45 PM Samuel Klein meta.sj@gmail.com wrote:
I appreciate all of the comments; still unsure where to more persistently host the conversation, but for now I posted this still-arbitrary list on Commons https://commons.wikimedia.org/wiki/User:Sj/multimedia. (adding other items mentioned in this thread) SJ
- *File formats*: Support high-demand formats – e.g. CSV, CML <https://phabricator.wikimedia.org/T18491>, + hundreds of other <https://phabricator.wikimedia.org/T297514> open tickets - *Uploads*: Improve bulk, large, and video uploads. + *Bulk conversion* for video uploads (videoconverter / video2commons are broken) + *Upload Wizard* upgrades (timeouts <https://phabricator.wikimedia.org/T267492>, batch renaming, batch imports <https://phabricator.wikimedia.org/T281599>) - *Downloads*: Fix multi-download (Imker <https://commons.wikimedia.org/wiki/Commons:Imker_(batch_download)> is broken) + Make public dumps <https://phabricator.wikimedia.org/T298394> (stale since 2013) - *Video playback*: Debug + roll out the videojs <https://phabricator.wikimedia.org/T248418> player - *Search*: Bring CQS back up <https://phabricator.wikimedia.org/T297454>. Implement a noauth option <https://phabricator.wikimedia.org/T297995> for tools - *General*: Move to a blazegraph alternative (for wqcs) + *Images*: Update thumbor <https://phabricator.wikimedia.org/T216815> and librsvg <https://phabricator.wikimedia.org/T193352> || redesign <https://phabricator.wikimedia.org/T28741> the image table *- Curation*: Simpler content assessment workflow, like en:wp's <https://en.wikipedia.org/wiki/Wikipedia:Content_assessment> (QI/VP doesn't scale) _______________________________________________ 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/FVA4YJN5OHPRSLACPXYD4XITFG7NNKSL/ To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- Asaf Bartov asaf.bartov@gmail.com _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
On Thu, Dec 30, 2021, 10:27 AM Samuel Klein meta.sj@gmail.com 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 ladsgroup@gmail.com 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/... [2] There is a classic book in this topic called "The Mythical Man-month"
On Wed, Dec 29, 2021 at 11:41 AM Gnangarra gnangarra@gmail.com 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 -- commons-l@lists.wikimedia.org To unsubscribe send an email to commons-l-leave@lists.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 bvibber@wikimedia.org wrote:
On Thu, Dec 30, 2021, 10:27 AM Samuel Klein meta.sj@gmail.com 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 ladsgroup@gmail.com 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/... [2] There is a classic book in this topic called "The Mythical Man-month"
On Wed, Dec 29, 2021 at 11:41 AM Gnangarra gnangarra@gmail.com 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 -- commons-l@lists.wikimedia.org To unsubscribe send an email to commons-l-leave@lists.wikimedia.org
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 galder158@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 bvibber@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 bvibber@wikimedia.org wrote:
On Thu, Dec 30, 2021, 10:27 AM Samuel Klein meta.sj@gmail.com 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)%5Bdown%5D(https://phabricator.wik...), 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 ladsgroup@gmail.com 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/... [2] There is a classic book in this topic called "The Mythical Man-month"
On Wed, Dec 29, 2021 at 11:41 AM Gnangarra gnangarra@gmail.com 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 -- commons-l@lists.wikimedia.org To unsubscribe send an email to commons-l-leave@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/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
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 < galder158@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 < bvibber@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 bvibber@wikimedia.org wrote:
On Thu, Dec 30, 2021, 10:27 AM Samuel Klein meta.sj@gmail.com 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 ladsgroup@gmail.com 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/... [2] There is a classic book in this topic called "The Mythical Man-month"
On Wed, Dec 29, 2021 at 11:41 AM Gnangarra gnangarra@gmail.com 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 -- commons-l@lists.wikimedia.org To unsubscribe send an email to commons-l-leave@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/... To unsubscribe send an email to wikimedia-l-leave@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/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
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 https://protonmail.com/ Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ El dilluns, 3 de gener 2022 a les 9:44 PM, Galder Gonzalez Larrañaga < galder158@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 < bvibber@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 bvibber@wikimedia.org wrote:
On Thu, Dec 30, 2021, 10:27 AM Samuel Klein meta.sj@gmail.com 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 ladsgroup@gmail.com 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/... [2] There is a classic book in this topic called "The Mythical Man-month"
On Wed, Dec 29, 2021 at 11:41 AM Gnangarra gnangarra@gmail.com 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 -- commons-l@lists.wikimedia.org To unsubscribe send an email to commons-l-leave@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/... To unsubscribe send an email to wikimedia-l-leave@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/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
This is a proposal that would need to be included in next year's funding plan. It also would involve an obligation for the other teams within the Foundation.
**Part 1: Funding redistribution and Big Ticket team** This year, we (that is, the WMF using movement funds) spent a huge amount of money ($4.5 million) just directly donating to external knowledge equity funds.
This was done without Community review, or indeed, approval of the concept. A look through our email archives will show it was hardly a popular use of our money.
I propose that we stand-up a 2nd community wishlist team. Going off the average salaries, and the standard non-salary overhead for equivalent organisations, it should support a 16-18 person team.
This team's purpose is to handle the "Big Ticket" items, beyond the capacities of the current team. It will probably be 1-2 main items a year, with the ability to handle small(er) items from the main wishlist if they finish slightly early.
The current team could then alternate annually between Wikipedia/Wikidata/Commons items and small-project items.
**Part 2: blocked item obligations**
By far and away the two most common reasons for wishlist items being declined are "too large a project" (hopefully handled by part 1) and "in another team's scope". This aims to handle the 2nd issue with a "co-operate or takeup" mandate.
Where another team is "in the way" of a wishlist item, it should be obligated to fulfill that item itself within 24 months, or co-operate and utilise the Wishlist team's resources to fulfill it while avoiding disruption from separate workflows.
Hi Nosebagbear and all,
On Thu, Dec 30, 2021 at 11:52 AM nosebagbear@gmail.com wrote:
Going off the average salaries, and the standard non-salary overhead for equivalent organisations, it should support a 16-18 person team.
This calculation would benefit from some WMF salary data. In its 2019 Form 990[1] (the most recent one available), the WMF reported a "Salaries, other compensation, employee benefits" figure of $55,634,913 for a total of 291 employees.
This works out at an average of *$191,185.27 per employee*. (The WMF cost per employee actually increased by 38% in the space of four years.[2])
It's not cheap, especially when compared to, say, the Internet Archive, also based in San Francisco, which in its 2019 Form 990[3] reported $10,924,995 for 169 employees, an average of *$64,644.94 per employee* – about one-third the WMF figure. (The Internet Archive, which has genuinely struggled to break even in recent years, is actually crucial to Wikipedia, as it helps prevent link rot, and could really do with donations.)
For the Electronic Frontier Foundation, to give another example of a non-profit based in San Francisco, the 2019 Form 990 data yield an average of *$121,646,73 per employee*[4] – less than two-thirds the WMF figure.
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.
Andreas
[1] https://projects.propublica.org/nonprofits/organizations/200049703/202101319... [2] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_salaries#Salaries,_othe... [3] https://projects.propublica.org/nonprofits/organizations/943242767/202013219... [4] https://projects.propublica.org/nonprofits/organizations/43091431/2021213393... [5] https://foundation.wikimedia.org/w/index.php?title=File:Wikimedia_Foundation... [6] https://archive.today/rFGMv [7] https://wikimediafoundation.org/role/staff-contractors/
This team's purpose is to handle the "Big Ticket" items, beyond the
capacities of the current team. It will probably be 1-2 main items a year, with the ability to handle small(er) items from the main wishlist if they finish slightly early.
The current team could then alternate annually between Wikipedia/Wikidata/Commons items and small-project items.
**Part 2: blocked item obligations**
By far and away the two most common reasons for wishlist items being declined are "too large a project" (hopefully handled by part 1) and "in another team's scope". This aims to handle the 2nd issue with a "co-operate or takeup" mandate.
Where another team is "in the way" of a wishlist item, it should be obligated to fulfill that item itself within 24 months, or co-operate and utilise the Wishlist team's resources to fulfill it while avoiding disruption from separate workflows. _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
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... https://foundation.wikimedia.org/w/index.php?title=File:Wikimedia_Foundation_FY2020-2021_Audit_Report.pdf&page=5 [6] https://archive.today/rFGMv https://archive.today/rFGMv [7] https://wikimediafoundation.org/role/staff-contractors/ https://wikimediafoundation.org/role/staff-contractors/
Hello Andreas,
The Staff and Contractors page ( https://archive.today/rFGMv 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 https://meta.wikimedia.org/wiki/Wikimedia_Foundation_salaries .
/Antoine "hashar" Musso// //Wikimedia Release Engineering/
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 hashar@free.fr 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... [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*
Szymon: neat, thanks. How do past suggestions carry over?
We should definitely make more use of community-curated priority lists (annotated with how separable / hard they are; where they sit on the 'new solution <--> pay off tech debt' spectrum). And see if we can support a broader range of technical hubs + community groups tackling some of them.
Core challenges like Commons stability + capacity deserve their own thread! I believe the wishlist is traditionally for something else.
NBB: An interesting idea (below). It would be good for us to develop patterns w/ more shared creative leeway for experimenting with a collective call to action around major initiatives. Mozilla has some approaches to this. Including bounties, grants, outreach campaigns to recruit new contributors, awards for essential tools, workshops to train people in related toolchains so they can help move the space forward.
S.
On Thu, Dec 30, 2021 at 6:52 AM nosebagbear@gmail.com wrote:
This is a proposal that would need to be included in next year's funding plan. It also would involve an obligation for the other teams within the Foundation.
**Part 1: Funding redistribution and Big Ticket team** I propose that we stand-up a 2nd community wishlist team... to handle the "Big Ticket" items, beyond the capacities of the current team. **Part 2: blocked item obligations**
Core challenges like Commons stability + capacity deserve their own thread! I believe the wishlist is traditionally for something else.
There is nowhere else to raise these issue, especially for people like me who are photographers not a software and tech person. I know the phabricator exists and comment there occasionally but again things get close because its too hard.
Tools are great, new tools can sometimes improve other times they generate more issues.
I get it I'd rather get together with a bunch of photographers, talk gear, test gear, and look to outdo each other with the best shots. Wishlist, the Hack-a-thons serve this need for the tech community. we get to offer up some ideas on what could make things easier for us. The wish list also the one time of the year where everyone is listen to needs.
The list of issues on Commons are staggering and Commons feeds into every other project, it was created to support media uploads. As part of COT for 2021 I was also involved in uploading of all the session recordings, and I answered many questions about why was it taking so long, will captions be added all I could say was Commons wasnt letting us upload large files, Video2Commons, and VideoConverter kept falling over we couldnt get answers. We found work arounds mostly by paying for 3rd commercial software to do the conversion to webm then hoping uploadwizard would work. We even tried to find server side uploading support but despite instructions on how that isnt supported.
I see no need to create new tools when the underlying systems are failing, its clear indication that we as community have lost our way. The wishlist get what little funding the WMF is willing to spend on tech. As some who has participated in the wishlist over the years, tried to get funding to fix items like QRpedia, the thing I see is that this isnt working the tech teams arent keeping up with the core functions of projects so forget about extra toys. Every other aspect of the community has had reviews been first being paused, the whole community has been consulted, and then its been realigned to suit future needs. Its all for nothing if we dont drill down to the core of the tech that the whole thing relies upon, if that means we need to spend on extra people then the cost is justifiable because every dollar of the hundred million stashed away in future funds is worthless if the systems keeps failing or like commons appears to have reached completely collapses.
We dont need wishes, or votes to decide whats important when theres no way to contribute.
On Thu, 30 Dec 2021 at 23:50, Samuel Klein meta.sj@gmail.com wrote:
Szymon: neat, thanks. How do past suggestions carry over?
We should definitely make more use of community-curated priority lists (annotated with how separable / hard they are; where they sit on the 'new solution <--> pay off tech debt' spectrum). And see if we can support a broader range of technical hubs + community groups tackling some of them.
Core challenges like Commons stability + capacity deserve their own thread! I believe the wishlist is traditionally for something else.
NBB: An interesting idea (below). It would be good for us to develop patterns w/ more shared creative leeway for experimenting with a collective call to action around major initiatives. Mozilla has some approaches to this. Including bounties, grants, outreach campaigns to recruit new contributors, awards for essential tools, workshops to train people in related toolchains so they can help move the space forward.
S.
On Thu, Dec 30, 2021 at 6:52 AM nosebagbear@gmail.com wrote:
This is a proposal that would need to be included in next year's funding plan. It also would involve an obligation for the other teams within the Foundation.
**Part 1: Funding redistribution and Big Ticket team** I propose that we stand-up a 2nd community wishlist team... to handle the "Big Ticket" items, beyond the capacities of the current team. **Part 2: blocked item obligations**
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
On Fri, 31 Dec 2021 at 06:13, Gnangarra gnangarra@gmail.com wrote:
We found work arounds mostly by paying for 3rd commercial software to do the conversion to webm then hoping uploadwizard would work.
HandBrake can transcode dirrect to WebM these days.
thank you Geni
HandBrake can transcode dirrect to WebM these days.
On Mon, 3 Jan 2022 at 13:40, geni geniice@gmail.com wrote:
On Fri, 31 Dec 2021 at 06:13, Gnangarra gnangarra@gmail.com wrote:
We found work arounds mostly by paying for 3rd commercial software to do
the conversion to webm then hoping uploadwizard would work.
HandBrake can transcode dirrect to WebM these days.
-- geni _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
On Thu, 30 Dec 2021 at 11:52, nosebagbear@gmail.com wrote:
This year, we (that is, the WMF using movement funds) spent a huge amount of money ($4.5 million) just directly donating to external knowledge equity funds.
From https://meta.wikimedia.org/wiki/Knowledge_Equity_Fund:
Many of the barriers that prevent people from accessing and contributing to free knowledge are rooted in systems of racial oppression.
What about many of the barriers to contributing thrown up by broken or defective systems? This disproportionately affects people without the technical skills to circumvent the issues and/or implement fixes and/or gain political capital to agitate for a fix from the "system". Considering the well-documented inequalities both on racial and gender grounds in STEM subjects and computing in particular, these technical defects strike harder at the already-disadvantaged groups.
Combine this with the adversarial system of actually getting things done by having to fight, grab and compete for the scant resources thrown down, combined with the need to advocate for your issue just-so to get what you want (which again disadvantages "system-outsiders") and again this is disadvantageous to the already-disadvantaged.
Even if we just ignore race or gender, also consider that deficient technical platforms are also a brutal filter against _anyone_ without a STEM background: also people the knowledge equity stuff is supposed to help. The WMF has contrived a system that almost seems perfectly designed to filter out many of the disadvantaged or vulnerable groups they profess to want to help by failing to actually provide support for them to make their contributions in the first place. A few bright pictures and fluffy press releases and slinging money around on wishy-washy initiatives surely keeps everyone looking busy, fills some nice FTE positions and gets Twitter cachet. However, a bug's a bug and a missing feature is a missing feature.
A simple example: there's not even a "blessed" way to ask for technical help: you get ignored at COM:VPT, ignored at Mediawiki.org's dead manual pages, find out that the Discord isn't even official, bounce around several random IRC channels (once you figure out IRC in the first place, let's not pretend most people in the world have even heard of it) looking for one that can help you, eventually off to Phabricator, ignored again if your issue isn't written up '"just so" to align with the priorities of some "team" that isn't actually documented anywhere and then...you give up.
Another example closer to my home wiki: the smaller Wikisources are very disadvantaged by technical limitations which the big Wikisources work around on an ad-hoc basis using local users' skills. Many features that the big ones have would be _more_ useful for the smaller ones. A good example here is the OCR, which for years worked only at a handful of big Wikisources until CommTech integrated the OCR tool this year into the Wikisource extension. But the big wikis didn't really need the OCR as much (though they still needed it), because upstream OCR is usually better in English or French, than, say, Marathi. I had a wish to "upstream" more local features to the core extensions so all can benefit. But it's taken so long to get anything done, that I am out of time and have to go to a day-job soon, so it's not going to happen. Who has the luxury of tens or hundreds of hours spare to learn PHP from scratch to fix an issue, submit, resubmit, rebase and massage patches? Guess what: not the knowledge-equity-disadvantaged.
Perhaps instead of a firehose of money at fighting the "far enemy" of racial/social/etc. injustice, a more directed attitude of fixing the platforms and making it attractive and/or even possible for these groups to contribute in the first place is in order. Some of it's not even hard, certainly not $4,500,000-hard. It doesn't matter, in wiki terms (and those are terms that donors believe their money is to be used) how well you train a group of Jordanian journalists if when they come to upload their video, the upload fails, does it? Or PattyPan, or whatever tool has been created to address the lack of "native" tools is broken _again_.
Even if the "magic money tree" doesn't extend to more than one engineering or technical staff member, just a single FTE rotating a day per week though the projects, dedicated to helping others contribute, linking up issues with teams and driving things forward when they stall out (rather than just waiting for the would-be contributor to give up and abandon it all) would be a huge force multiplier. Allegedly, there are _already_ Developer Advocates, but whatever it is they do does not seem to actually involve advocating for the ability of would-be contributors to actually contribute.
The most frustrating thing is that this could all work well: Mediawiki is a solid piece of engineering, running on a solid operational foundation. There is CI, code review, relatively clean code, a functional issue tracker, regular deployments, RelEng/Ops teams holding it together at the coal-face, the Toolforge/WMCS (which is a completely brilliant piece of gear), a 9-figure budget (not that much of it reaches engineering, but it _could_) all of the good stuff. Really all it needs is better documentation (which needs resources allocated to those who know the domain enough to write it), proper support for outside developer so that good and useful tools don't just bit-rot to unmaintained husks, and enough slack in the system to both start to burn down the backlog and (here's the real key) allow _others_ to assist without burning out or bouncing right off the barriers to entry.
--IL
wikimedia-l@lists.wikimedia.org