Bartosz Dziewoński wrote:
I really liked what Jon said at the beginning, and what has apparently been lost in the discussions already – "Keep gadgets for experiment, but ensure global gadgets are held to a higher standard of quality and made more visible to a wider audience.". Proper global gadgets still don't exist, but when they finally happen, experienced coders who do this for a living should take them under their wings (to clean up existing code, to check new contributions – but a "post-merge" code-review might still be more appropriate); but local gadgets should stay the safe haven of innovation they are now.
Yep. We should obviously find ways to improve performance and reduce unnecessary code. Global (Wikimedia-wide) gadgets would be a good approach to take. Converting successful JavaScript gadgets into PHP MediaWiki extensions would be another good approach to take. There are others.
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.
Brian Wolff wrote:
Submitting patches is not the problem. Getting them reviewed in a timely fashion is a problem. Having power taken out of local wikis hands is a problem.
Yep.
Brian Wolff also wrote:
I also think it would be unenforcable unless one plans to ban personal js in all forms.
Quite: if you ban site-wide JavaScript (Common.js, Monobook.js, gadgets, etc.), people will simply revert to using per-user JavaScript (i.e., User:Foo/script.js) and importScript(), as they did for years.
Tyler Romeo wrote:
I'll be frank. I don't really care. If power is really the issue, then let people from the wikis have +2 on their wiki's Gerrit project.
Currently you already have a +1/+2 model on the wiki. Any user can +1 while any local administrator can +2.
Tyler Romeo also wrote:
If the cost of increasing site-wide security and alleviating developers' pain is a few upset users who will get over it in a month or two, then so be it.
With respect, your posts exhibit hints that you have not been a community member of a Wikimedia wiki, though perhaps I'm mistaken. I find it much easier to agree with Bartosz and Brian than with you. It's very important that wikis have sovereignty and freedom to experiment.
Daniel Friesen wrote:
Bartosz Dziewoński wrote:
And it's not very easy to cause a major security bug when writing code that runs client-side and usually only in response to user action. Most gadgets don't, say, parse untrusted input from *other* users.
That's not always true. There are a variety of scenarios where a Gadget author may do something relatively common and innocent, and through a bad practice mistake could inadvertently introduce a gaping XSS vector that could be used to attack any user for whom said gadget is merely enabled.
While it's probably impossible to accurately measure, anecdotal evidence suggests that XSS vulnerabilities are far more common in MediaWiki core and its extensions and than in JavaScript gadgets. :-)
Jon Robson wrote:
I'd love us to get into a situation where Gadgets continue to be a platform for innovation but community and developers work hard to mature these gadgets into performant, test protected beasts that live in a single code repository. I do feel at times that we treat our users like dirt in terms of their experience...
Further anecdotal evidence: I hear a lot of users complain about MediaWiki extensions (UniversalLanguageSelector, ArticleFeedbackv5, FlaggedRevs) and even occasionally about MediaWiki core, all of which go through formal code review. I don't hear many complaints about JavaScript gadgets or CSS. In fact, in my experience certain actions (such as nominating a page for deletion) have become nearly impossible without the use of gadgets.
MZMcBride