I haven't seen too much discussion about this, but i just wanted to remind
everyone that people who participate in mediawiki development (including
many third party extensions) are eligible to vote in the current Wikimedia
foundation board of trustees election, even if you don't edit any wikimedia
wiki. You just have to have made one commit. Commits to third party
mediawiki extensions not used by Wikimedia wikis count (including some
hosted at github). The Wikimedia Foundation is the largest contributor to
MediaWiki core, and the trustees control the direction of the Wikimedia
Foundation. Hence your vote (indirectly) determines the direction of
MediaWiki software!
There is an unofficial list of eligible developers at
https://i-want-to-vote.toolforge.org . I encourage anyone who participates
in development of software in the mediawiki ecosystem to check if they are
on the list. Even if you are not on that list you may still be eligible.
You can learn more about the candidates at
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_elections/2022/Candida…
. In particular, many of you might already know legoktm who is one of the
candidates and is very active in the mediawiki developer community. You can
vote now up until september 6 (however some eligible people must register
to vote before sept 2). The link to vote is
https://meta.wikimedia.org/wiki/Special:SecurePoll/vote/393 . People who
are eligible to vote due to software development must pre-register via
email before that link works for them and they must do so 4 days before the
end of the election. See https://i-want-to-vote.toolforge.org for details.
The full official list of eligibility criteria is at
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_elections/2022/Voter_e…
. The key point for software developers, is you only have had to make 1
commit between Jan 5 and july 5, to any gerrit repo, any toolforge tool
repo (including those outside gerrit), or any mediawiki extension/skin on
MWStake's list of mediawiki extensions/skins developed outside of gerrit.
If the above doesn't describe you, there are also other criteria that can
make you eligible, like if you have made lots of edits to
https://mediawiki.org or https://translatewiki.net, maintain or contribute
to "tools, bots, user scripts, gadgets, and Lua modules on Wikimedia
wikis", or "substantially engaged in the design and/or review processes of
technical development related to Wikimedia." or are employed by the
Wikimedia foundation or an affiliate of Wikimedia. Check the official rules
for the full list.
Anyways i encourage everyone to vote who is eligible. People who are voting
by virtue of being a software developer MUST register 4 days before the end
of the election (i.e. sept 2), so if that's you, be sure to do it in time.
See the official rules or https://i-want-to-vote.toolforge.org for details.
--
Bawolff
p.s. Just to clarify, this isn't an official email, i just wanted to ensure
that the wider mediawiki developer community was aware of this as i suspect
many eligible developers may be unaware they are allowed to vote.
Hello,
We have a proposal to make small adjustments to the MediaWiki database
policy which would make abstract schema an explicit requirement.
Abstract schema was approved by TechCom in
https://phabricator.wikimedia.org/T191231 and now core and all WMF-deployed
extensions have migrated to abstract schema.
You can find the proposal in here. Please take a look and comment:
https://www.mediawiki.org/wiki/Talk:MediaWiki_database_policy
If there are no major objections by the end of August 2022, I will codify
this into the policy.
Best
--
*Amir Sarabadani (he/him)*
Staff Database Architect
Wikimedia Foundation <https://wikimediafoundation.org/>
Dear Wikimania Hackathon Attendees,
It was a pleasure spending the weekend hacking with you! I hope you had as
much fun as I did playing with WikiData games, learning about clever ways
to improve medical data on wikis, exploring Wikimedia Cloud Services, and
engaging with all the other cool projects and sessions.
If you missed the final showcase, it was recorded! You can watch it on
YouTube. <https://www.youtube.com/watch?v=xZ2tKvv3Hfc>
The playlist of recorded sessions is also available. <
https://www.youtube.com/playlist?list=PL3soxkz-0_y6xOBqgWuZXv4ZrGJTghXIA>
There’s also information about all the projects on the Wikimania wiki. If
you didn’t get the chance to present, you can still add your project there.
<https://wikimania.wikimedia.org/wiki/Hackathon/Showcase>
Finally, please consider giving feedback on the event! If you have ideas,
things you liked, or things you’d like to see changed, this is your chance
to share that so we can improve in the future. <
https://etherpad.wikimedia.org/p/2022WikimaniaHackathon-FB>
My best regards,
Haley and the Developer Advocacy Team
--
*Haley Lepp*
Technical Community Program Manager
Wikimedia Foundation <https://wikimediafoundation.org/>
Dan and Sage,
Thank you very much for your kind words and well wishes! It means a lot to
me to hear that. :)
Best regards,
Josephine
On Fri, 26 Aug 2022 at 22:04, <wikitech-l-request(a)lists.wikimedia.org>
wrote:
> Message: 2
> Date: Thu, 25 Aug 2022 08:34:02 -0700
> From: Sage Ross <ragesoss+wikipedia(a)gmail.com>
> Subject: [Wikitech-l] Re: Commons app - v4.0 and my resignation
> To: Wikitech-l <wikitech-l(a)lists.wikimedia.org>
> Message-ID:
> <CA+QewsP2ypRG2ff7Poxg2pw7_ck8g=
> F7ku0ZB2YgK1jJ_i_fFw(a)mail.gmail.com>
> Content-Type: multipart/alternative;
> boundary="000000000000a64aa005e7128719"
>
> Josephine,
>
> Thanks so much for all the work you've done on the Commons app. I'm really
> grateful that you've maintained it so well; it's one of my favorite apps,
> and there's nothing else out there that comes close to doing what it does.
>
> Good luck with your career change!
>
> You are awesome!
>
> -Sage
>
>
> On Thu, Aug 25, 2022, 8:01 AM Dan Andreescu <dandreescu(a)wikimedia.org>
> wrote:
>
> > Thanks so much for your leadership and work Josephine, it's been awesome
> > to watch over the years. Good luck on your next adventures!
> >
> > On Thu, Aug 25, 2022 at 2:17 AM Josephine Lim <josephinelim86(a)gmail.com>
> > wrote:
> >
> >> Hi all,
> >>
> >> Hope you have been well! We have just released v4.0 of the Commons
> >> Android app to production on Google Play - this version includes tons of
> >> new features (a map displaying nearby Commons pictures, custom SPARQL
> >> queries, user profiles, and a custom picture selector), as well as fixes
> >> for major bugs such as the "date uploaded" bug. The app can be
> downloaded
> >> from the Play Store[1] or directly from our GitHub repository[2].
> >>
> >> I should probably also add that this will likely be my last release - I
> >> am currently transitioning to a new career, and will be stepping down
> from
> >> the role of project lead, which I have held for the past 6 years. I
> intend
> >> to stick around on a volunteer basis, but the amount of time that I can
> put
> >> into the app from now on will be much more limited. I have discussed
> this
> >> with the app's community, and I believe that a new grant team might be
> >> emerging, and one of the volunteers might step up to take on the project
> >> lead role.
> >>
> >> Thank you very much for the support that you have all shown to the
> >> Commons app over the years. It was an honor and a pleasure to work with
> all
> >> of you - I have learned so much and met so many amazing people in the
> >> Wikimedia community, and I certainly hope to continue being part of it.
> I
> >> also hope that the app and the community surrounding it may have
> benefited
> >> from my work here, and that the new team will be able to bring it to
> places
> >> that I might not have ever foreseen.
> >>
> >> Best regards,
> >> Josephine (User: Misaochan)
> >>
> >> [1] https://play.google.com/store/apps/details?id=fr.free.nrw.commons
> >> [2] https://github.com/commons-app/apps-android-commons/releases
> >>
> >>
>
Hi,
Tomorrow at the HOPE 2022 conference, I'm giving a talk titled, "How to
Run a Top-10 Website, Publicly and Transparently", discussing the impact
of transparency in Wikimedia's technical spaces. A number of people have
expressed interest in watching, including non-technical users, so I'm
advertising it a bit more broadly.
I apologize for the short notice, I didn't realize the stream would be
free to watch until yesterday (thanks Ori!).
Time: 2022-07-23 17:00 UTC (1pm ET) -
https://zonestamp.toolforge.org/1658595637
Stream: https://hope.net/416dac.html
If you can't watch it live, a recording will be uploaded later on.
I've documented all of this on-wiki, including the full abstract:
<https://meta.wikimedia.org/wiki/User:Legoktm/HOPE_2022>.
I am of course happy to answer any questions people might have after the
talk!
Thanks,
-- Kunal / Legoktm
Hi all,
Hope you have been well! We have just released v4.0 of the Commons Android
app to production on Google Play - this version includes tons of new
features (a map displaying nearby Commons pictures, custom SPARQL queries,
user profiles, and a custom picture selector), as well as fixes for major
bugs such as the "date uploaded" bug. The app can be downloaded from the
Play Store[1] or directly from our GitHub repository[2].
I should probably also add that this will likely be my last release - I am
currently transitioning to a new career, and will be stepping down from the
role of project lead, which I have held for the past 6 years. I intend to
stick around on a volunteer basis, but the amount of time that I can put
into the app from now on will be much more limited. I have discussed this
with the app's community, and I believe that a new grant team might be
emerging, and one of the volunteers might step up to take on the project
lead role.
Thank you very much for the support that you have all shown to the Commons
app over the years. It was an honor and a pleasure to work with all of you
- I have learned so much and met so many amazing people in the Wikimedia
community, and I certainly hope to continue being part of it. I also hope
that the app and the community surrounding it may have benefited from my
work here, and that the new team will be able to bring it to places that I
might not have ever foreseen.
Best regards,
Josephine (User: Misaochan)
[1] https://play.google.com/store/apps/details?id=fr.free.nrw.commons
[2] https://github.com/commons-app/apps-android-commons/releases
Hello everyone!
We have just added a new organisation located in Russia(Moscow) to mirror
the last 4 good dumps and the wikidata entity dump. You could find the
updated list of all our current mirror sites in
https://meta.wikimedia.org/wiki/Mirroring_Wikimedia_project_XML_dumps#Dumps
-- Hannah Okwelum
Hi,
please tell me, what is the thought behind the impossibility, that a normal
admin can delete pages with more than 5000 revisions.
Thank you
Martin aka Doc Taxon ...
Hello,
After many years of work, I'm happy to announce a milestone in addressing
one of our major areas of tech debt in database infrastructure: we have
eliminated all schema drifts between MediaWiki core and production.
It all started six years ago when users in English Wikipedia reported that
checking history of some pages is quite slow *at random*. More in-depth
analysis showed the revision table in English Wikipedia was missing an
important index in some of the replicas. An audit of the schema of the
revision table revealed much bigger drifts in the revision table of that
Wiki. You can read more in its ticket: T132416
<https://phabricator.wikimedia.org/T132416>
Lack of schema parity between expectation and reality is quite dangerous.
Trying to force an index in code assuming it would exist in production
(under the same name) would cause fatal error every time it’s attempted.
Trying to write to a field that doesn’t exist is similar. Such changes
easily pass tests and work well in our test setups (such as beta cluster)
just to cause an outage in production.
If only one table in one Wiki had this many drifts, looking at all Wikis
and all tables became of vital importance. We have around ~1,000 wikis,
~200 hosts (each one hosting on average ~100 Wikis), and each Wiki has
around ~130 tables (half of them being tables from MediaWiki core) and each
table can have multiple drifts.
We slowly started looking for and addressing schema drifts five years ago
and later automated the discovery by utilizing abstract schema (before
that, the tool had to parse SQL) and discovered an overwhelming number of
drifts. You can look at the history of the work in T104459
<https://phabricator.wikimedia.org/T104459>.
Around fifty tickets addressing the drifts have been completed and they are
collected in T312538 <https://phabricator.wikimedia.org/T312538>. I suggest
checking some of them to see the scale of the work done. Each one of these
tickets took days to months of work to finish. Large number of them also
existed in primary databases, requiring a primary switchover and read-only
time for one or more Wikis. Each drift was different, in some cases, you
needed to change the code and not production so it needed a thorough
investigation.
Why do such drifts happen? The most common reason was when a schema change
happened in code but it was never requested to be applied in production.
For example, a schema change in code in 2007 led to having any wiki created
before that date to have a different schema than wikis created after it. We
introduced processes
<https://wikitech.wikimedia.org/wiki/Schema_changes#Workflow_of_a_schema_cha…>
and tooling to make sure this doesn’t happen anymore in 2015 but we still
needed to address previous drifts. The second common reason was when a host
didn’t get the schema change for various reasons (was out of rotation when
the schema was being applied, a shortcoming of the manual process). By
automating <https://wikitech.wikimedia.org/wiki/Auto_schema> most of the
schema change operational work we reduced the chance of such drifts from
happening as well.
After finishing core, we now need to look at WMF-deployed extensions,
starting with FlaggedRevs <https://phabricator.wikimedia.org/T313253> that,
while being deployed to only 50 wikis and having only 8 tables, has ~7,000
drifts. Thankfully, most other extensions are in a healthier state.
I would like to personally thank Manuel Arostegui and Jaime Crespo for
their monumental dedication to fix these issues in the past years. Also a
big thank you to several of our amazing developers, Umherirrender, James
Forrester and Sam Reed who helped on reporting, going through the history
of MediaWiki to figure out why these drifts happened, and helping build the
reporting tools.
Best
--
*Amir Sarabadani (he/him)*
Staff Database Architect
Wikimedia Foundation <https://wikimediafoundation.org/>