Στις 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