Hello,
We will upgrade our Gerrit to [version 3.3]. We have scheduled it on
Tuesday, August 3rd at 16:00 UTC. We will first upgrade the [Gerrit
replica] then the primary server. The service will thus be unavailable for
a few minutes while we conduct the operation and restart the service.
The July 19th upgrade took a bit longer than expected since we were trying
our runbook for the first time. We have since improved our documentation
and addressed a few configuration glitches we had.
This upgrade comes with a new feature: "Attention Set". It replaces change
*assignees* with a list of people that are expected to act on the change.
It helps better differentiate changes you have already reviewed from the
one you have to review or amend. The feature is nicely explained on
upstream documentation page:
http://gerrit-documentation.storage.googleapis.com/Documentation/3.3.1/user…
Ahmon, Antoine, Brennen
Release Engineering
[version 3.3] https://www.gerritcodereview.com/3.3.html
[Gerrit replica]
https://wikitech.wikimedia.org/wiki/Gerrit-replica.wikimedia.org
Upgrade task: https://phabricator.wikimedia.org/T262241
Hello all,
We invite you all to sign up for Toolhub's Quality Signal sessions!
Toolhub <https://meta.wikimedia.org/wiki/Toolhub> [1] is a
community-authored catalog of Wikimedia tools. On Toolhub, you will be able
to discover new tools in the Wikimedia ecosystem, promote their use in your
wiki community, and help improve them by contributing data. Toolhub's first
release is planned around Wikimania 2021.
The Toolhub team is currently working on identifying quality indicators
through conversations with tool users and developers. As a tool user, how
do you know which tool is reliable, useful, and safe to use? As a tool
maintainer, what makes it attractive to you to contribute to an existing
tool? What information are you looking for to decide whether to join a tool
project? We hope that these sessions will help gather quality indicators
for tools and provide valuable insight toward developing new features to
convey the quality.
Want to organize a quality signal session in your community in August/early
September? Please get in touch on the talk page or sign-up for an already
planned session by adding your name below it: <
https://meta.wikimedia.org/wiki/Toolhub/The_Quality_Signal_Sessions> [2].
Your feedback, thoughts, ideas would be valuable!
If you are attending Wikimania, we are running a few introductions and a
feedback session as part of the unconference. Learn more here: <
https://wikimania.wikimedia.org/wiki/2021:Unconference/Toolhub> [3].
Cheers,
Srishti
On behalf of the Toolhub team
[1] https://meta.wikimedia.org/wiki/Toolhub
[2] https://meta.wikimedia.org/wiki/Toolhub/The_Quality_Signal_Sessions
[3] https://wikimania.wikimedia.org/wiki/2021:Unconference/Toolhub
*Srishti Sethi*
Senior Developer Advocate
Wikimedia Foundation <https://wikimediafoundation.org/>
Hello all,
This email is a reminder to start proposing projects and sessions for this
year’s Wikimania hackathon, taking place on August 13th (the first day of
Wikimania). You may have already seen the announcement email last week with
all the details.
This year’s hackathon will take place in a 24 hrs format covering all time
zones. You can start proposing a session or a project by following the
guidelines here: <
https://wikimania.wikimedia.org/wiki/2021:Hackathon#Propose_a_project_or_a_…>
[1].
We also encourage folks to reuse the video of a previously recorded session
(in lecture format) to organize a watch party-style session. And, you can
pause during or after for questions and discussions. That way, you have to
do less prep, and one can watch your session at any time during the event.
There isn't a specific focus area proposed this time, so your session or
project needn't fit under a theme. Anything that involves MediaWiki
development or covers a technical area in the Wikimedia ecosystem. Plus, we
welcome sessions that would be helpful to newcomers–new to the event, our
technical spaces, or projects.
If you have any questions, feel free to use the related talk page to
contact the organizing team or join the community conversation on Telegram:
<https://t.me/wikimaniachat> [2].
We look forward to your participation!
Cheers,
Srishti
On behalf of the Wikimania Hackathon organizing team
[1]
https://wikimania.wikimedia.org/wiki/2021:Hackathon#Propose_a_project_or_a_…
[2] https://t.me/wikimaniachat
*Srishti Sethi*
Senior Developer Advocate
Wikimedia Foundation <https://wikimediafoundation.org/>
The Search Platform Team
<https://www.mediawiki.org/wiki/Wikimedia_Search_Platform> usually holds
office hours the first Wednesday of each month. Come talk to us about
anything related to Wikimedia search, Wikidata Query Service, Wikimedia
Commons Query Service, etc.!
Feel free to add your items to the Etherpad Agenda for the next meeting.
Details for our next meeting:
Date: Wednesday, August 4th, 2021
Time: 15:00-16:00 GMT / 08:00-09:00 PDT / 11:00-12:00 EDT / 17:00-18:00 CEST
Etherpad: https://etherpad.wikimedia.org/p/Search_Platform_Office_Hours
Google Meet link: https://meet.google.com/vgj-bbeb-uyi
Join by phone: https://tel.meet/vgj-bbeb-uyi?pin=8118110806927
*NOTE: We have a new Google Meet link as of August 2021, which offers
international calling options.*
Trey Jones
Sr. Computational Linguist, Search Platform
Wikimedia Foundation
UTC–4 / EDT
I have a script for writing to the Wikidata API that respects the rate limit of 50 edits per minute for bots without a bot flag. However, when that script was used by somebody else, she received the error "As an anti-abuse measure, you are limited from performing this action too many times in a short space of time, and you have exceeded this limit.\nPlease try again in a few minutes". I think it is because she is a "newbie" who is subjected to a slower rate (i.e. as in https://www.mediawiki.org/wiki/Manual:$wgRateLimits).
Questions:
1. Is there a newbie rate limit that is slower than the rate for "normal" registered users?
2. If so, what is that limit?
3. How many edits must a newbie user make before they are no longer considered a "newbie" (or is number of edits not the criterion for being considered a newbie)?
Thanks!
Steve Baskauf
--
Steven J. Baskauf, Ph.D. he/him/his
Data Science and Data Curation Specialist / Librarian III
Jean & Alexander Heard Libraries, Vanderbilt University
Nashville, TN 37235, USA
Office: Eskind Biomedical Library, EMB 111
Phone: (615) 343-4582
https://my.vanderbilt.edu/baskauf/
This email is a summary of the Wikimedia production deployment of
1.37.0-wmf.16.
Mukunda Modell was the train conductor last week. Antoine Musso (hashar)
was the backup conductor.
Blocker task: https://phabricator.wikimedia.org/T281157
The new version is live on all sites: https://versions.toolforge.org/
== 📊 Stats ==
* 365 patches ↑
* 1 risky patch ↑
* 1 rollback (for ~2hours) ↑
* 0 days of delay ↓
* 2 blockers added, 0 resolved, 2 removed — same as last week
** OPEN: https://phabricator.wikimedia.org/T287704 by @mmodell
** RESOLVED: https://phabricator.wikimedia.org/T286490 by @dancy
== 🚂🌈 ==
A couple of tasks were mentioned but not added as blockers:
* OPEN: https://phabricator.wikimedia.org/T287642 by @brennen
* RESOLVED: https://phabricator.wikimedia.org/T287649 by @IKhitron
* RESOLVED: https://phabricator.wikimedia.org/T191021 by @Trizek-WMF
Thank you to everyone who filed tasks, triaged bugs, talked publicly, added
risky patch notifications, and braved yet another production deployment. To
quote Winnie the Pooh: "You are braver than you believe, stronger than you
seem, and smarter than you think"
Much thanks goes to:
* Addshore
* alexhollender
* daniel
* DannyS712
* Etonkovidova
* IKhitron
* Jdlrobson
* Krinkle
* Ladsgroup
* Legoktm
* Majavah
* ovasileva
* Pchelolo
* Zabe
– The Trainbow Bunch
Hi all,
With excitement we're sharing today that Vue.js is Wikimedia
Foundation's official choice for adoption as future JavaScript
framework for use with MediaWiki.
The evaluation of front-end frameworks officially started mid 2019, as
part of the Platform Evolution program’s goal to evolve our technology
platform and development processes to empower the Wikimedia
Movement[0].
The corresponding Technical RFC was successfully resolved in March
2020[1]. As this framework selection is a wide-ranging, long-term
decision, a dedicated group, the Front-end Architecture Working
Group[2], was established to drive the technology comparison and the
final recommendation. Besides the resolved RFC the outcome was to
build and test developer experience in a pilot project[3].
The selected pilot was within the Desktop Improvements project[4] with
its new Vue.js-based TypeaheadSearch feature that allows for providing
additional context while searching. Since its introduction in March
2021[5] the new TypeaheadSearch component has been the default across
15 wikis of varying sizes and has received positive user feedback[6].
A final developer satisfaction survey was completed to gain further
information on the developer experience. The survey results emphasized
“a positive light on the future of working with Vue.js”. And “[t]he
engineers felt optimistic about the future and confident in
recommending it for adoption across all our teams.”
The pilot gave us confidence in the recommendation to adopt Vue.js and
we are moving into further implementation of Vue.js tooling and
product migration planning.
To support further efforts, the Wikimedia Foundation has established
the Wikimedia Design System team[7], which I'm proudly part of. Our
continued work and upcoming priorities include:
- Preparing a shared Vue.js user-interface components library
- Deciding on Vue 2 or Vue 3 including transition path
- Figuring out how the components library will be built and
distributed in and beyond MediaWiki
You can find more of the ongoing work on Phabricator[8].
For full transparency, we've carried that knowledge with us for some
time already, but were prioritizing progressing integration, annual
planning and our internal All-hands conference to finally arrive at
this announcement today.
I'd like to thank a number of folks involved in leading to this, all
Front-end Architecture Working Group members, especially colleagues
Eric Gardner & Roan Kattouw for driving the RFC, the Readers Web team
for undergoing as pilot implementers and especially our former
colleague Stephen Niedzielski who was central to making it a success,
Wikimedia Deutschland for numerous insights through their Vue.js
experience, current Design System team members responsible for further
progress, all Movement volunteers involved in both providing feedback
to the pilot and contributing to development and Product & Tech
department leadership for their strong support of this wide-reaching
change.
Best regards,
Volker
References
[0] https://www.mediawiki.org/wiki/Platform_Evolution/Recommendations#1._Develo…
[1] https://phabricator.wikimedia.org/T241180
[2] https://www.mediawiki.org/wiki/Frontend_Architecture_Working_Group
[3] https://www.mediawiki.org/w/index.php?title=File:FAWG_Demo.pdf&page=26
[4] https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements
[5] https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Updates#Mar…
[6] https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements#List_of_ear…
[7] https://www.mediawiki.org/wiki/Design_Systems_Team
[8] https://phabricator.wikimedia.org/T286946
---
Volker Eckl
Design Lead
Wikimedia Design System
Wikimedia Foundation
1 Montgomery Street
Suite 1600
San Francisco, CA 94104
For performance sensitive tight loops, such as parsing and HTML
construction, to get the best performance it's necessary to think
about what PHP is doing on an opcode by opcode basis.
Certain flow control patterns cannot be implemented efficiently in PHP
without using "goto". The current example in Gerrit 708880
<https://gerrit.wikimedia.org/r/c/mediawiki/core/+/708880/5/includes/Html.ph…>
comes down to:
if ( $x == 1 ) {
action1();
} else {
action_not_1();
}
if ( $x == 2 ) {
action2();
} else {
action_not_2();
}
If $x==1 is true, we know that the $x==2 comparison is unnecessary and
is a waste of a couple of VM operations.
It's not feasible to just duplicate the actions, they are not as
simple as portrayed here and splitting them out to a separate function
would incur a function call overhead exceeding the proposed benefit.
I am proposing
if ( $x == 1 ) {
action1();
goto not_2; // avoid unnecessary comparison $x == 2
} else {
action_not_1();
}
if ( $x == 2 ) {
action2();
} else {
not_2:
action_not_2();
}
I'm familiar with the cultivated distaste for goto. Some people are
just parotting the textbook or their preferred authority, and others
are scarred by experience with other languages such as old BASIC
dialects. But I don't think either rationale really holds up to scrutiny.
I think goto is often easier to read than workarounds for the lack of
goto. For example, maybe you could do the current example with break:
do {
do {
if ( $x === 1 ) {
action1();
break;
} else {
action_not_1();
}
if ( $x === 2 ) {
action2();
break 2;
}
} while ( false );
action_not_2();
} while ( false );
But I don't think that's an improvement for readability.
You can certainly use goto in a way that makes things unreadable, but
that goes for a lot of things.
I am requesting that goto be considered acceptable for micro-optimisation.
When performance is not a concern, abstractions can be introduced
which restructure the code so that it flows in a more conventional
way. I understand that you might do a double-take when you see "goto"
in a function. Unfamiliarity slows down comprehension. That's why I'm
suggesting that it only be used when there is a performance justification.
-- Tim Starling
Hi Community Metrics team,
This is your automatic monthly Phabricator statistics mail.
Accounts created in (2021-07): 257
Active Maniphest users (any activity) in (2021-07): 988
Task authors in (2021-07): 495
Users who have closed tasks in (2021-07): 265
Projects which had at least one task moved from one column to another on
their workboard in (2021-07): 296
Tasks created in (2021-07): 1911
Tasks closed in (2021-07): 1731
Open and stalled tasks in total: 47797
* Only open tasks in total: 46883
* Only stalled tasks in total: 914
Median age in days of open tasks by priority:
Unbreak now: 45
Needs Triage: 678
High: 940
Normal: 1467
Low: 2085
Lowest: 2145
(How long tasks have been open, not how long they have had that priority)
Active Differential users (any activity) in (2021-07): 5
To see the names of the most active task authors:
* Go to https://wikimedia.biterg.io/
* Choose "Phabricator > Overview" from the top bar
* Adjust the time frame in the upper right corner to your needs
* See the author names in the "Submitters" panel
TODO: Numbers which refer to closed tasks might not be correct, as
described in https://phabricator.wikimedia.org/T1003 .
Yours sincerely,
Fab Rick Aytor
(via community_metrics.sh on phab1001 at Sun 01 Aug 2021 12:00:19 AM UTC)