Talk:Community Tech/Global gadgets

Creating a sane future proof tool

The notion of simple using a single repository to store global gadgets and have these automatically usable everywhere is noble. Still things that should be considered blockers for making this tool future proof and sane:

• Creating a default mandatory code review process - https://phabricator.wikimedia.org/T71445 .
• Creating unique identifiers, e.g. a hash of the code - https://phabricator.wikimedia.org/T117540
• Automated documentation - https://phabricator.wikimedia.org/T53651
• Choosing a suitable repository - Creating a new wiki (e.g. gadgets.wikimedia.org or phabricator )
• Mandatory tests before going active - https://phabricator.wikimedia.org/T39230

The rationale for these suggestions is fairly simple. While local gadgets have fairly free editing, many of them cause problems such as :

• Software issues - A badly designed gadget may in turn break basic site functionality. It is frequently the case were these are reported in local discussion areas, then phabricator. In some cases these may lead to foot shooting and a wild goose chase , e.g.:
  • https://phabricator.wikimedia.org/T108282
  • https://phabricator.wikimedia.org/T135378
  • https://phabricator.wikimedia.org/T132161
  • https://phabricator.wikimedia.org/T139919
• Security issues - Wikimedia accounts have been compromised many times, and it is and was trivial for these hackers to change javascript, redirect wikimedia sites to an illegal site, add XSS, and much more. This is not theoretical and has happened at least on Wikia's wikis (https://phabricator.wikimedia.org/T71445#1763357). It just so happens that Wikimedia actively ignores open XSS issues on many wikis, just like wikia did, until it came back to bite them multiple times (maybe wikimedia needs a similar wake up call?).

While local issues can be quickly and easily fixed, having a global gadget makes these problems much much worse. As the code will hit all wikis that import it, and it may not be clear where the errors are coming from.

Some suggestions:

• Consider the feasibility of storing the code transparently on a proper code repository, e.g. phabricator, and transparently allowing editing through the wiki. Alternatively, store and edit the code in the wiki, synchronize to a phabricator repository, and run periodic basic tests using code testing infrastructure.
• Separate admin rights and gadget editing rights. Most admins / stewards / bureaucrats are not qualified to edit the code, and there should be some clear vetting process before someone becomes a gadget developer. This should not be optional, exposing XSS and security issues to one wiki is bad enough, exposing this globally would be very irresponsible. (Maybe Codeacademy could issue unique badges for this. )
• Wikis import a specific revision of the code and must deliberately choose to upgrade to newer version (this eliminates issues with breaking changes).
• Clear approval process for code to go live, e.g. maybe after a different developer approves it, instead immediately.

197.218.80.145 13:08, 15 January 2017 (UTC)

Thank you for the suggestions and ideas. Do you have a username or a Phabricator ID? It would be nice to be able to talk some more about this. -- DannyH (WMF) (talk) 21:18, 18 January 2017 (UTC)