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>
Hi,
On Tue, Mar 1, 2016 at 3:36 PM, David Strine <dstrine(a)wikimedia.org> wrote:
> We will be holding this brownbag in 25 minutes. The Bluejeans link has
> changed:
>
> https://bluejeans.com/396234560
I'm not familiar with bluejeans and maybe have missed a transition
because I wasn't paying enough attention. is this some kind of
experiment? have all meetings transitioned to this service?
anyway, my immediate question at the moment is how do you join without
sharing your microphone and camera?
am I correct thinking that this is an entirely proprietary stack
that's neither gratis nor libre and has no on-premise (not cloud)
hosting option? are we paying for this?
-Jeremy
As of 950cf6016c, the mediawiki/core repo was updated to use DB_REPLICA
instead of DB_SLAVE, with the old constant left as an alias. This is part
of a string of commits that cleaned up the mixed use of "replica" and
"slave" by sticking to the former. Extensions have not been mass
converted. Please use the new constant in any new code.
The word "replica" is a bit more indicative of a broader range of DB
setups*, is used by a range of large companies**, and is more neutral in
connotations.
Drupal and Django made similar updates (even replacing the word "master"):
* https://www.drupal.org/node/2275877
* https://github.com/django/django/pull/2692/files &
https://github.com/django/django/commit/beec05686ccc3bee8461f9a5a02c607a023…
I don't plan on doing anything to DB_MASTER, since it seems fine by itself,
like "master copy", "master tape" or "master key". This is analogous to a
master RDBMs database. Even multi-master RDBMs systems tend to have a
stronger consistency than classic RDBMs slave servers, and present
themselves as one logical "master" or "authoritative" copy. Even in it's
personified form, a "master" database can readily be thought of as
analogous to "controller", "governer", "ruler", lead "officer", or such.**
* clusters using two-phase commit, galera using certification-based
replication, multi-master circular replication, ect...
**
https://en.wikipedia.org/wiki/Master/slave_(technology)#Appropriateness_of_…
***
http://www.merriam-webster.com/dictionary/master?utm_campaign=sd&utm_medium…
--
-Aaron
Hello,
The DockerSIG[0] meeting for this month is cancelled due to the agenda
being empty. Future DockerSIG meetings are still planned.
Please do email myself or reach out in other ways if you have something
you'd like to add to the agenda for our next session; even if it's a
request and not something you'd lead.
Best,
Greg
[0] https://www.mediawiki.org/wiki/Docker/SIG
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| Release Team Manager A18D 1138 8E47 FAC8 1C7D |
Hello all,
It's been a little while since our last review cycle, but we're
starting one now. The discussion period for these items will be open
until August 23rd 2019, at which point we'll look to make a decision
regarding the item's future. Please note that the Code Stewardship
review process is intended to help address un/under funded code that
is deployed to the Wikimedia production environment.
In order to simplify discussions, we've decided to move all
discussions to the relevant Phabricator tasks.
For more information about the process, please see the Code
Stewardship Review page[1].
This cycle's Code Stewardship reviews are:
- SpamBlacklist extension [2]
- Collection Extension [3]
- OAuth Extension [4]
- Nuke Extension [5]
- ShortURL Extension [6]
Cheers,
Jean-René Branaa (aka JR)
WMF - Release Engineering/Code Health
[1] https://www.mediawiki.org/wiki/Code_stewardship_reviews
[2] https://phabricator.wikimedia.org/T224921
[3] https://phabricator.wikimedia.org/T224922
[4] https://phabricator.wikimedia.org/T224919
[5] https://phabricator.wikimedia.org/T221155
[6] https://phabricator.wikimedia.org/T187045
The 1.34.0-wmf.16 version of MediaWiki is blocked[0], after a brief
period of being unblocked. Thanks to Jdlrobson and everyone else who
worked on unblocking the earlier issues.
1.34.0-wmf.16 cannot proceed to group1[1] until these issues are resolved:
* PHP Warning:
Wikibase\Lib\Store\Sql\WikiPageEntityRevisionLookup::getEntityRevision:
Entity not loaded - https://phabricator.wikimedia.org/T229482
Once these issues are resolved, the train can resume. If these issues
are resolved on a Friday the train will resume Monday.
Thank you for your help resolving these issues!
-- Your unassuming train minion
[0]. <https://phabricator.wikimedia.org/T220741>
[1]. <https://tools.wmflabs.org/versions/>
The 1.34.0-wmf.16 version of MediaWiki is blocked[0].
The new version can't proceed to group1[1] until these issues are resolved:
* Disable grouped results on RecentChanges page on mobile -
https://phabricator.wikimedia.org/T228280
* Inform AMC users that grouped results are not available on the recent
changes page - https://phabricator.wikimedia.org/T228516
Once these issues are resolved, the train can resume. If these issues
are resolved on a Friday the train will resume Monday.
Thank you for your help resolving these issues!
-- Your unassuming train minion
[0]. <https://phabricator.wikimedia.org/T220741>
[1]. <https://tools.wmflabs.org/versions/>
📘 Read on Phabricator at
https://phabricator.wikimedia.org/phame/live/1/post/163/
-------
How’d we do in our strive for operational excellence last month? Read on to
find out!
## 📊 Month in numbers
* ⚠️11 documented incidents. [1]
* 39 new Wikimedia-prod-error reports. [2]
* 25 Wikimedia-prod-error reports closed. [3]
The number of incidents in June was high compared to previous years. At 11
incidents, this is higher than this year’s median (5), the 2018 median (4),
and the 2017 median (5). It is also higher than any month of June in the
last 4 years. – More data at <https://codepen.io/Krinkle/full/wbYMZK>.
To read more about these incidents, their investigations, and pending
actionables; check <
https://wikitech.wikimedia.org/wiki/Incident_documentation#2019>.
There are currently 204 open Wikimedia-prod-error reports (up from 186 in
April, and 201 in May). [4]
-------
## *️⃣ [Op-ed] Integrated maintenance cost
Hereby a shoutout to the Wikidata and Core Platform teams, at WMDE and WMF
respectively. They both recently established a rotating subteam that
focuses on incidental work. Such as maintenance, and other work that might
otherwise hinder feature development.
I expect this to improve efficiency by avoiding context switches between
feature and incidental work. The rotational aspect should distribute the
work more evenly among team members (avoiding burnout). And, it may
increase exposure to other teams, and lesser-known areas of our code; which
provide opportunities for personal growth and to retain institutional
knowledge.
-------
## 📉 Current problems
Take a look at the workboard and look for tasks that might need your help.
The workboard lists known issues, grouped by the month in which they were
first observed.
→ https://phabricator.wikimedia.org/tag/wikimedia-production-error/
Breakdown of recent months (past two weeks not included):
* November: 1 issue got fixed! (1 issue left).
* December: 3 issues left (unchanged). ⚠️
* January: 1 issue left (unchanged). ⚠️
* February: 2 issues left (unchanged). ⚠️
* March: 4 issues left (unchanged). ⚠️
* April: 2 issues got fixed! (10 of 14 issues, that survived April, remain
open).
* May: 4 issues got fixed! (6 of 10 issues, that survived May, are left).
* June: 11 new issues from last month remain unresolved.
By steward and software component, the unresolved issues that survived June:
* CPT / MW Auth (PHP fatal): https://phabricator.wikimedia.org/T228717
* CPT / MW Actor (DB contention): https://phabricator.wikimedia.org/T227739
* CPT or Multimedia / Thumb handler (MultiCurl error):
https://phabricator.wikimedia.org/T225197
* Multimedia / File metadata (PHP error):
https://phabricator.wikimedia.org/T226751
* Wikidata / Commons page view (PHP fatal):
https://phabricator.wikimedia.org/T227360
* Wikidata / Jobrunner (PHP memory fatal):
https://phabricator.wikimedia.org/T227450
* Wikidata / Jobrunner (Trx error):
https://phabricator.wikimedia.org/T225098
* Product-Infra / ReadingList API (PHP fatal):
https://phabricator.wikimedia.org/T226593
* (Unknown?) / Special:ConfirmEmail (PHP fatal):
https://phabricator.wikimedia.org/T226337
* (Unknown?) / Page renaming (DB timeout):
https://phabricator.wikimedia.org/T226898
* (Unknown?) / Page renaming (Bad revision fatal):
https://phabricator.wikimedia.org/T225366
-------
## 🎉 Thanks!
Thank you to everyone who has helped by reporting, investigating, or
resolving problems in Wikimedia production. Including: Brad Jorsch, Brion
Vibber, Roan Kattouw, CScott, Daniel Kinzler, David Causse, DerFussi,
Ebe123, Filippo Giunchedi, James Forrester, Kosta Harlan, Legoktm, Lucas
Werkmeister, Bartosz Dziewoński, Matthias Mullie, Michael Große, Niklas
Laxström, Stephane Bisson, Stas Malyshev, Tchanders, Gergő Tisza, Tpt,
Umherirrender, and Urbanecm.
Thanks!
Until next time,
– Timo Tijhof
🔮 “These are his marbles...” “Ha! He really did lose his marbles, didn't
he?” “Yeah, he lost them good.”
-------------------------------------------------
Footnotes:
[1] Incidents. –
https://wikitech.wikimedia.org/wiki/Special:PrefixIndex?prefix=Incident+doc…
[2] Tasks created. –
https://phabricator.wikimedia.org/maniphest/query/barA9u0RtzE3/#R
[3] Tasks closed. –
https://phabricator.wikimedia.org/maniphest/query/zXZdtEhocO1a/#R
[4] Open tasks. –
https://phabricator.wikimedia.org/maniphest/query/47MGY8BUDvRD/#R