The tool that keeps track of the remaining work to do enforces a naming on the tasks.

@Debenben You should be able to push now. I think I remember Striker made this automatically IIRC, yes. Not sure why it does not now.

It looks like the invoke of the main.css file from Common.css is broken. We can add it from REL1_30: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/skins/MonoBook/+/REL1_30/main.css

@Mainframe98 Fixing at https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/UserExport/+/440397/2..3/UserExport.body.php I think.

Fix.

Thanks @mmodell - I understand that future requests like this for maintainers can be approved. Regards.

Thanks! I'll try to get those fixed once the patches I upload for ExtReg and PHPCS are merged :-)

Seems so. I've found that uid=ccogdill is attached via ldapsearch to User:Ccogdill on Wikitech and with an @wikimedia.org address attached to it as well.

@CCogdill_WMF I'm assuming that your shell username is ccogdill for the account CCogdill (WMF). Is that right?

@bd808 Sounds like attachLdapUser.php is required?

Hi. Where do you want said link? Footer of http://paws.wmflabs.org/paws/hub/login maybe? Thanks.

@cooltey Perfect. Less work :) Thanks for +2. Hope that it works.

Patches you create directly on the Gerrit UI are marked WIP as default, and only the owner of the patch can unmark it as WIP by clicking on the 'Start Review' button. I am not aware if Admins can do this but, as Addshore, I am a Gerrit Manager and I can only see that button for the patches I own (as expected afaik).

I have removed the title from app/src/main/java/org/wikipedia/settings/SettingsPreferenceLoader.java but as you can see the string is translated to several languages. Do you want those removed too?

It's missing on .gitmodules for REL1_31. Fixing.

Okay then. I can grant you such permissions, but let me please ask @Aklapper and @mmodell just in case. Thanks.

In T186445#4274228, @Jrbranaa wrote:

At this juncture the Language-Team will move forward as the Code Stewards for this extension. Runa and I have briefly discussed and will be working to get this extension the support/funding for more active maintenance. In the meantime non-UBN issues that need support will be reviewed on a case-by-case basis. @MarcoAurelio of the open changesets, are there any in particular that are of higher priority?

In T163060#4282071, @Samwilson wrote:

Just awaiting the OAuth consumer approval: https://meta.wikimedia.org/wiki/Special:OAuthListConsumers/view/bbf18209c7e5538761c312f9619bdf84

Given that you're the author/maintainer of the tool I think we can grant you push access to the Diffusion repository. Depending on the method you wish to push changes to the repo you'll need to create an HTTPS password or upload your SSH key to https://phabricator.wikimedia.org/settings/user/maskaravivek/

Aha, that explains. Thanks.

I am not wure what to do with:

Thanks for the clarification :)

That's "I'd approve a 'enter your password and get 30 minutes without having to enter it again' feature" somewhat so I think I'm fine with that.

My opinion about this is similar to what I wrote in T197150#4280429. Please note that often CheckUser queries are performed in a row (ie: CheckUser gets IPs of User:Vandal; CheckUser checks the IPs to investigate further). A simple checkuser request can take from one to dozens of queries. If we're forced to re-enter our password each and every time we perform a CU query that'll slow our job big time. On the other hand CheckUser queries are --obviously-- not publicly logged so spotting abuse of the feature is not that trivial unless someone is watching the logs. I'd approve a 'enter your password and get 30 minutes without having to enter it again' feature, but if possible I'd avoid having to enter my password for each and every CU query. Regards.

As someone who often changes user permissions locally and globally, requiring users to re-authenticate every time we need to change a permission would be overkill, at least from the perspective of the work we stewards do, and will lead to people using simple or easy passwords if they have to do this several times per day as it's our case (ie: something similar was argued not to force the users to change their passwords each Y days). Not that I'd use a weak password intentionally and put in danger the safety of our projects, nor my fellow stewards would do that of course; but it'd be quite annoying. Can we think of a different safety method? Please also note that changing userrights is always logged on Special:Log/rights so in principle weird changes of permissions can be quickly and easily spotted and reverted.

Adding @hashar to do the pending GitHub mirror deletions.

I would like to thank @Legoktm for his kind nomination, which I humbly accept hoping that I can be useful. In addition to what he's said, I have also contributed patches to many mediawiki/extensions/* (same link added in the description) and I'm also a Gerrit Manager there which let me handle some stuff such as repository and group creations. Thank you.

Perfect. Regards.

Yep @Prtksxna Whatever you commit/merge on Gerrit will be mirrored on Diffusion and GitHub, so you only have to work on Gerrit :)

Per above.

Yep, resetting the preferences has worked @Paladox. Thanks.

Testing that.

See also T196840: Massive increase of writes in m3 section.

With the upgrade of Gerrit to v2.15 millions of commits from the type refs/.*/.*/meta are being copied to the Phabricator database. A hotfix was applied yesterday to ignore further refs/.*/.*/meta commits, but those that were in the queue from before are still being processed. According to @mmodell the queue was, as of yesterday, about 8 million of commits still pending to be processed. @Paladox can explain further I think.

I see there are no CI tests for that repo. You should setup some I think. Added Continuous-Integration-Config.

Repository should now be observing changes from https://gerrit.wikimedia.org/oojs/router now. Until you commit and merge something there I won't know if it is fully working as expected though.