I'm super-excited to see forward progress on this. :D

Are there any non-technical (e.g., policy) issues that need to be figured out before this extension can be deployed to Wikimedia wikis?

Have we firmly decided on using Meta-Wiki (metawiki) as the central wiki?

Will preëxisting User:Foo/global.js and User:Foo/global.css pages on Meta-Wiki automatically work once this extension is deployed? (Have we firmly decided that /global.xxx is the naming convention that we'll use?)

Are there any known hard requirements to deploying this extension?

I don't believe the "GlobalCssJs" MediaWiki extension currently provides [[m:MediaWiki:Global.css]] and [[m:MediaWiki:Global.js]], but perhaps it could one day?

(In reply to comment #1)

I'm super-excited to see forward progress on this. :D

Are there any non-technical (e.g., policy) issues that need to be figured out
before this extension can be deployed to Wikimedia wikis?

Not that I can think of really. This gives meta administrators (and anyone else with 'editinterface' on meta) the ability to easily run javascript on a user's account on every single wiki, however meta admins have historically had much greater access than normal sysops (global spam/title blacklists, etc). I don't personally see it as an issue, but I'll drop a note on meta just in case.

Have we firmly decided on using Meta-Wiki (metawiki) as the central wiki?

The only other wiki that could be used is loginwiki, except nearly all users there don't even have the 'edit' right, making it useless. I don't think creating a new wiki for this makes sense either.

Will preëxisting User:Foo/global.js and User:Foo/global.css pages on
Meta-Wiki
automatically work once this extension is deployed? (Have we firmly decided
that /global.xxx is the naming convention that we'll use?)

Yes. That said, if users currently are importing their global.js in the old style (creating a common.js on every wiki loading global.js), their JS will be double-loaded, which might cause issues.

Are there any known hard requirements to deploying this extension?

Code wise...or? bug 57225 (use ResourceLoader) is an absolute must.

I don't believe the "GlobalCssJs" MediaWiki extension currently provides
[[m:MediaWiki:Global.css]] and [[m:MediaWiki:Global.js]], but perhaps it
could
one day?

The original extension did, I neglected to re-add it into the ResourceLoader version. Will do that shortly.

(In reply to comment #2)

Are there any non-technical (e.g., policy) issues that need to be figured out
before this extension can be deployed to Wikimedia wikis?

Not that I can think of really. This gives meta administrators (and anyone
else
with 'editinterface' on meta) the ability to easily run javascript on a
user's
account on every single wiki, however meta admins have historically had much
greater access than normal sysops (global spam/title blacklists, etc). I
don't
personally see it as an issue, but I'll drop a note on meta just in case.

https://meta.wikimedia.org/w/index.php?title=Wikimedia_Forum&oldid=6588613#Global_JS_and_CSS

I don't believe the "GlobalCssJs" MediaWiki extension currently provides
[[m:MediaWiki:Global.css]] and [[m:MediaWiki:Global.js]], but perhaps it
could
one day?

The original extension did, I neglected to re-add it into the ResourceLoader
version. Will do that shortly.

Added in the latest version of the ResourceLoader patchset.

Related:
https://www.mediawiki.org/wiki/RL2 (work from Roan and Trevor that addresses at least part of the "global css/js" issue).

So, it sounds like some kind of joint clarification of plan among everyone is in order before we progress. I hate to use the 3 letter word, but... RFC?

(In reply to comment #4)

Related:
https://www.mediawiki.org/wiki/RL2 (work from Roan and Trevor that addresses
at
least part of the "global css/js" issue).

Does it? Can you link the specific section? I don't see anything about this, only about global gadgets while this is about global *personal* JS/CSS.

Or in other words, I suppose this could just be controlled by a configuration setting disabled by default if that's your worry:

(In reply to comment #2)

I don't believe the "GlobalCssJs" MediaWiki extension currently provides
[[m:MediaWiki:Global.css]] and [[m:MediaWiki:Global.js]], but perhaps it
could
one day?

The original extension did, I neglected to re-add it into the ResourceLoader
version. Will do that shortly.

(In reply to comment #4)

Related:
https://www.mediawiki.org/wiki/RL2 (work from Roan and Trevor that addresses
at
least part of the "global css/js" issue).

The GlobalCssJs extension is primarily for custom user-js/css, not for widespread gadgets that a majority of users will enable (though until Gadgets 2.0 is deployed, people will probably enable stuff like popups or global-twinkle through it). This feature is intended for a pretty narrow set of users, mainly those that are active cross-wiki like the [[m:SWMT]].

Ah, the name may have scared me a little then. I thought the scope was a bit bigger.

I think it still might be worthwhile to talk with Roan/Dan G/Timo about this, though (Roan and Timo being the ones who wrote that RL2 page, and Timo being the one who said "well, <what's on RL2> is basically a bunch of steps towards the global gadget solution" (paraphrased)).

Sent an email to wikitech: http://lists.wikimedia.org/pipermail/wikitech-l/2013-December/073643.html

What's the goal for this bug? End of February?

(In reply to MZMcBride from comment #10)

What's the goal for this bug? End of February?

I believe the only hard blocker now is bug 58438 (security review). Depending on Chris S.'s (or someone else's...) availability to do a security review, this extension deployment may get pushed until the end of March 2014. We'll see.

Nemo, Guillaume, Lego, et al.: thoughts on what's needed in terms of communicating this change and giving users time to prepare? As I see it, it's really just a matter of coordinating with the Meta-Wiki community.

Can someone confirm whether this extension also creates MediaWiki:Common.js and MediaWiki:Common.css pages that are global and affect all users on all wikis?

(In reply to Dan Garry from comment #12)

Can someone confirm whether this extension also creates MediaWiki:Common.js
and MediaWiki:Common.css pages that are global and affect all users on all
wikis?

This extension creates "MediaWiki:Global.js" and "MediaWiki:Global.css", yes. Changes to these pages will affect all users on all public Wikimedia wikis. You can read more at https://gerrit.wikimedia.org/r/94837. Why do you ask?

(In reply to MZMcBride from comment #11)

Nemo, Guillaume, Lego, et al.: thoughts on what's needed in terms of
communicating this change and giving users time to prepare? As I see it,
it's really just a matter of coordinating with the Meta-Wiki community.

We need some kind of tool to delete existing common.js pages that users have created with Pathoschild/Hoo/Tanvir's scripts to load global.js manually.

(In reply to Dan Garry from comment #12)

Can someone confirm whether this extension also creates MediaWiki:Common.js
and MediaWiki:Common.css pages that are global and affect all users on all
wikis?

It currently creates a MediaWiki:Global.js/css on the central wiki (Meta), which would affect users on all wikis where the extension is installed (all CentralAuth wikis minus loginwiki).

Krinkle has said (https://gerrit.wikimedia.org/r/#/c/94837/11/GlobalCssJs.hooks.php,cm) that we should add a configuration option to control this feature, which I agree with. He also said that it should probably be disabled on WMF wikis, which I disagree with. ;)

(In reply to Kunal Mehta (Legoktm) from comment #14)

We need some kind of tool to delete existing common.js pages that users have
created with Pathoschild/Hoo/Tanvir's scripts to load global.js manually.

As far as I'm concerned, users who have done this to their own accounts are on their own. I don't believe there's any reasonable obligation to fix this for these users, though we can certainly provide forewarning.

Krinkle has said
(https://gerrit.wikimedia.org/r/#/c/94837/11/GlobalCssJs.hooks.php,cm)
that we should add a configuration option to control this feature, which I
agree with. He also said that it should probably be disabled on WMF wikis,
which I disagree with. ;)

I disagree with adding a configuration variable unless there's a compelling use-case. If you install the GlobalCssJs extension on your wikifarm, I think it's natural to then have ... global CSS and JS. If Wikimedia wikis aren't going to use this option, I'm not sure who ever would. Until there's a reasonable use-case for including a feature flag, I'd leave it out.

(In reply to MZMcBride from comment #15)

(In reply to Kunal Mehta (Legoktm) from comment #14)

Krinkle has said
(https://gerrit.wikimedia.org/r/#/c/94837/11/GlobalCssJs.hooks.php,cm)
that we should add a configuration option to control this feature, which I
agree with. He also said that it should probably be disabled on WMF wikis,
which I disagree with. ;)

I disagree with adding a configuration variable unless there's a compelling
use-case. If you install the GlobalCssJs extension on your wikifarm, I think
it's natural to then have ... global CSS and JS. If Wikimedia wikis aren't
going to use this option, I'm not sure who ever would. Until there's a
reasonable use-case for including a feature flag, I'd leave it out.

I understood that the point of this bug was user-level farm-global JS and CSS. Wiki-level farm-global JS and CSS that any admin on meta can edit would instantly turn this immediately into a WONTFIX, IMO.

Use case enough?

(In reply to James Forrester from comment #16)

I understood that the point of this bug was user-level farm-global JS and
CSS. Wiki-level farm-global JS and CSS that any admin on meta can edit would
instantly turn this immediately into a WONTFIX, IMO.

Why would that turn it into a wontfix? Meta admins already have access to a lot of global features, including centralnotice - which, from what I understand, allows the insertion of any arbitrary css and js. We already trust them with that, and they've shown to be sensible, so how would this be any different?

(In reply to Isarra from comment #17)

(In reply to James Forrester from comment #16)

I understood that the point of this bug was user-level farm-global JS and
CSS. Wiki-level farm-global JS and CSS that any admin on meta can edit would
instantly turn this immediately into a WONTFIX, IMO.

Why would that turn it into a wontfix? Meta admins already have access to a
lot of global features, including centralnotice - which, from what I
understand, allows the insertion of any arbitrary css and js. We already
trust them with that, and they've shown to be sensible, so how would this be
any different?

"Other stupid decisions have been made, so we should make more!" isn't a great argument. I think in this case we've got a great, useful tool (user-level farm-global JS and CSS) and a suspect, unrelated tool (in terms of user experience, not code).

CN currently does allow arbitrary insertion of code, yes, which is one of the reasons why there are plans to re-work it so that there aren't.

Writing code that goes active on all wikis at once is a major security vulnerability (and hugely disruptive to wikis). This is a major cross-wiki community issue to which a proper long-term solution is already underway (global gadgets), and throwing new technical toys doesn't make it easier. Why don't we focus efforts on the proper solution?

Anyway we are still waiting for Gadgets 2.0

(In reply to James Forrester from comment #18)

"Other stupid decisions have been made, so we should make more!" isn't a
great argument. I think in this case we've got a great, useful tool
(user-level farm-global JS and CSS) and a suspect, unrelated tool (in terms
of user experience, not code).

Writing code that goes active on all wikis at once is a major security
vulnerability (and hugely disruptive to wikis). This is a major cross-wiki
community issue to which a proper long-term solution is already underway
(global gadgets), and throwing new technical toys doesn't make it easier.
Why don't we focus efforts on the proper solution?

Perhaps we don't have the proper solution right now, but we do have this - and fear of community members does not seem like a very convincing argument to me why it wouldn't work well in the meantime, especially as it could well help folks to begin migrating away from the IMPORTS EVERYWHERE paradigm that is currently in place. Something doesn't need to be perfect to be a step in the right direction.

In terms of security, though, how would global gadgets even be any better in that respect? Wouldn't any on-by-default global gadget would do exactly that - go active on all wikis at once?

(In reply to Isarra from comment #20)

In terms of security, though, how would global gadgets even be any better in
that respect? Wouldn't any on-by-default global gadget would do exactly that

• go active on all wikis at once?

[off topic]
From what I remember from the prototypes, "on-by-default global gadgets" are were not planned for gadgets 2.0 (they would be globally available but not enabled by default).

See also the specs:

• [[mw:ResourceLoader/Version 2 Design Specification]].

(In reply to Isarra from comment #20)

(In reply to James Forrester from comment #18)

"Other stupid decisions have been made, so we should make more!" isn't a
great argument. I think in this case we've got a great, useful tool
(user-level farm-global JS and CSS) and a suspect, unrelated tool (in terms
of user experience, not code).

Writing code that goes active on all wikis at once is a major security
vulnerability (and hugely disruptive to wikis). This is a major cross-wiki
community issue to which a proper long-term solution is already underway
(global gadgets), and throwing new technical toys doesn't make it easier.
Why don't we focus efforts on the proper solution?

Perhaps we don't have the proper solution right now, but we do have this -
and fear of community members does not seem like a very convincing argument
to me why it wouldn't work well in the meantime, especially as it could well
help folks to begin migrating away from the IMPORTS EVERYWHERE paradigm that
is currently in place.

Except that you're going from a model where the wiki's admins (who have to clean up the mess) have actively done the step, and can see what changed, to one where some entirely invisible change has broken their wiki and they can't see why, how, or where to fix it.

Something doesn't need to be perfect to be a step in the right direction.

Indeed; I'm saying that the issue is that this is in the wrong direction, not that it's imperfect.

In terms of security, though, how would global gadgets even be any better in
that respect? Wouldn't any on-by-default global gadget would do exactly that

• go active on all wikis at once?

(a) The plan isn't for global gadgets to be on-by-default-able.
(b) The plan is to bring in some form of code review / second pair of eyes before going live to avoid this issue.

So basically, we can't trust our admins/stewards. But it's fine because this vapourware we've already been waiting on for years will solve all our problems anyway? Interesting.

And it's not like admins can't take down the servers pretty easily from a single project already.

That said, by all means, add a thing to disable the global project-wide css/js. I don't buy your arguments against having such global css/js, but that doesn't mean there's even a good use case here for it in the first place, and the same could probably be said of a lot of third-party projects, so having that option to just turn it off might be useful to them too.
Of course they could also just... well, not use that part of it. Plenty of projects don't even use the site css/js, but it's still there in case there does wind up a need for it.

Global gadgets (like LQT 3.0) are just a myth, everyone has wanted (and has been promised) global gadgets since at least 3 years ago. Let's not introduce such off-topic tangents in serious discussions, it's only a way to antagonise and polarise. From now on, forbidden topic on this bug.

I stand my point in comment 5, let's address one problem at a time. We currently have users forced to manually set the same CSS/JS preferences with a thousand edits, making that *1* edit will be huge progress. We've waited too long for this, we now have a solution, let's please take the path of least resistance and release it immediately.
<obligatory victimisation>I'm sick of my scattered custom CSS, insanity spreads; think of the children, who might be killed in a school shooting any time, or whatever. We're in a War on Terror. Etc.</obligatory victimisation>

I disagree that enabling MediaWiki:Global.js/css is a clear WONTFIX, but I also disagree that just because there is CentralNotice then this wouldn't change anything, for a number of reasons:

1. CentralNotice, as a feature, has been enabled with global acquiescence if not consensus (AKA unconditional surrender to fundraising);
2. it's not so completely trivial to inject any kind of CSS/JS via CentralNotice, while every sysop knows how to do so in .css/.js pages;
3. it's not easy because it's clearly not its scope, so any sysop would think about it very well before doing it and they would rather easily be spotted by looking at the green rows on [[m:Special:CentralNotice]];
4. Meta-Wiki sysops (and stewards) are trusted and non-evil, no need to repeat or prove it, but that doesn't mean mistakes don't happen, especially when things are new: when I was a Meta sysop I had, for years, to informally "police" CentralNotice usage in countless cases, but I'm *not* volunteering to write the equivalent of [[m:CentralNotice/Usage guidelines]].

So, we'll have this configuration, default whatever, feature off on Wikimedia projects; then, on the very day this is deployed on all wikis, start a discussion/notification on [[m:Wikimedia Forum]] for switching it on.

Now after all this unnecessarily egotist rant please behave kids, all of you.

(In reply to Nemo from comment #24)

I stand my point in comment 5, let's address one problem at a time. We
currently have users forced to manually set the same CSS/JS preferences with
a thousand edits, making that *1* edit will be huge progress. We've waited
too long for this, we now have a solution, let's please take the path of
least resistance and release it immediately.
<obligatory victimisation>I'm sick of my scattered custom CSS, insanity
spreads; think of the children, who might be killed in a school shooting any
time, or whatever. We're in a War on Terror. Etc.</obligatory victimisation>

+1. About MediaWiki:Global.js/css, nobody is requesting such a feature.

+1 to putting Global JS/CSS behind a flag, defaulting that to off,and deploying this. Smaller wikis are already paranoid of 'OMG WMF IS PUTTING CODE IN OUR SITES WIHTHOUT TELLING US', introducing another group of people (meta?) who can do that without a large consulting period seems to be asking for dramaz. There's a huge use case for Global User CSS/JS, and not so much for Global Global CSS/JS.

Submitted https://gerrit.wikimedia.org/r/#/c/114079/. It defaults to turning it off, but we could just as well default it to *on* in the extension and turn it off in wmf-config. I personally think that having it default to 'off' is the more secure default.

(In reply to Yuvi Panda from comment #26)

+1 to putting Global JS/CSS behind a flag, defaulting that to off,and
deploying this.

Could we simply remove this feature from the extension? It appears to have been tacked on as an afterthought, without a cohesive story about why and how it fits with the rest of the extension. (I contrast that with the primary functionality of the extension, which strikes me as a deliberate and practical solution for a well-defined problem.)

Hiding it behind a configuration variable does lower the stakes a lot, but it still plants a flag on this problem and adds another code artifact with which alternative solutions will have to contend.

(In reply to Ori Livneh from comment #28)

(In reply to Yuvi Panda from comment #26)

+1 to putting Global JS/CSS behind a flag, defaulting that to off,and
deploying this.

Could we simply remove this feature from the extension? It appears to have
been tacked on as an afterthought, without a cohesive story about why and
how it fits with the rest of the extension. (I contrast that with the
primary functionality of the extension, which strikes me as a deliberate and
practical solution for a well-defined problem.)

Hiding it behind a configuration variable does lower the stakes a lot, but
it still plants a flag on this problem and adds another code artifact with
which alternative solutions will have to contend.

On other non-wmf wiki farms, I can see this feature being very helpful. So I think we should leave it in behind the feature flag. If having that means shoutwiki/wikia/whomever will use it and help maintain the extension, I think it's a positive addition and we (wmf) shouldn't block it.

Regarding the feature on general WMF-specific security, the only attacks it would open up would be that meta admins would be able to attack wikis without the other wiki's users actually visiting meta (where meta's site js can then talk cross-domain to a wiki, and do whatever the admin wants). CN allows this too, but provides a lot of additional controls to make sure it's correctly used (timeouts, and targeting), and IIRC, campaigns can't be suppressed, whereas an edit to the .js can later be suppressed to hide that it once ran.

(In reply to Chris Steipp from comment #29)

On other non-wmf wiki farms, I can see this feature being very helpful. So I
think we should leave it in behind the feature flag. If having that means
shoutwiki/wikia/whomever will use it and help maintain the extension, I
think it's a positive addition and we (wmf) shouldn't block it.

Hmmm. Ok. Rescinding my objection, then.

I note here that this is in active discussion by various different teams at the Wikimedia Foundation, and that I'll leave a decision about this here as soon as possible.

I'm a bit late to the party it seems.

(In reply to Nemo from comment #24)

So, we'll have this configuration, default whatever, feature off on
Wikimedia projects; then, on the very day this is deployed on all wikis,
start a discussion/notification on [[m:Wikimedia Forum]] for switching it on.

This sounds like a good compromise to me.

Yup.

(In reply to James Forrester from comment #22)

Except that you're going from a model where the wiki's admins (who have to
clean up the mess) have actively done the step, and can see what changed, to
one where some entirely invisible change has broken their wiki and they
can't see why, how, or where to fix it.

I think this is mostly nonsense. An "entirely invisible change has broken their wiki" is true for a good number of software deployments every month and _always_ has been. There are reasonable arguments against having MediaWiki:Global.js/.css, but we really shouldn't pretend as though this is a novel way to suddenly and nearly silently annoy users with broken code. That's a much older tradition.

To put it another way, when diagnosing breakage on a wiki, users are already forced to consider modifications to per-user CSS/JS, modifications to site-wide CSS/JS (both on-wiki and off-wiki), modifications to global pages such as the global title blacklist and the global spam blacklist, modifications to MediaWiki (tracked via [[wikitech:Server Admin Log]]) and MediaWiki extensions, changes to PHP, Perl, Python, and many other languages whose code can update and break in subtly different ways, changes to the operating system that the servers are running on (which can dramatically change the most bizarre and unexpected behaviors), and then of course there are hardware-level changes and issues that can arise (network connectivity problems, excessive database load, etc.). I don't think having to check the page history of these two particular pages on Meta-Wiki is really going to add a non-negligible amount of effort in diagnosing an on-wiki issue. And the implementation provides _much_ greater accountability than other changes to the stack (such as hardware changes). Please be reasonable.

https://gerrit.wikimedia.org/r/#/c/114719/ deploys this to betalabs, and I guess we can let it marinate there for a bit.

In its present form, this extension cannot be enabled at this time.

Cluster-wide common.css and common.js pages take control away from small wikis. The possibility of some CSS or JS being placed in there that small wikis are not happy about and cannot easily override is unacceptable. This extension therefore represents a radical shift in the power structure our community. I'd be happy with this if, say, after some discussion it was agreed to limit the scope of what these pages are used for, so that that power structure does not change without prior agreement of all relevant parties.

From the security and privacy side, admins on Meta are trusted, so in my opinion the probability of a wilful security attack is so unlikely that it's not worth considering. However, Chris Steipp has informed me that he regularly has to fix privacy-related issues that are caused by JS that doesn't meet standards for security due to flaws in the code that have no malicious intent. As with the above, I'd potentially be happy with this if we can come up with a social solution to this problem.

The farm-wide common.js and common.css aspect of this extension need much, much more discussion between the WMF and the community before it is enabled. We need an agreement, formed by both the WMF and the community, on how these common.css and common.js files would be used. We need user stories for how and what this could be used. The onus is always on the enabler of something to show that it is needed and present use cases that show that, not on the deployments people to prove the opposite. Thus, the current request to enable it is premature.

The user-specific side of this extension, on the other hand, looks great. There are clear user stories for enabling it. After it's had a security review, we could turn that on.

Here's the way I'd like to see us proceed:

• Puts the farm-wide common.js and common.css aspect of this extension behind a feature flag, and make the configuration change that sets whether them to being disabled on the Wikimedia cluster.
• Enable the extension with the above changes merged.
• Start an in-depth discussion about the common.js and common.css aspect of this extension with the Meta community and representatives from other wikis that would be affected by this change. Present user stories for this feature. Form an agreement that both the WMF, the Meta community, and the individual wikis can support. We can then consider enabling the extension.

(In reply to Dan Garry from comment #36)

Here's the way I'd like to see us proceed:

• Puts the farm-wide common.js and common.css aspect of this extension

behind a feature flag, and make the configuration change that sets whether
them to being disabled on the Wikimedia cluster.

Feature Flag done and merged yesterday https://gerrit.wikimedia.org/r/#/c/114079/

Deploy to betalabs with only the user-specific JS and CSS enabled (and site-wide css / js disabled) will be done when https://gerrit.wikimedia.org/r/#/c/114719/ gets merged.

• Start an in-depth discussion about the common.js and common.css aspect of

this extension with the Meta community and representatives from other wikis
that would be affected by this change. Present user stories for this
feature. Form an agreement that both the WMF, the Meta community, and the
individual wikis can support. We can then consider enabling the extension.

So i guess that the extension can be enabled with the site-wide CSS/JS turned off, and then there is community consultation, etc before that particular feature can be turned on. However that does not need to block the deployment of the per-user CSS/JS parts of the extension. Is that accurate?

(In reply to Yuvi Panda from comment #37)

So i guess that the extension can be enabled with the site-wide CSS/JS
turned off, and then there is community consultation, etc before that
particular feature can be turned on. However that does not need to block the
deployment of the per-user CSS/JS parts of the extension. Is that accurate?

Correct. If the extension needs a testing or a security review, then those would block deployment. But from a product standpoint, the per-user CSS/JS part is totally fine.

This is live on Betalabs now \o/. Thanks to Mark Traceur.

(In reply to Yuvi Panda from comment #39)

This is live on Betalabs now \o/. Thanks to Mark Traceur.

And to all those involved in making this extension a reality. :-)

Still needs perf and arch review before it can be deployed for realz though.

Bump! Perf and Arch review?

(In reply to Yuvi Panda from comment #42)

Bump! Perf and Arch review?

This extension had a security review in bug 58438. The two open dependencies are bug 62600 and bug 62602. I'm not sure exactly what you mean by a "perf and arch" review. If that's an additional subtask needed to resolve this bug, it should probably filed as such in Bugzilla so that it can be appropriately assigned. Though I'd question the need for such a review given the implementation here and previous code reviews.

Sam, Greg, Dan, or Kunal: thoughts on where we stand regarding deploying this extension to Wikimedia wikis?

From my reading, I think this bug is pretty much ready for the "shell" keyword. Then we'll need to provide a week or two of forewarning before rolling this out. We can probably get this bug resolved by the end of April. Thoughts?

(In reply to Yuvi Panda from comment #42)

Bump! Perf and Arch review?

I reviewed the extension for potential performance issues just now and did not identify anything significant, so consider this comment a sign-off from me.

(In reply to MZMcBride from comment #44)

Sam, Greg, Dan, or Kunal: thoughts on where we stand regarding deploying
this extension to Wikimedia wikis?

Bug 62602 is the only real blocker left, bug 62600 is trivial and just needs someone to +2 the patch.

(In reply to Ori Livneh from comment #45)

(In reply to Yuvi Panda from comment #42)

Bump! Perf and Arch review?

I reviewed the extension for potential performance issues just now and did
not identify anything significant, so consider this comment a sign-off from
me.

Thanks Ori!

(In reply to Ori Livneh from comment #45)

(In reply to Yuvi Panda from comment #42)

Bump! Perf and Arch review?

I reviewed the extension for potential performance issues just now and did
not identify anything significant, so consider this comment a sign-off from
me.

I was not able to reproduce bug 62602 locally, and could not identify a cause by stepping through the code in my head. I think deployment to test / test2 would be useful. Greg G. and Dan G. OK'd it, so I'm going to go ahead with that.

(In reply to Ori Livneh from comment #47)

(In reply to Ori Livneh from comment #45)

(In reply to Yuvi Panda from comment #42)

Bump! Perf and Arch review?

I reviewed the extension for potential performance issues just now and did
not identify anything significant, so consider this comment a sign-off from
me.

I was not able to reproduce bug 62602 locally, and could not identify a
cause by stepping through the code in my head. I think deployment to test /
test2 would be useful. Greg G. and Dan G. OK'd it, so I'm going to go ahead
with that.

As I said in email, deployment to test and test2 is fine by me. Of course, bear in mind what I said in comment 36 for future deployments. :-)

As I see it, the next steps here are:

• figuring out who has global.css and global.js pages across Wikimedia wikis already and warning them about the impending deployment;

• scheduling a deployment; and

• deploying this feature to all public (including fishbowl, excluding private) Wikimedia wikis, starting with the phase 0 wikis and moving forward from there.

We also have the formal "architecture review" still to do. I've filed bug 68842 for that, and believe Krinkle will be able to do it.

(In reply to MZMcBride from comment #49)

• deploying this feature to all public (including fishbowl, excluding

private) Wikimedia wikis, starting with the phase 0 wikis and moving forward
from there.

We can't deploy this to fishbowl wikis since CentralAuth is not enabled on those wikis. Also we are not going to deploy the extension to loginwiki (no user/site CSS/JS runs there). It's already deployed to testwiki & test2wiki.

(In reply to Kunal Mehta (Legoktm) from comment #50)

We also have the formal "architecture review" still to do. I've filed bug
68842 for that, and believe Krinkle will be able to do it.

I think this is a formality to be sure, but all right.

(In reply to MZMcBride from comment #49)

• deploying this feature to all public (including fishbowl, excluding

private) Wikimedia wikis, starting with the phase 0 wikis and moving forward
from there.

We can't deploy this to fishbowl wikis since CentralAuth is not enabled on
those wikis. Also we are not going to deploy the extension to loginwiki (no
user/site CSS/JS runs there).

Oh right. Lame. I kind of wanted this on wikimediafoundation.org. Oh well.

It's already deployed to testwiki & test2wiki.

Hmmm, I kept missing this extension on [[testwiki:Special:Version]] and [[test2wiki:Special:Version]] because I was searching the page for "GlobalCssJs". Ouch.

(In reply to MZMcBride from comment #49)

• figuring out who has global.css and global.js pages across Wikimedia wikis

already and warning them about the impending deployment;

Would we need to check anywhere except Meta itself?
IIUC, this extension would only affect the editors who already have global files at Meta. Hence, anyone who is using mw.loader.load (or similar) to import css/js from other wikis, won't be affected directly. (Though, they'll possibly want to take advantage of the new functionality!)
Meta:
79: https://meta.wikimedia.org/w/index.php?title=Special:Search&limit=100&offset=0&ns2=1&search=intitle%3Aglobal.css
291: https://meta.wikimedia.org/w/index.php?title=Special:Search&limit=100&offset=0&ns2=1&search=intitle%3Aglobal.js

(and for reference:
Mediawiki:
1: https://www.mediawiki.org/w/index.php?title=Special%3ASearch&fulltext=Search&ns2=1&search=intitle%3Aglobal.css
1: https://www.mediawiki.org/w/index.php?title=Special%3ASearch&fulltext=Search&ns2=1&search=intitle%3Aglobal.js
Enwiki:
7: https://en.wikipedia.org/w/index.php?title=Special%3ASearch&fulltext=Search&ns2=1&search=intitle%3Aglobal.css
12: https://en.wikipedia.org/w/index.php?title=Special%3ASearch&fulltext=Search&ns2=1&search=intitle%3Aglobal.js
Dewiki
10: https://de.wikipedia.org/w/index.php?title=Special%3ASearch&fulltext=Search&ns2=1&search=intitle%3Aglobal.css
6: https://de.wikipedia.org/w/index.php?title=Special%3ASearch&fulltext=Search&ns2=1&search=intitle%3Aglobal.js
etc.)

So, we could probably just MassMessage the users on Meta, and reach everyone else via Tech/News etc? (Or, send an emphatic message to the Meta editors, and a quick headsup to the editors at other wikis)

(In reply to Quiddity from comment #52)

Would we need to check anywhere except Meta itself?

We need to provide a means for users to undo the mini-messes they've made, basically.

For example, [[m:User:Alan/global.css]] is loaded at https://zh.wiktionary.org/wiki/User:Alan/common.js. Some automated or semi-automated tool or script will be needed to identify and possibly correct pages such as https://zh.wiktionary.org/wiki/User:Alan/common.js, as I understand it.

For me personally, I use User:MZMcBride/monobook.js on a few wikis, which loads from m:User:MZMcBride/global.js, but I'll need to be able to figure out where specifically I've done this in order to blank or request deletion of those user subpages. Or in some cases, I'll want to only remove the line that loads global.js and leave everything else (e.g., [[mw:User:MZMcBride/monobook.js]]). Plus some of these user subpages probably have other useful edit history that we don't want to simply blow away.

IIUC, this extension would only affect the editors who already have global
files at Meta.

Yes, this is true. But Legoktm, using mwgrep, discovered that there are tens of thousands of pages across Wikimedia wikis that reference "global.css" or "global.js".

So, we could probably just MassMessage the users on Meta, and reach everyone
else via Tech/News etc?

Sure, but in that message, we'll need to provide some kind of remedy other than "visit over 800 wikis and check them individually". Lego and I discussed possibly a script for stewards that could delete user subpages that contain only a reference to global.js or global.css and that have very few distinct authors on an opt-in per-user basis.

But, broadly, we want to be incredibly hesitant of using bots to make automated edits to or deletions of pages of this kind, due to their very sensitive nature.

(In reply to MZMcBride from comment #53)

But, broadly, we want to be incredibly hesitant of using bots to make
automated edits to or deletions of pages of this kind, due to their very
sensitive nature.

There's nothing sensitive in disabling them. Lines importing from the user's global.js or global.css on other wikis can simply be commented by a bot, with an edit summary linking the announcement of the new feature.

I split the "we should help users fix their manual global.css/js" into bug 68933. I'll post some stats and ideas I have there in a minute.

(In reply to Nemo from comment #54)

(In reply to MZMcBride from comment #53)

But, broadly, we want to be incredibly hesitant of using bots to make
automated edits to or deletions of pages of this kind, due to their very
sensitive nature.

There's nothing sensitive in disabling them.

I mean(t) that the pages are generally associated with stewards and other power-users and we need to be very mindful of mucking with users' personal CSS and JS without explicit permission/consent.

Lines importing from the user's global.js or global.css on other wikis can
simply be commented by a bot, with an edit summary linking the announcement of
the new feature.

Commenting out is a good point. We'd discussed blanking or deleting, but not that. If we're doing bot edits, you're probably right that commenting out is best. Though I'm still not sure we should be doing bot edits and there were general concerns about leaving behind clutter (e.g., leaving user subpages around indefinitely that contain only commented-out code).

(In reply to MZMcBride from comment #56)

Lines importing from the user's global.js or global.css on other wikis can
simply be commented by a bot, with an edit summary linking the announcement of
the new feature.

Commenting out is a good point. We'd discussed blanking or deleting, but not
that. If we're doing bot edits, you're probably right that commenting out is
best. Though I'm still not sure we should be doing bot edits and there were
general concerns about leaving behind clutter (e.g., leaving user subpages
around indefinitely that contain only commented-out code).

What if it was commented out, a note left on the user's primary wiki talk page, and then if nothing happens, delete the commented out code after some arbitrary number of months like six?

(I copied comment 56 and comment 57 to bug 68933.)

The architecture and security reviews are done, and I assume bug 68933 (a low priority enhancement) is not a blocker to the deployment.

Can this be scheduled for, say, the next week?

Let's schedule this for Tuesday, August 26. That'll give us a little more than a week to notify users, and figure out a solution to bug 68933.

Change 154432 had a related patch set uploaded by Legoktm:
Enable GlobalCssJs on all CentralAuth wikis minus loginwiki

https://gerrit.wikimedia.org/r/154432

Change 154432 merged by jenkins-bot:
Enable GlobalCssJs on all CentralAuth wikis minus loginwiki

https://gerrit.wikimedia.org/r/154432