Last modified: 2014-08-29 08:12:57 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T72125, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 70125 - Advertise that some site code (common.js and gadgets) are now protected & maintained by WMF
Advertise that some site code (common.js and gadgets) are now protected & mai...
Status: NEW
Product: Wikimedia
Classification: Unclassified
Site requests (Other open bugs)
wmf-deployment
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-08-28 14:34 UTC by Rainer Rillke @commons.wikimedia
Modified: 2014-08-29 08:12 UTC (History)
10 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Rainer Rillke @commons.wikimedia 2014-08-28 14:34:20 UTC
Given the super protection of a MediaWiki:Common.js, that makes it unmaintainable for local administrators, I’d like to get a statement by the Wikimedia Foundation's development department that it is going to maintain all script pages it super-protects or to show a proper way to propose and approve changes of those in a timely fashion.
If this isn’t going to happen, I’ll file another bug to remove either super protection or site wide community scripting support as unmaintained scripts are unacceptable for providing a stable service to our visitors and contributors.
Comment 1 John F. Lewis 2014-08-28 14:39:39 UTC
This is inappropriate. The Foundation are not preventing every single administrator from editing site-wide js pages. Erik has stated they are proposing a code-review sytle system and I have seen a patch which separates site js and CSS from the editinterface package.

Sitewide js pages will not be removed from MediaWiki nor will superprotect from Wikimedia as visible by the 30 patches reverting the change abandoned by operations. I'll leave this bug open but I am urging an INVALID close.
Comment 2 Bartosz Dziewoński 2014-08-28 14:41:28 UTC
I think Rillke only intended to add such a note on the pages that have actually been superprotected, not all that might technically be some day.
Comment 3 John F. Lewis 2014-08-28 14:43:09 UTC
In theory this is something a local community can do so bringing it to Bugzilla is you know :)
Comment 4 Rainer Rillke @commons.wikimedia 2014-08-28 14:56:59 UTC
(In reply to Bartosz Dziewoński from comment #2)
Thank you, yes, there should be some notification on each of such pages how to propose changes to them and get these reviewed in a *timely manner*.

(In reply to John F. Lewis from comment #1)
> This is inappropriate.
Please be specific about what is inappropriate. The bug's description contains multiple options.

> The Foundation are not preventing every single administrator from editing 
> site-wide js pages.
This was not true. And I see that in future, super protection might be used again which renders all non-staffers unable to edit pages with this protection level.


> Erik has stated they are proposing a code-review sytle system
Code review sounds good, though non-default gadgets should be still deployable without having someone reviewing them. There won't be enough resources.

> a patch which separates site js and CSS from the editinterface package
Cool. Gerrit #?

> nor will superprotect from Wikimedia as visible by the 30 patches reverting 
> the change abandoned by operations
Fine, then let's go with what Bartosz Dziewoński suggests.

DMCA takedown notices from the legal team consist of comprehensive information about how to challenge them and often also why the DMCA requests were complied with. I think we should have something similar for super protection:
* What will be the right channel to get emergency-changes quickly applied to super protected pages.
* Why were pages super protected?
* What is super protection?
Comment 5 Rainer Rillke @commons.wikimedia 2014-08-28 14:59:04 UTC
(In reply to John F. Lewis from comment #3)
Well, every local community would have to develop its own wording, so why not doing it centralized?
Comment 6 Chad H. 2014-08-28 15:03:29 UTC
Tightening summary since this only applies to superprotected pages. The rest of CSS/JS is still very much in an individual wiki's control.
Comment 7 John F. Lewis 2014-08-28 15:04:34 UTC
(In reply to Rainer Rillke @commons.wikimedia from comment #4)
> > This is inappropriate.
> Please be specific about what is inappropriate. The bug's description
> contains multiple options.
The fact it originally looked out to be yet another 'oh let's remove this protection because x or y'. I retract that now.

> > The Foundation are not preventing every single administrator from editing 
> > site-wide js pages.
> This was not true. And I see that in future, super protection might be used
> again which renders all non-staffers unable to edit pages with this
> protection level.
It is true technically. They used it once, this does not mean *everything* will be super protected because x or y.

> > a patch which separates site js and CSS from the editinterface package
> Cool. Gerrit #?
https://gerrit.wikimedia.org/r/#/c/154452/
Comment 8 Jesús Martínez Novo (Ciencia Al Poder) 2014-08-28 15:18:24 UTC
> Erik has stated they are proposing a code-review sytle system

bug 69445
Comment 9 Steinsplitter 2014-08-28 15:24:22 UTC
(In reply to Jesús Martínez Novo (Ciencia Al Poder) from comment #8)
> > Erik has stated they are proposing a code-review sytle system
> 
> bug 69445

for non large wikis. To be honest, on large wikis are engough admins to revert errors if needed. At lest "prevent saving if too much validations (jshint etc.) errors.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links