I can see both sides of the argument here and just wanted to provide my thoughts on this matter. The short version is basically this: Keep gadgets for experiment, but ensure global gadgets are held to a higher standard of quality and made more visible to a wider audience.

As a developer the existence of Common.js and gadgets adds an extreme amount of unnecessary complexity to our code. In the early days of the mobile site, we missed an entire week of deployment due to certain global gadgets breaking on certain wikis that had not been designed for mobile that we had overlooked. We had to spend this week disabling all gadgets on mobile so we could actually continue work and remove this complexity. It seems extremely unreasonable to expect any engineer of MediaWiki to know exactly which gadgets are enabled on every single wiki using MediaWiki that exists and what actions they perform and under what circumstances. In addition to this, unless I am mistaken - and if I am this shows how much of a black hole Gadgets are for those not in the loop - gadgets do not tend to have tests, or any code review type process (editing a wiki page of a global gadget is like self merging your own code which we frown upon for core - so why do we encourage it here?).

Wiki pages in my opinion are also not the best medium for code collaboration. There are various CSS rules in MediaWiki:Common.css that seem to only work on a small amount of pages thus the CSS is not optimal and we are hitting all our users badly in the performance (There are an extremely huge amount of rules for horizontal lists for example). Wiki pages can also be edited in isolation and unaware of each other so you end up generating lots of code that does the same thing rather than consolidating code as you would if it was under version control in a shared repository (FYI on the Barack Obama page according to Chrome web tools 90% of CSS rules we send go unused to a reader - although this a larger problem in that core doesn't even have a shared repository of styles that other extensions can use).

All this said, I think gadgets are a great experimentation ground and create some extremely useful tools for editors and readers. However I do think various changes can be confusing for the average //reader// if enabled globally. I remember around the time of the Echo launch there was friction between developers of the feature and community members and the orange bar of death resurfaced promptly leaving an unacceptable very confusing fragmented experience for all readers who were not in that loop.

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...

Many a time I've talked about this I've hit the argument that gerrit is confusing to some users and is a barrier for development, but this is a terrible unacceptable attitude to have in my opinion. Our end users deserve a certain standard of code. I'm aware using a code review process can slow things down but I feel this is really essential. I for one greatly benefit from having every single piece of my code scrutinized and perfected before being consumed by a wider audience. If this is seen as a barrier, someone should investigate making it possible to send wiki edits to Gerrit to simplify that process.

Anyway that concludes my thoughts here... (braces himself for lions)

On Mon, Dec 9, 2013 at 2:01 PM, Paul Selitskas p.selitskas@gmail.com wrote:

Yep, that's what I did too a year a two ago. Since some parts of front-end code work quite differently in Common.js and gadgets, it's bettet to put modular stuff (esp. ones that users would like to opt-out of) in gadgets.

On Tue, Dec 10, 2013 at 12:38 AM, Liangent liangent@gmail.com wrote:

...

MediaWiki:Common.js can also create disagreement and defaults change without notice.

Actually what I did sometimes is to move code from MediaWiki:Common.js to default gadgets, so it can be disabled per user (for example, some users are using a too slow computer or network), and at the same time, this

makes

...

maintenance easier for developers, because gadgets can be made

modularized,

...

instead of using a big JavaScript and CSS file (Common.js/css).

-Liangent

On Tue, Dec 10, 2013 at 5:02 AM, K. Peachey p858snake@gmail.com wrote:

...

For wider discussion

---

From: <bugzilla-daemon <at> wikimedia.org> Subject: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites<

http://news.gmane.org/find-root.php?message_id=%3cbug%2d58236%2d3%40https.bu...

...

...

...

Newsgroups: gmane.org.wikimedia.mediawiki.bugs< http://news.gmane.org/gmane.org.wikimedia.mediawiki.bugs%3E Date: 2013-12-09 20:41:41 GMT (19 minutes ago)

https://bugzilla.wikimedia.org/show_bug.cgi?id=58236

Web browser: --- Bug ID: 58236 Summary: No longer allow gadgets to be turned on by default

for

...

all users on Wikimedia sites Product: Wikimedia Version: wmf-deployment Hardware: All OS: All Status: NEW Severity: normal Priority: Unprioritized Component: Site requests Assignee: wikibugs-l <at> lists.wikimedia.org Reporter: jared.zimmerman <at> wikimedia.org CC: benapetr <at> gmail.com, bugzilla+org.wikimedia <at> tuxmachine.com, dereckson <at> espace-win.org, greg <at>

wikimedia.org

...

, tomasz <at> twkozlowski.net, wikimedia.bugs <at> snowolf.eu Classification: Unclassified Mobile Platform: ---

Gadgets being turned on for all site users (including readers) can

cause

...

a

...

confusing users experience, especially when there is some disagreement

and

...

defaults change without notice (readers are rarely if ever part of

these

...

...

discussions)

Move to model where gadgets are per user rather than part of a default experience for users

-- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l <at> lists.wikimedia.orghttps://

lists.wikimedia.org/mailman/listinfo/wikibugs-l

...

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

-- З павагай, Павел Селіцкас/Pavel Selitskas Wizardist @ Wikimedia projects _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On 11/12/13 19:21, Chad wrote:

Sending wiki edits to Gerrit for review? Absolutely not.

I'm totally cool with the idea of code review for Gadgets & so forth, just not using Gerrit. We considered it for Scribunto (and heck, I wrote half of a proof of concept) but shot it down because the idea totally sucked.

-Chad

Thank you.

2013/12/12 Quim Gil qgil@wikimedia.org

On 12/11/2013 11:21 AM, Chad wrote:

...

Sending wiki edits to Gerrit for review? Absolutely not.

I'm totally cool with the idea of code review for Gadgets & so forth,

just

...

not using Gerrit. We considered it for Scribunto (and heck, I wrote half of a proof of concept) but shot it down because the idea totally sucked.

I think I agree with your conclusion, but based on my assumptions. It would be useful to know why you think it sucked.

Alright, not on Gerrit. Where?

https://www.mediawiki.org/wiki/Gadgets_2.0 ?

-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com ‪“We're living in pieces, I want to live in peace.” – T. Moore‬

On Fri, Dec 13, 2013 at 3:34 PM, Jon Robson jdlrobson@gmail.com wrote:

I raised a new bug which is hopefully more focused about the issues here: https://bugzilla.wikimedia.org/show_bug.cgi?id=58462

That strikes me as a RESOLVED INVALID bug, considering global gadgets don't actually exist yet. Or did Gadgets 2.0 get put in Gerrit and merged while I wasn't looking?

On Fri, Dec 13, 2013 at 5:04 PM, Bartosz Dziewoński matma.rex@gmail.com wrote:

On Fri, 13 Dec 2013 21:40:35 +0100, Brad Jorsch (Anomie) bjorsch@wikimedia.org wrote:

...

On Fri, Dec 13, 2013 at 3:34 PM, Jon Robson jdlrobson@gmail.com wrote:

...

I raised a new bug which is hopefully more focused about the issues here: https://bugzilla.wikimedia.org/show_bug.cgi?id=58462

That strikes me as a RESOLVED INVALID bug, considering global gadgets don't actually exist yet. Or did Gadgets 2.0 get put in Gerrit and merged while I wasn't looking?

It's sorta kinda happening as we speak while no one is looking ;)

https://bugzilla.wikimedia.org/show_bug.cgi?id=57891

That's not gadgets, that's user CSS/JS.

On Wed, Dec 11, 2013 at 2:04 PM, Jon Robson jdlrobson@gmail.com wrote:

Many a time I've talked about this I've hit the argument that gerrit is confusing to some users and is a barrier for development, but this is a terrible unacceptable attitude to have in my opinion. Our end users deserve a certain standard of code. I'm aware using a code review process can slow things down but I feel this is really essential. I for one greatly benefit from having every single piece of my code scrutinized and perfected before being consumed by a wider audience. If this is seen as a barrier, someone should investigate making it possible to send wiki edits to Gerrit to simplify that process.

I can definitely understand the reasoning behind this. Right now with both Gadgets and common.js we are allowing non-reviewed code to be injected directly into every page. While there is a bit of trust to be had considering only administrators can edit those pages, it is still a security risk, and an unnecessary one at that.

I like the idea of having gadgets (and any JS code for that matter) going through Gerrit for code review. The one issue is the question of where would Gadget code go? Would each gadget have its own code repository? Maybe we'd have just one repository for all gadgets as well as common.js (something like operations/common.js)? I don't think sending wiki edits to Gerrit is too feasible a solution, so if this were implemented it'd have to be entirely Gerrit-based.

*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science

On Wed, Dec 11, 2013 at 3:19 PM, Brian Wolff bawolff@gmail.com wrote:

I would expect any sort of code review requirement for gadgets to meet strong resistance, especially on the smaller wikis.

Unless it was the community doing code review on itself, maybe. To some extent this already happens on enwiki.

I also think it would be unenforcable unless one plans to ban personal js in all forms.

Not necessarily. Individual user JS applies only to the one user, while gadgets apply to potentially many and [[MediaWiki:Common.js]] to everyone.

On Wed, Dec 11, 2013 at 3:30 PM, Tyler Romeo tylerromeo@gmail.com wrote:

In this case we should promptly work to fix this issue. To be honest, the only difficult part of our code review process is having to learn Git if you do not already know how to use it. If there were a way to submit patchsets without using Git somehow (maybe some kind of desktop application), it may make things easier.

I agree, it would make life a lot easier! Something like TortoiseSVN, but for Git, then?

On Wed, Dec 11, 2013 at 4:13 PM, Brian Wolff bawolff@gmail.com wrote:

I guess I should have said without banning [[MediaWiki:Common.js]]. I was kind of assuming this proposal meant banning all site wide js (Since otherwise what's the point of banning default on gadgets? Default on gadgets is just a way to separate common.js into modules for easier maintainability)

Yeah I think it's pretty much established that globally banning Gadgets is simply not going to work unless you also ban common.js. If anything it makes the problem worse, since at least Gadgets allow some organization for the chaos (and users can turn off gadgets).

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.

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. 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.

*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science

On Wed, Dec 11, 2013 at 7:15 PM, Chad innocentkiller@gmail.com wrote:

I'm going to say this one final time, since I'm feeling like a broken record today...

We are not going to use Gerrit for gadgets and so forth. It is the *wrong* tool for the job. Full stop.

Gerrit is a code review tool. Gadgets are code. It is the absolute *correct* tool for the job. At the very least it is a more proper tool than using wiki software. If Wikipedia wants to have any resemblance of proper software security, having gadgets stored on wiki should disappear very quickly.

*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science

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

Reading this thread and thinking about the proposed changes, im getting stuck, and there may be some inconsistencies. The problems identified seem to be

1. Core development is made much harder because of an abundance in local differences in wikis caused by local js and css.

2. Local wikis security may be compromised by lack of formalised structured code review of local js and css. (by staff/core developers?)

The former seems to be generally acknowledged, and a large problem, the latter more or less debated, and a smaller problem (is that correct)

Fixing 1 pretty much seems unfixable apart from completely banning local js altogether, which is something we don't want to do. Most of the solutions proposed as a compromise focus on fixing 2 by use of code review tools and standards, while still using 1 as a reason, though it actually does nothing to fix it.

Is 2 still big enough of a problem to be fixed? If so, what does it need most? A more structured approach? More staffers reviewing gadgets? The use of the same tooling core uses?

To me it seems more people doing review is a good thing, but are there enough resources for that? "There should be more review" more or less implies that that should be done by people who have +2 in core right now. I'm not sure if that is indeed the way to read former posts, but if it is, that is probably a bad idea. Apart from the additional workload that would cause - in this scenario I imagine loads and loads of patches waiting for review - it again moves the responsibility for maintaining a local wiki to a centralized body, which is bad for the local community.

Alternatively, if we want other people to do the code review (e.g. local admins), shouldn't we be asking them what tools they need, if any, to effectively review and deploy patches, rather than centrally decide it for them? If we do ask them, I sincerely doubt their answer will be git and gerrit.

As far as centralized gadgets go, lets not worry too much about those until the infrastructure for them actually exists.

On Dec 12, 2013 8:58 AM, "Chad" innocentkiller@gmail.com wrote:

+1 to everything MZM said.

Except the XSS in user/site/gadget JS vs core/extension XSS. Intuition tells me the former is much more common. We just think about

core/extension

XSS because it gets a security release and tons of attention.

-Chad

On Dec 11, 2013 8:01 PM, "MZMcBride" z@mzmcbride.com wrote:

...

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

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Thu, Dec 12, 2013 at 7:21 AM, Brian Wolff bawolff@gmail.com wrote:

I actually feel the opposite. Point #1 does not make core development much harder. There's the occasional issue with local customization, but in my experience these types of issues are few and far between. Point #2 does scare me a little bit, particularly on the non enwikipedia sites. I agree with Chad that anecdotes in this area probably have more to do with no one looking, than any actual greater security.

--Bawolff

I'll compile hard numbers when I have some free time, but I strongly agree with Bawolff here. Site javascript has a significant percentage of the totally xss'es we've fixed, and almost no one is reviewing them.

On Wed, 11 Dec 2013 21:30:15 +0100, Tyler Romeo tylerromeo@gmail.com wrote:

In this case we should promptly work to fix this issue. To be honest, the only difficult part of our code review process is having to learn Git if you do not already know how to use it. If there were a way to submit patchsets without using Git somehow (maybe some kind of desktop application), it may make things easier.

There is also gerrit, which is widely considered a clusterfuck.

You can actually submit patches almost without using git (apart from `git clone` and `git diff`) using http://tools.wmflabs.org/gerrit-patch-uploader/ (but they still have to be reviewed via gerrit).

As both an active gadget writer (on pl.wikipedia) and a core developer, let me say that while I would *love* to have a somewhat formalized code-review process for gadgets, it is pretty much not possible, and the reason is twofold.

First, code-review is, apart from spotting bugs, about getting the code to adhere to certain formal standards and code conventions. We have lots of such standards and conventions in core, for example, and while almost all of them are useful or (at least not troublesome) to a seasoned developer working in a team of a few dozen people, every single one is also *damned boring* – and if we make writing gadgets not enjoyable, people will stop writing them.

When you're a single person working on a 200-line script, who the hell cares if you use == or ===, or if you use multiple `var` declarations in a function, or if you use `alert()` to notify the user that something went very wrong? In most cases this does not matter, and if the code works, that's all good. Unfortunately writing code for core is largely about petty things like this; if you're a biologist who learned to program for fun and wrote a tool in JS to scratch your own itch, code style matters very little, both for you and for other people who enjoy using your toy.

Second, en.wp might be an exception, but most communities simply don't have enough active people. On pl.wp (ninth largest Wikipedia), I am currently the only active JavaScript person; who do I ask for review? Even if core developers or people from other wikis volunteered, they'd surely not be able to understand the "domain", especially due to the language barrier. And my core experiences say that the slowest part of code-review is getting someone to do it (I have 30+ unreviewed or +1'd patches pending right now).

And as Brad mentioned, informal code review happens; people watch gadgets' pages and look at the changes, non-admins have to ask admins to have their gadget code "merged", admins are generally responsible people anyway, and even *if* something bad does happen (which I feel happens less often than with MW deployments, really), reverting or fixing the change takes one click instead of a multi-hour deployment process.

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.

In the Hebrew Wikipedia it's pretty straightforward: A proposal is made at the Village Pump-like page, people bring up arguments for and against, and if there are no strong arguments against, an administrator makes the gadget default after a few days.

-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com ‪“We're living in pieces, I want to live in peace.” – T. Moore‬

2013/12/10 Chris Steipp csteipp@wikimedia.org

I think the bug is sufficiently killed at this point, so I wanted to add my $.02 here instead of there.

As hoo mentioned on the bug, there have been some gadgets that have opened up some serious security and performance issues, so I can sympathize with Jared wishing they didn't exist at times. But without them, we would get even worse stuff hacked into Common.js. So I think we need to focus on the desired process so useful gadgets can safely be set as default.

Do any of the communities have formal policies on how code should be formalized into a gadget, and a process for setting that gadget as a default? There seems to be some inferred policy from Wikipedia:Gadget, but I'm not finding a specific policy on it.

On Tue, Dec 10, 2013 at 9:01 AM, Gerard Meijssen gerard.meijssen@gmail.comwrote:

...

Hoi, A blanket ban like this is an extremely bad idea. The notion that you should think twice before you make something a default option does have merit.

Gadgets, java script all provide functionality that is sometimes / often experimental. Without the benefit of experiments we will get into a rut,

We

...

will have moved away from the credo of "be bold". Thanks, GerardM

On 9 December 2013 22:02, K. Peachey p858snake@gmail.com wrote:

...

For wider discussion

---

From: <bugzilla-daemon <at> wikimedia.org> Subject: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites<

http://news.gmane.org/find-root.php?message_id=%3cbug%2d58236%2d3%40https.bu...

...

...

...

Newsgroups: gmane.org.wikimedia.mediawiki.bugs< http://news.gmane.org/gmane.org.wikimedia.mediawiki.bugs%3E Date: 2013-12-09 20:41:41 GMT (19 minutes ago)

https://bugzilla.wikimedia.org/show_bug.cgi?id=58236

   Web browser: ---
        Bug ID: 58236
       Summary: No longer allow gadgets to be turned on by default

for

...

                all users on Wikimedia sites
       Product: Wikimedia
       Version: wmf-deployment
      Hardware: All
            OS: All
        Status: NEW
      Severity: normal
      Priority: Unprioritized
     Component: Site requests
      Assignee: wikibugs-l <at> lists.wikimedia.org
      Reporter: jared.zimmerman <at> wikimedia.org
            CC: benapetr <at> gmail.com,
                bugzilla+org.wikimedia <at> tuxmachine.com,
                dereckson <at> espace-win.org, greg <at>

wikimedia.org

...

, tomasz <at> twkozlowski.net, wikimedia.bugs <at> snowolf.eu Classification: Unclassified Mobile Platform: ---

Gadgets being turned on for all site users (including readers) can

cause

...

a

...

confusing users experience, especially when there is some disagreement

and

...

defaults change without notice (readers are rarely if ever part of

these

...

...

discussions)

Move to model where gadgets are per user rather than part of a default experience for users

-- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l <at> lists.wikimedia.orghttps://

lists.wikimedia.org/mailman/listinfo/wikibugs-l

...

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l