Hi Everyone,
It's time for Wikimedia Tech Talks 2019 Episode 5!
This month's talk will take place *June 25, 2019 at 6:00 PM UTC****.*
*Topic*: Just what is Analytics doing back there?
*Speaker*: Dan Andreescu, Senior Software Engineer, Analytics
*Summary*: We take care of twelve systems. Data flows through them to
answer the many questions that our community and staff have about
our piece of the open knowledge movement. Let's take a look at how
these systems fit together and dive deeper into some of the more
interesting algorithms.
*YouTube stream for viewers*: https://www.youtube.com/watch?v=GD0PEDFysfM
During the live talk, you are invited to join the discussion on IRC
at #wikimedia-office
You can watch past Tech Talks here:
https://www.mediawiki.org/wiki/Tech_talks
If you are interested in giving your own tech talk, you can learn more
here:
https://www.mediawiki.org/wiki/Project:Calendar/How_to_schedule_an_event#Te…
Subbu.
(Standing in for Sarah Rodlund who is currently away)
In the Release Engineering team we're preparing for a new CI system.
The current one needs to be replaced. It works well, but parts of it
are getting obsolete. In particular, the Zuul version we use is
obsoleted by upstream. The new version of Zuul is entirely different.
Because of this, we are taking the opportunity to re-think the whole
approach to CI. We would like to introduce the possibility of
continuous delivery and deployment, in addition to continuous
intergration.
Earlier this year, we started a working group to evaluate candidates
for software. In phase 1, we set up some criteria for evaluation, and
considered a large number of possibilities, and winnowed the list down
to three candidates: GitLab CI, Zuul v3, and Argo. For details and a
report, see [0].
We are currently writing up what the new CI system should look like in
more detail. The approach taken is to start with what's needed and
wanted, rather than what the tools provide. The document has had a
first round of internal review, to get rid of the worst issues, and v2
is now open for feedback from the whole movement. You can find it at
[1]. Those with a WMF Google account can comment directly on the doc,
everyone else please use email, either by responding to this email via
wikitech-l or directly to me.
[0] https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/CI_Future…
[1] https://docs.google.com/document/d/1EQuInEV-eY_5kxOZ8E1qEdLr8fb6ihwOD9V_tpV…
The status of wmf.10 as of now:
* Group 1 wikis are on wmf.10 [1]
* There is one open blocker: T226448 [2]
Assuming the remaining blocker is fixed, then we will deploy wmf.10 to all
wikis tomorrow afternoon coincident with cutting the branch for wmf.11.
Tomorrow, Jeena is in charge of the train and I will be assisting. This is
Jeena's first week as train conductor and I'm not sure whether to offer
congratulations or condolences.
1. https://tools.wmflabs.org/versions/
2. https://phabricator.wikimedia.org/T226448
Sorry for cross-posting!
Reminder: Technical Advice IRC meeting this week **Wednesday 3-4 pm UTC**
on #wikimedia-tech.
Questions can be asked in English, Romanian and German!
The Technical Advice IRC Meeting (TAIM) is a weekly support event for
volunteer developers. Every Wednesday, two full-time developers are
available to help you with all your questions about Mediawiki, gadgets,
tools and more! This can be anything from "how to get started" over "who
would be the best contact for X" to specific questions on your project.
If you know already what you would like to discuss or ask, please add your
topic to the next meeting:
https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting
Hope to see you there!
--
Raz Shuty
Engineering Manager
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30 219 158 26-0
https://wikimedia.de
Imagine a world, in which every single human being can freely share in the
sum of all knowledge. That‘s our commitment.
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
Hello,
Could somebody please help me understand the configuration of the
Wikimedia Job Runner service?
https://github.com/wikimedia/mediawiki-services-jobrunner/blob/master/jobru…
I'm not quite clear on how groups work, it would seem that the
groups/runners parameter is the number of threads assigned to each
group..? But then why does the "gwt" group have runners=0?
Thanks,
Aran
Hi,
The Wikimedia technical spaces Code of Conduct is enforced by a committee.
That committee's selection process is defined as follows:
"The first Committee will be chosen by the Wikimedia Foundation’s Technical
Collaboration team. Subsequent members and auxiliary members of the
Committee will be chosen by the current regular members through a majority
vote." [1]
About a month ago, the CoC Committee put up a slate of "candidates", and
was soliciting feedback on them. The decision on these candidates was
supposed to happen on June 12, last week. I don't know if it actually
happened - I didn't see an announcement, and the candidates page is still
up. [2] In any case, I doubt any of these candidates will have trouble
getting through, since these candidates are also, for the most part, the
people deciding who gets in.
That's what I'm writing about: I now think that the committee should be
decided via open elections, instead of having the committee appoint itself.
At the moment, this group has a complete lack of accountability: they could
make any decision whatsoever at any time, and, according to the rules,
there is literally no one who can stop them. With every passing year and
additional "renewal" (that's what it's called), [3] it seems to me that
their legitimacy as representing the views of the overall community
decreases.
I had a strange personal experience that made me start to think about this.
Pretty soon after they requested feedback a month ago, I sent en email to
the CoC Committee giving my negative view about one member of the
committee, and explaining why I thought they shouldn't remain there. The
committee responded a few weeks later by saying they were rejecting my
feedback - which is their right - but then spent the rest of the email
criticizing my own previous behavior. Which I found bizarre. Thinking about
it later, it seems to only make sense as what's known in American business
as "circling the wagons" - a group of people responding to outside
criticism in a defensive way, by rejecting all of it, attacking the
critics, etc. Which is not the kind of thing you want to see from people
who are supposed to be making rational, unbiased decisions.
Now, it could be that I'm making too much of this one interaction - maybe
some people there were just having a bad day - but there's still the larger
question of whether elections make sense, and to some extent it's a
question that's independent of whatever you think of the people currently
on the committee.
As for the mechanics of voting: one option is to give one vote to anyone
who has a Wikimedia developer account. The vote could be held on
wikitech.wikimedia.org, or perhaps there's an even better technical
solution. The key thing for now is just to get a sense for people's views
on this.
So, what do people think - is there any kind of significant support for the
idea of elections for the CoC Committee?
-Yaron
[1] https://www.mediawiki.org/wiki/Code_of_Conduct/Committee
[2]
https://www.mediawiki.org/wiki/Code_of_Conduct/Committee/Members/Candidates
[3]
https://www.mediawiki.org/wiki/Code_of_Conduct/Committee#Creation_and_renew…
On Wednesday the 19th, production wikis were rolled back from 1.34.0-wmf.10
to 1.34.0-wmf.8 due to a critical issue: "T226109 Jobs not being executed
on 1.34.0-wmf.10" [1]
It's now Thursday afternoon in the U.S. and we still do not have a fix, nor
is there an indication that a fix is imminent. It's not clear which patch
caused the issue so that leaves us with no choice but to cancel the train
for this week and try again next week. If there are critical fixes that
need to be deployed, I can help with that for the remainder of today; there
are of course no deployments on Friday.
[1] https://phabricator.wikimedia.org/T226109
Hello,
*TL;DR*
As part of our work on partial blocks, the Anti-Harassment Tools team has
been refactoring MediaWiki’s code related to blocking, including the Block
class. While “Block” still exists as an alias, extension developers and
anyone who works on code related to blocks should examine their code and
adjust accordingly. Please read further for more information.
*The reason*
With the introduction of partial blocks, and as a follow up to the previous
email we shared with this list several months ago, several cleanup efforts
were scheduled. One of our major tasks involved making sure that
restrictions of overlapping blocks are merged on enforcement[0]. To add
this type of functionality to the large block class in a way that would be
maintainable and extendable going forward, we found it necessary to do some
refactoring.
*Introducing a BlockManager service*
The first piece of cleanup work was the creation and addition of a
BlockManager class[1][2], which is responsible for managing the blocks that
apply to a user, considering that multiple blocks may impact the same user
- e.g. if the user is in a blocked (or partially blocked) IP range as well
as having a separate block (or partial block) on their user account or IP
address.
This work has so far involved moving several methods from the User and
(formerly) Block classes into the BlockManager. The User class uses the
BlockManager to get the correct state of a specific block and its
restrictions.
*Refactoring Block into AbstractBlock, SystemBlock, and DatabaseBlock (and
adding MultipleBlock)*
In order for block restrictions and enforcement to be properly evaluated
even in cases where there may be multiple blocks that apply, the blocks
were split into three main types[3]:
* DatabaseBlock: These blocks are stored in the database. Most blocks are
DatabaseBlocks; most extensions that deal with blocks only deal with
DatabaseBlocks. Blocks obtained using `DatabaseBlock::newFrom*` (formerly
`Block::newFrom*`) are DatabaseBlocks.
* SystemBlock: These blocks are temporary, and created by the system on
enforcement (e.g. blocks against blacklisted IP addresses).
* CompositeBlocks: These are blocks that were created from multiple other
blocks[0]. Like SystemBlocks, these are created temporarily on enforcement,
and not saved.
All three classes inherit the new base class “AbstractBlock”.
“Block” is now an alias for the DatabaseBlock class, and should be
considered deprecated.
*Followup: How to update your code*
The team has followed up with code in production to correct type hinting
and the uses we’ve encountered that require changes.“Block” is still an
alias of the new DatabaseBlock class, so there is no urgency in changing
existing code dealing with DatabaseBlocks (and most blocks are
DatabaseBlocks), but code maintainers and extension developers should
correct the uses of any blocking behavior as necessary, and as fits their
products.
Here are general tips for approaching any changes you may want to make to
adhere to the new block features:
* Any use of static Block methods such as Block::newFrom* should be changed
to use DatabaseBlock
* Any use of the Block constructor should be changed to the SystemBlock or
DatabaseBlock constructor. If the block has the `$systemBlockType`
property, then it should be a SystemBlock. If it is saved to or loaded from
the database, it should be a DatabaseBlock. (In the vast majority of cases,
it will be DatabaseBlock.)
* Any typehint for Block that could be expecting more than one type of
block should be changed to AbstractBlock - e.g. a block returned from
methods that call User::getBlockedStatus could be any type of block. If
expecting a DatabaseBlock, then Block will work for now, but should be
updated to DatabaseBlock
As always, if you find any bugs, please submit a ticket and tag it against
“Anti-Harassment” tag and “MediaWiki-User-management” tag.
Thank you,
The Anti Harassment Tools Team
*References*
[0] Restrictions of overlapping blocks should be merged on enforcement
https://phabricator.wikimedia.org/T206163
[1] Introduce a BlockManager service for getting and combining the blocks
that apply to a user/IP https://phabricator.wikimedia.org/T219441
[2] Clean up code related to blocking
https://phabricator.wikimedia.org/T225011
[3] Refactor Block to AbstractBlock, DatabaseBlock and SystemBlock
https://phabricator.wikimedia.org/T222737
--
Moriel Schottlender (she/her)
Senior Software Engineer
Tech Lead | Community Tech and Anti Harassment Tools
Wikimedia Foundation https://wikimediafoundation.org/
Hello,
This is an announcement about a new installment of the Language Showcase, a
series of presentations about various aspects of language diversity and its
connection to Wikimedia Projects.
This new installment will deal with Machine Translation and how we are
seeing their use in Wikimedia projects.
This session is going to be broadcast over YouTube, and a recording will be
kept for later viewing. You can also participate in the conversation on IRC
or with us on the hangout. However, please do let us know earlier so that
we can send you a hangout invite.
Please read below for the event details, including local time, YouTube
links and do let us know if you have any questions.
Thank you!
Amir
== Details ==
# Event: Language Showcase #2
# When: June 26, 2019 (Wednesday) at 13:00 UTC (check local time
https://www.timeanddate.com/worldclock/fixedtime.html?iso=20190626T1300)
# Where:
https://www.youtube.com/watch?v=uG3eU1tohok
IRC - #wikimedia-office (on Freenode)
# Agenda:
The usage of Machine Translation in Wikimedia projects.
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
Hello,
The committee has finished selecting new members and the new committee
candidates are (In alphabetical order):
- Amir Sarabadani
- Lucie-Aimée Kaffee
- MusikAnimal
- Tonina Zhelyazkova
- Tony Thomas
And auxiliary members will be (In alphabetical order):
- Huji
- Matanya
- Nuria Ruiz
- Rosalie Perside
- Tpt
You can read more about the members in [0]
The changes are:
* Nuria and Rosalie are moving from main member to auxilary members
* MusikAnimal is moving from auxilary member to main
* Tonina Zhelyazkova is joining the main members
This is not the final structure. According to the CoC [1], the current
committee publishes the new members and call for public feedback for *six
weeks* and after that, the current committtee might apply changes to the
structure based on public feedback.
Please let the committee know if you have any concern regarding the members
and its structure until *19 June 2019* and after that, the new committee
will be in effect and will serve for a year.
[0]:
https://www.mediawiki.org/wiki/Code_of_Conduct/Committee/Members/Candidates
[1]:
https://www.mediawiki.org/wiki/Code_of_Conduct/Committee#Selection_of_new_m…
Amir, On behalf of the Code of Conduct committee
Best