Talk:Community Tech/Global gadgets
Creating a sane future proof tool Edit
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.:
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.
- 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.
22.214.171.124 13:08, 15 January 2017 (UTC)