On Wed, Dec 11, 2013 at 12:00 PM, Brad Jorsch (Anomie) < bjorsch(a)wikimedia.org&gt; wrote: That's a big part of it. The other part is that Gadgets and site CSS/JS stuff has always been a system that empowers wikis to make their own changes quickly. Gerrit may produce better reviewed code, but it's certainly not a rapid process. -Chad

Hey, Has there been thought on how GitHub can potentially help here? I'm not sure it fits the workflow well, though can make the following observations: * People can click an "edit" button on GH to edit the code, much like on wiki. * If the GH web UI is used, people do not have to install git * They do not even need to understand git or know what it is * A workflow only involving code in actual source control can potentially be more streamlined and rely less on custom written solutions that also need to be maintained * Having such code in an "easy to use" (compared to git+gerrit) system that nevertheless provides a way to move to doing it more "professionally" might well have more people make the jump at some point Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 --

It's not a bad thought; but I don't think it'll work for a couple of reasons: * It causes people to leave the site * GItHub for various reasons requires an account (which most likely they wont have and it doesn't seem correct to require one given our editing philosophy) * The editing interface is completely different that of the MediaWiki interface * It would most likely complicate what's already going to be a fairly complicated merge / review process. ~Matt Walker Wikimedia Foundation Fundraising Technology Team On Wed, Dec 11, 2013 at 12:21 PM, Jeroen De Dauw &lt;jeroendedauw(a)gmail.com&gt;wrote;wrote:

Heh; wrong thread to discuss that in Jon -- this one is about non-developers helping out writing documentation for configuration variables and what not without having to modify the source file in gerrit. The OTHER thread, which I forked from, is the one about what we already allow (users to modify common.js and common.css) and how to get that code reviewed. ~Matt Walker Wikimedia Foundation Fundraising Technology Team On Wed, Dec 11, 2013 at 2:35 PM, Jon Robson &lt;jdlrobson(a)gmail.com&gt; wrote:

On 2013-12-11 4:52 PM, Bartosz Dziewoński wrote: 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. For example take a gadget which runs unconditionally on a specific URL, like how the AJAX recent changes does, triggering a special view when on `Special:BlankPage?blankspecial=ajaxrc`. Now say the gadget happens to take user input from the URL, for example a page title, because the gadget wants per-page stuff and include a link inside the toolbox on every page that would link to the tool passing along the title of the page (title might be the most common, but there are plenty of other reasons to accept user input from the URL). If the gadget author decided to output this title into the page, they might accidentally do it in a way that amounted to raw html concatenation: Such as `+ userInput +`ing it into a block of html, passing it to a mw.message in a parameter that accepts raw html, using innerHTML in the wrong way, using some other interface that actually accepts HTML, etc... If this happened, a glaring XSS vector would suddenly become open. Anyone, anywhere on the internet could simply include an iframe pointed to the URL and use that parameter to inject any html and script they wanted creating a full-blown XSS attack. (And thanks to user scripts, etc... escalating any momentary XSS attack into a persistent on-site XSS attack is trivial) ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]