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
> 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(a)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(a)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(a)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
Hello all,
I would like to announce the release of MediaWiki Language Extension
Bundle 2022.01. This bundle is compatible with '''MediaWiki 1.36''' or
above and requires '''PHP 7.3.19''' or above.
Next MLEB is expected to be released in 3 months. If there are very
important bug fixes, we will do an intermediate release. Please give
us your feedback at
[[Talk:MLEB|https://www.mediawiki.org/wiki/Talk:MLEB]].
* Download: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2022.01.tar…
* sha256sum: 0cb434980b399f7bac42a92c9f171b6c9041cb998e3b2b0fcf16daf58c43fe61
* Signature: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2022.01.tar…
Quick links:
* Installation instructions are at: https://www.mediawiki.org/wiki/MLEB
* Announcements of new releases will be posted to a mailing list:
https://lists.wikimedia.org/postorius/lists/mediawiki-i18n.lists.wikimedia.…
* Report bugs to: https://phabricator.wikimedia.org/project/view/1464/
Release notes for each extension are below.
-- Kartik Mistry
== Highlights ==
* '''MLEB now requires MediaWiki 1.36 and PHP 7.3.19'''
== Babel, cldr, CleanChanges and LocalisationUpdate ==
* Localisation and maintenance updates.
== Translate ==
* Fix Special:PageMigration - Page search suggestion does not work
({{phab|T217726}})
* Fix UI issue: the page moves from bottom to top when new messages
are loaded in List tab ({{phab|T295655}}, {{gerrit|738587}})
* Migrate tables to an abstract schema ({{phab|T268576}}, {{gerrit|735613}})
* Improve UX on Special:AggregateGroups and add collapsibility ({{phab|T90511}})
* Feature: Special:Translate: Make the target language visible in the
translation UI ({{phab|T296987}}, {{gerrit|743383}})
* Feature: Special:Translate: Make the target language selector a bit
more prominent ({{phab|T296986}}, {{gerrit|743397}})
* Performance: Special:ActiveLanguages should not perform slow queries
if results are cached ({{phab|T285314}}, {{gerrit|747122}})
* Feature: Add a new Javascript hook,
<code>mw.translate.translationView.stateChange</code>, fired when the
state is updated ({{phab|T297129}}, {{gerrit|745997}})
* Remove unused Configure extension integration ({{gerrit|751382}})
* Feature: Add reason dropdown on PageTranslationDeletePage
({{phab|T153542}}, {{gerrit|754490}})
* Add filters to <code>meta=messagegroupstats</code> API
({{phab|T298736}}, {{gerrit|752000}})
* Allow exporting AggregateMessageGroups in offline format via CLI
({{phab|T299493}}, {{phab|T263268}}, {{gerrit|755356}})
=== Breaking changes ===
* Remove backward compatibility for MW <= 1.35 ({{phab|T298788}},
{{gerrit|752166}})
== UniversalLanguageSelector ==
* Remove backward compatibility for MW <= 1.35
* Localisation and maintenance updates.
=== Font updates ===
* Add Awami Nastaliq font ({{phab|T290510}}, {{gerrit|737206}})
* Update OpenDyslexic ({{gerrit|737207}})
* Update GentiumPlus font ({{phab|T298613}}, {{gerrit|737206}})
--
Kartik Mistry | કાર્તિક મિસ્ત્રી
kartikm.wordpress.com
This is just a note to inform and/or remind you that the WMF has its own
internal cloud solution, Wikimedia Cloud VPS[0]. If you are considering
starting up a project on AWS, Google Cloud, or the like, please consider
using our internal, already-paid-for service.
We provide:
- Easy virtual machine creation and management[1]
- Persistent block storage[2]
- Self-serve provisioning of Mariadb and PostgreSQL database servers[3]
(and self-serve management of Mariadb user access)
- Automatic HTTPS/TLS termination for web endpoints[4]
- Other things!
Start experimenting today with a project request here:
https://phabricator.wikimedia.org/project/view/2875/
Q. Isn't WMCS only for community/volunteer projects?
A. Nope. Dozens of internal WMF projects are already hosted on Cloud
VPS. The advantage of using a community-focused platform is that when
the time comes to involve volunteers, contractors, or WMDE staff in your
work, you will find the path to access simple and straightforward.
Q. Is WMCS a safe place for my data and passwords?
A. Yes. If you want to store user PII on a Cloud VPS system then there
will need to be some official discussion, but that is true for any PII
hosted on any cloud platform.
Q. What is this going to cost me or my department?
A. WMCS provides free, unmetered resources to all projects related to
the WMF's mission and the Wikimedia community. If you have extremely
large resource needs (dozens of cores or terabytes of data) then there
may be some discussion about long-term cloud capacity but we don't have
a billing department and don't plan on ever having one.
Q. What kind of software can I host on Cloud VPS?
A. Any software with an OSI-approved license can be freely installed.
Q. I really need <specific feature that I know is available on AWS>. Do
you support that?
A. Maybe! Or even if we don't, we might be about to. Feel free to
respond to this ticket, or contact a member of the WMCS team via email,
slack, or IRC.
Q. Why would I use Cloud VPS when I already know how to use AWS?
A. There are so many reasons! Some of them are financial, ideological,
and legal, but the biggest reason is that we are here to help you. WMCS
staff and volunteers provide ongoing support for Cloud VPS via
phabricator and IRC, and we care about whether or not your project succeeds.
Thank you for reading!
[0] https://wikitech.wikimedia.org/wiki/Portal:Cloud_VPS
[1] https://wikitech.wikimedia.org/wiki/Help:Horizon_FAQ
[2] https://wikitech.wikimedia.org/wiki/Cinder
[3]
https://wikitech.wikimedia.org/wiki/Help:Adding_a_Database_to_a_Cloud_VPS_P…
[4]
https://wikitech.wikimedia.org/wiki/Help:Using_a_web_proxy_to_reach_Cloud_V…
🚂🌈Summary of 1.38.0-wmf.18 train deployment
This email is a summary of the Wikimedia production deployment of
1.38.0-wmf.18
- Conductor: Jeena Huneidi
- Backup Conductor: Mukunda Modell
- Blocker Task: T293959 <https://phabricator.wikimedia.org/T293959>
- Current Status <https://versions.toolforge.org>
🔢 According to our calculations
Sparklines comparing with the last 5 trains.
- 287 Patches ▆▇▁██
- 0 Rollbacks ▂▄▁█▁
- 0 Days of delay ▁▂▂█▁
- 13 Blockers ▄▃▁▃█
😻 Trainbow Love 🎉 Thanks to folks who reported or resolved blockers:
- Kosta Harlan
- Brennen Bearnes
- Tyler Cipriani
- Peter Pelberg
- Taavi Väänänen
- Umherirrender
- Zabe
- James D. Forrester
- Samuel
- Bartosz Dziewoński
- Jon Robson
- Gergő Tisza
--
Jeena Huneidi
Software Engineer, Release Engineering
Wikimedia Foundation
Hi,
excited to share that we've released OOUI v0.43.0 last Thursday.
It will rollout on the normal train tomorrow, Tuesday, 18 January 2022.
Highlights in this release since v0.42.0:
- MessageWidget features now a `showClose` option for the optional
closing notices et al.
- MenuSelectWidget highlights the first selectable option instead of the
visible one. Thanks to volunteer Func.
- Numerous icon additions and improvements are featured:
-- The only nominal breaking change is removal of the `destructive`
variant from 'close' icon. The 'close' icon shouldn't be used for removing
or deleting things for user-experience consistency, please revisit your
codebase and use 'trash' icon instead.
-- 'stopHand' icon was deprecated and renamed to 'hand' icon while being
aligned to the Design Style Guide's icon guidelines[0].
-- 'watchlist' icon was added. Thanks to Alex Hollender.
-- Large number of 'bold' and 'italic' icons for specific languages
were aligned to the guidelines. Thanks to new Design Systems team
peer, Bárbara Martínez Calvo.
I'm specifically excited about these changes as they emphasize our goal
to provide first-class experience for our diverse language communities.
With updated OOUI demos[1] and demos of future Vue.js-based[2] UI
toolkit Codex, you're now able to see and compare all per language
icons. Thanks to Roan Kattouw and Ed Sanders.
- Last, but not least, more than 20 different performance optimizations
across widgets were included in this release, thanks to Thiemo Kreuz
at current work focus by Wikimedia Deutschland.
One call for notice here, widgets don't feature default implicit
`aria-disabled="false"` any more to save bytes sent to client,
only when set dynamically.
There was one case of a template breakage written to check for
this –now missing attribute. Please carefully test if this might affect
your
code.–
You can find details on additional new features, code-level, styling
and interaction design amendments, and all improvements since v0.42.0
in the full changelog[4].
If you have any further queries or need help dealing with deprecating
changes, please let me know.
As always, interactive demos and library documentation is available
on mediawiki.org[5], there is comprehensive generated code-level
documentation and interactive demos and tutorials hosted on
doc.wikimedia.org[6].
OOUI version: 0.43.0
MediaWiki version: 1.38.0-wmf.18[7]
Date of deployment to production: Regular train, starting Tuesday 18 January
[0] - https://design.wikimedia.org/style-guide/visual-style_icons.html
[1] -
https://doc.wikimedia.org/oojs-ui/master/demos/?page=icons&theme=wikimediau…
[2] - https://www.mediawiki.org/wiki/Vue.js
[3] - https://gerrit.wikimedia.org/g/oojs/ui/+/v0.43.0/History.md
[4] - https://www.mediawiki.org/wiki/OOUI
[5] - https://doc.wikimedia.org/oojs-ui/master/
[6] - https://wikitech.wikimedia.org/wiki/Deployments#Tuesday,_January_18
Best,
Volker