Στις 11-12-2013, ημέρα Τετ, και ώρα 23:01 -0500, ο/η MZMcBride έγραψε:
...
The idea being proposed in bug 58236, as it was framed, was a non-starter. It simply riled people up and caused them to become defensive. (Its sibling bugs didn't help.) However, if we re-frame the issue, I think many people would agree that if there's a desire to enable a gadget for _all_ users, whatever functionality that is being provided by that gadget probably ought to be integrated into a MediaWiki extension.
I agree that code in MediaWiki:Common.js and in gadgets can cause problems with performance, security or even privacy that code review might prevent. A recent case in point was the Wdsearch code on en wikipedia, invoked on a few other wikis such that every viewed page caused a hit to toollabs, rendering that project inaccessible in short order.
Having said that, I think MZMcBride is exactly right; we cannot go in telling folks 'You know all that freedom you had to create and edit your local wiki's javascript/gadgets and get immediate results? We're going to take that away now.' Like it or not, gadgets and js on many wikis is a matter of copy-paste and trying tweaks nearly at random to get the thing to work locally, and that's ok, because that's all the tools some wiki communities have available. Many don't have developers on hand, and they shouldn't have to; just as wikitext was intended to make editing easy for everybody and not just experts, our js/css setup was intended to make editing and adjustment of *that* easy -- or at least approachable -- for everybody and not just experts. And this has been the way of things for over ten years; changing it is a Big Deal.
If we start a conversation with the folks who write and/or maintain the js and gadgets on their wikis, setting forth our goals (catching security/privacy/performance issues ahead of time) and asking for collaboration on how we can achieve those goals, rather than coming in with a decision already made for them, we're much more likely to get something constructive out of it.
A pool of folks willing to review code in a timely fashion may be one piece of the solution; migration of some gadgets to MW extensions, as has been mentioned, may be another. We can suggest these as possibilities and see what else may be proposed.
This list is a fine place to come up with more ideas; it is not a fine place, however, to have the real community discussion.
Ariel