I know it has been annoying a couple of people other than me, so now that I've learned how to make it work I'll share the knowledge here.
tl;dr: Star the repositories. No, seriously. (And yes, you need to star each extension repo separately.)
(Is there a place on mw.org to put this tidbit on?)
------- Forwarded message -------
From: "Brian Levine" <support(a)github.com> (GitHub Staff)
To: matma.rex(a)gmail.com
Cc:
Subject: Re: Commits in mirrored repositories not showing up on my profile
Date: Tue, 09 Jul 2013 06:47:19 +0200
Hi Bartosz
In order to link your commits to your GitHub account, you need to have some association with the repository other than authoring the commit. Usually, having push access gives you that connection. In this case, you don't have push permission, so we don't link you to the commit.
The easy solution here is for you to star the repository. If you star it - along with the other repositories that are giving you this problem - we'll see that you're connected to the repository and you'll get contribution credit for those commits.
Cheers
Brian
--
Matma Rex
We just released a new version of Research:FAQ on Meta [1], significantly
expanded and updated, to make our processes at WMF more transparent and to
meet an explicit FDC request to clarify the role and responsibilities of
individual teams involved in research across the organization.
The previous version – written from the perspective of the (now inactive)
Research:Committee, and mostly obsolete since the release of WMF's open
access policy [2] – can still be found here [3].
Comments and bold edits to the new version of the document are welcome. For
any question or concern, you can drop me a line or ping my username on-wiki.
Thanks,
Dario
[1] https://meta.wikimedia.org/wiki/Research:FAQ
[2] https://wikimediafoundation.org/wiki/Open_access_policy
[3] https://meta.wikimedia.org/w/index.php?title=Research:FAQ&oldid=15176953
*Dario Taraborelli *Head of Research, Wikimedia Foundation
wikimediafoundation.org • nitens.org • @readermeter
<http://twitter.com/readermeter>
Yesterday there was a conversation about code review on irc and among other
things, how sometimes patches can get "stuck".
I had an idea for a way to improve things. I'm not sure if it is a good
idea, but there's only one way to find out.
So without further ado, announcing the Code Review Patch Board:
https://www.mediawiki.org/wiki/Code_review/patch_board
In short - each person is allowed to list one of their patches on the board
that they would really like to see reviewed. You can only list one patch at
a time, and it should be a patch that you have been unable to get review
for for at least a week through normal means. See the page for the full
list of guidelines.
I encourage people to give it a try. Add a patch you wrote that you cannot
get a review for. Or if you have +2 rights, try giving some love to these
underloved patches.
I would also love to hear feedback on the general idea as well as the
current guidelines.
To repeat, the url is:
https://www.mediawiki.org/wiki/Code_review/patch_board
Thanks,
bawolff
Hello!
Please take our annual* *Developer Satisfaction Survey*!
Link: https://wikimediafoundation.limesurvey.net/484133
The survey is open until Fri, 17 Feb 2023—two weeks from today.
____
This survey is for members of the *Wikimedia Developer Community* and
covers the following topics:
-
Code review tooling and process
-
Code quality
-
Phabricator
-
Continuous Integration
-
MediaWiki development environments
-
Beta cluster / Staging
Please take the survey if you’ve used the above tools as part of your role
developing software for the Wikimedia community.
We’re soliciting your feedback to:
-
Measure developer satisfaction, and
-
determine where to invest resources in the future
We will anonymize, explore, and report the data we gather on mediawiki.org.
View previous years' survey results:
https://www.mediawiki.org/wiki/Developer_Satisfaction_Survey
Privacy statement: This survey will be conducted via a third-party service,
which may subject it to additional terms. For more information on privacy
and data-handling, see the survey privacy statement
<https://foundation.wikimedia.org/wiki/Legal:2023_Developer_Satisfaction_Sur…>
.
Thank you!
Tyler Cipriani (he/him)
Engineering Manager, Release Engineering
Wikimedia Foundation
____
*: “annual,” except we missed 2022 🙁
Dear Wikitechians,
On *Wednesday March 1st*, the SRE team will run a planned data center
switchover, moving all wikis from our primary data center in Virginia to
the secondary data center in Texas. This is an important periodic test of
our tools and procedures, to ensure the wikis will continue to be available
even in the event of major technical issues in our primary home. It also
gives all our SRE and ops teams a chance to do maintenance and upgrades on
systems in Virginia that normally run 24 hours a day.
The switchover process requires a *brief read-only period for all
Foundation-hosted wikis*, which will start at *14:00 UTC on Wednesday March
1st*, and will last for a few minutes while we execute the migration as
efficiently as possible. All our public and private wikis will be
continuously available for reading as usual, but no one will be able to
save edits during the process. Users will see a notification of the
upcoming maintenance, and anyone still editing will be asked to try again
in a few minutes.
CommRel has already begun notifying communities of the read-only window. A
similar event will follow a few weeks later, when we move back to Virginia.
This is currently scheduled for *Wednesday, April 26th*.
If you like, you can follow along on the day in the public
#wikimedia-operations channel on IRC (instructions for joining here
<https://meta.wikimedia.org/wiki/IRC/Instructions>). To report any issues,
you can reach us in #wikimedia-sre on IRC, or file a Phabricator ticket
with the *datacenter-switchover* tag (pre-filled form here
<https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?projects=Data…>);
we'll be monitoring closely for reports of trouble during and after the
switchover. (If you're new to Phab, there's more information at
Phabricator/Help.) The switchover and its preparation are tracked tracked
in Phabricator Task T327920 <https://phabricator.wikimedia.org/T327920>
On behalf of the SRE team, please excuse the disruption, and our thanks to
everyone in a number of departments who've been involved in planning this
work for the past weeks. Feel free to reply directly to me with any
questions.
Thank you,
--
Clément Goubert (they/them)
Senior SRE
Wikimedia Foundation
Hi All,
The Wikimedia Foundation’s Tech & Product departments have published a
first overview on current annual planning work for the fiscal year
2023/2024 (July 1st-June 30th). Comments and questions are welcome on the
talk page:
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/…
This is an almost real time “snapshot” of the work that is currently
underway to develop the Technology & Product annual plan in a
cross-departmental effort. The plan is still at the very high level and
work in progress - main areas of work (“buckets”), possible annual
objectives <https://en.wikipedia.org/wiki/OKR>, initiatives that could help
achieve these, first versions of annual key results that could roll into
these objectives. Content on the page will change as things evolve, and new
thoughts and feedback are incorporated.
If you have thoughts or questions at this early stage, please comment on
the talk page so that we can keep discussions in one place. If you prefer
to wait until things become clearer - this is perfectly fine too!
A call for feedback on the specifics of the annual plan is planned for
later in the process - this is just a start.
Thanks,
Birgit
--
Birgit Müller (she/her)
Director of Technical Engagement
Wikimedia Foundation <https://wikimediafoundation.org/>
Wikimedia Phabricator tasks have a "Priority" dropdown field (which is
not consistently used) with several discrete values, among them
"Lowest". See [1] for the full list of Priority field values.
Since [2], "Low" and "Lowest" priority share the same definition.
I propose to disable setting the "Lowest" Priority value in Phab tasks.
"Lowest priority" can sound demotivating / disrespectful ("there is
nothing that could be even less important"). However, bikeshedding
about changing the name of the value would ignore further observations:
* About half of the people who are most active in setting initial
Priority values do not ever set Priority to "Lowest"[3].
* There is no significant difference between median age of open tasks
with Low and with Lowest priority[4], thus nothing seems to get
realistically differentiated here.
* Personally I also assume Lowest priority is sometimes used instead
of honestly declining a task (means: "this is not a good idea"[5]).
But of course that is rather hard to prove.
If you have opinions and/or ideas how to interpret data differently,
please add them to https://phabricator.wikimedia.org/T228759 to keep
them in a single place - either as a text comment, or via "Award Token"
to express support or disagreement without adding words.
Thanks,
andre
[1] https://www.mediawiki.org/wiki/Phabricator/Project_management#Priority_leve…
[2] https://phabricator.wikimedia.org/T317533
[3] https://phabricator.wikimedia.org/T228759#6988320
[4] https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/…
[5] https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle
--
Andre Klapper (he/him) | Bugwrangler / Developer Advocate
https://blogs.gnome.org/aklapper/
Hey all,
This is a quick note to highlight that in six weeks' time, the REL1_40
branch will be created for MediaWiki core and each of the extensions and
skins in Wikimedia git, with some (the 'tarball') included as sub-modules
of MediaWiki itself[0]. This is the first step in the release process for
MediaWiki 1.40, which should be out in May 2023, approximately six months
after MediaWiki 1.39.
The branches will reflect the code as of the last 'alpha' branch for the
release, 1.40.0-wmf.27, which will be deployed to Wikimedia wikis in the
week beginning 13 March 2023 for MediaWiki itself and those extensions
and skins available there.
After that point, patches that land in the main development branch of
MediaWiki and its bundled extensions and skins will be slated for the
MediaWiki 1.41 release unless specifically backported[1].
If you are working on a new feature that you wish to land for the release,
you now have a few days to finish your work and land it in the development
branch; feature changes should not be backported except in an urgent case.
If your work might not be complete in time, and yet should block release
for everyone else, please file a task against the `mw-1.40-release` project
on Phabricator.[2]
If you have tickets that are already tagged for `mw-1.40-release`, please
finish them, untag them, or reach out to get them resolved in the next few
weeks.
We hope to issue the first release candidate, 1.40.0-rc.0, two weeks after
the branch point, and if all goes well, to release MediaWiki 1.40.0 a few
weeks after that.
Tyler Cipriani (he/him)
Engineering Manager, Release Engineering
Wikimedia Foundation
[0]: <https://www.mediawiki.org/wiki/Bundled_extensions_and_skins>
[1]: <https://www.mediawiki.org/wiki/Backporting_fixes>
[2]: <https://phabricator.wikimedia.org/tag/mw-1.40-release/>
TLDR: Invoking maintenance scripts directly will be deprecated in MW 1.40, use
maintenance/run.php instead. This affects anyone managing a MediaWiki
installation, for development, testing, or production use.
Until now, MediaWiki maintenance scripts have been handled standalonePHP scripts
- for instance, to run the script that outputs the MediaWiki version, you would use:
> php maintenance/version.php
Starting with MediaWiki 1.40, this is deprecated. The preferred way to run
maintenance scripts is now by name, using the maintenance runner:
> php maintenance/run.php version
Similarly, the preferred way to run the updater is now:
> php maintenance/run.php update
The script to run cal also be specified using the full path of the script file,
or the full PHP class name of a subclass of the Maintenance class. For more
details, run
> php maintenance/run.php --help
Rationale and History:
Treating maintenance scripts as standalone PHP scripts requires some boilerplate
code to be present at the top and at the bottom of every file. This is error
prone and makes it difficult to update the maintenance framework. But more
importantly,
for this boilerplate to work, the location of the MediaWiki installation has to
be known relative to the maintenance script, which is not reliably possible for
scripts defined in extensions.
A similar problem arises if the maintenance script needs a base class other than
the default Maintenance class: since the class is loaded before MediaWiki is
initialized, the autoloader is not yet in place, and the file containing the
base class needs to be included explicitly.
These and similar issues can be avoided by creating a wrapper script that loads
and executes the actual maintenance class. This way, the maintenance wrapper can
initialize MediaWiki before passing control to the script.
I propose creating such a wrapper as an RFC in 2018 (T99268)[^1], which was
approved in 2019. However, implementing the proposal proved challenging, and
soon stalled. I picked it up again as a side project after working on
overhauling the configuration and bootstrapping code in early 2022: With the
introduction of SettingsBuilder, it became much simpler to create a
MaintenanceRunner class, because it was no longer necessary to juggle global
variables.
Several bits and pieces got reviewed and merged over the course of 2022 (shout
out to Amir, Tim, Timo, and everyone who contributed). Now the runner is ready,
and we should stop calling maintenance scripts directly.
For now, existing maintenance scripts will function both ways[^2] : when called
using the runner, or directly. However, newly created maintenance scripts should
not be required to be callable as standalone scripts. So it's best to change all
callers to use the wrapper.
This should now work for nearly all[^2] cases, though there are still a couple
of rough edges to be smoothed out. If you are running MediaWiki 1.40, please try
the new mechanism, and report any isses on Phabricator.
Thanks,
Daniel
[^1] https://phabricator.wikimedia.org/T99268
[^2] with the exception over very old-school scripts that do not use the
Maintenance base class and rely on CommandLineInc.php instead.
--
Daniel Kinzler
Principal Software Engineer, Platform Engineering
Wikimedia Foundation