Topic on Talk:ResourceLoader/Version 2 Design Specification

Is it correct to say that it's our goal to ensure that we have a pretty clean flow from getting your feet wet by writing a user script, to implementing a proper gadget, to getting that gadget officially accepted and possibly even activated by default?

If so, are there elements of the current permission model and workflow which present potential for friction?

More specifically:

• If I'm not mistaken, MediaWiki: namespace edit permission is managed through the 'editinterface' permission, which in Wikimedia wikis is only given to users with sysops-or-higher access privileges. Would this present a barrier for a non-sysop developer to prepare their gadget for proper i18n? If so, how could we reduce that barrier?

• With the current permission model, it looks like higher permission users (gadgetmanagers) have to perform work on behalf of lower permission users (gadgetauthors). Alternatively, might it make sense to enable some kind of gadget submission workflow where a gadget author can use all the same forms that a gadget manager can, but not activate the gadget (except perhaps for personal testing purposes)? This would mean that a gadget author could successfully take a gadget very close to activation, awaiting only review and acceptance by a gadget manager.

If we can build a workflow that makes it easy to do the Right Thing without jumping through hoops or obtaining extra permissions, it seems likely that we can get more casual user script authors to adapt their scripts to best practices and publish them through a shared repository.

Re 1, yes, that would be a barrier. It would be pretty hard to separate gadget messages from regular messages though. I'll ask Timo to share his thoughts on that.

Re 2, yes, I agree that we need that. From a backend perspective, hiding the gadget from all but a few users and disallowing a certain group to create gadgets that aren't hidden in that way wouldn't be hard. As for the frontend / user-observed workflow perspective, I once again defer to Timo.

I'll answer your points while at the same time writing some extra documentation that hasn't been described much so far (feel free anyone to re-use this on a documentation page)

---

One of the goals I had in the ResourceLoader 2 project (or rather "Gadgets 2.0 - made possible by a few ResourceLoader improvements" as Roan and I have been calling it lately).. is to improve the user's workflow in general (in addition to just the technical aspect).

Technical aspect being the efficient loading through ResourceLoader, proper dependency support, localization and what not. Although I think the technical aspect is the main focus and main motivation for the project, the user workflow definitely needs improvements and I took some of them into account when writing the specification.

The main change in the workflow is to branch off two very important abilities away from the "sysop" user group (aka "Wiki page/ wiki user administrator"). Note that no actual user rights are removed from the "sysop" user group (neither were they ever added in the past), they were simply implied by the fact that everything was controlled from MediaWiki-namespace pages. Any gadget guru sysop is free to join one or both of these new groups as soon as we're live.

• The first ability to be available independently from sysops is the ability to maintain gadgets. This was annoying so far because, like you say, the gadget resources are stored in a pseudo-namespace prefixed by "Gadget-" inside the actual MediaWiki-namespace, which is (and should) be restricted to translators and sysops. This made it impossible for anyone expert and trusted with JavaScript to easily help out. Often leading to pending "{{editprotected}}" messages on MediaWiki_talk-pages by users requesting that a sysop copies and pastes the latest version from page X.
  • This is now solved by having gadget resources live in their own "Gadget"-namespace. Among many advantages is that they can be easily filtered in Special:RecentChanges (What changes were made to gadgets recently), as well as the ability to grant users access to it (users that know JavaScript) without them having to be super well known by the community and becoming a "sysop" and all.
  • A new user group "Gadget authors" was introduced which grants the gadgets-edit user right (=ability to edit in NS_GADGET)

• The second ability is the ability to manage gadgets. Meaning that a set of js/css pages in NS_GADGET will be available as a bundle in everybody's preferences. As well as the ability to enable something by default (which is not something a developer should be needed for). This is improved/made possible by two things.
  • Special:Gadgets (Gadget manager): The management of gadgets is now much more intuitive and doesn't require any knowledge of some obscure syntax.
  • A new user group "Gadget managers" was introduced which grants the gadget-definition-* rights. This is what grants users the right to use the Gadget manager.

Note that the "Gadget authors" and "Gadget managers" user groups don't actually exist by default, they're commented-out examples when installing the Gadgets extension. Any wiki is free to configure this in any way they like. For instance, WMF may chose not to have "Gadget managers" and instead grant those rights to the "sysop" user group (Introducing only "Gadget authors" as a new user group). Of course separate user rights and groups can still be configured on a per-wiki base would a wiki wish to have a separate "Gadget managers" user group.

Also note that although a Gadget author is not able to enable a gadget by default, there is no difference between editing a JavaScript-page of a gadget that is or isn't enabled by default. So any Gadget author is therefor able to modify scripts that affect all users including anonymous users (assuming there is at least one gadget set to be enabled by default). This is why we shouldn't put the bar for Gadget authors too low. In order to attract new developers the bar should not be too high either. Previously the bar was being a sysop, so I'd say it's a significant improvement already.

If a Gadget author wishes to develop/test a gadget, they would previously do this on a subpage of their user page (i.e. User:Example/Gadget-Foobar.js). This made collaboration hard (since nobody else is allowed to edit that user subpage), as well as sharing. By having them in the Gadgets namespace one can create a set of JS pages that any Gadget author can improve and collaborate on, without it having to be an officially defined "Gadget". Anyone who wants to use this experimental bundle of JS-pages can put "importScript('Gadget:Foobar.js'); in their personal javascript.

Last but not least, development by users who have not been granted any non-default user rights. There hasn't been much improvement on that part, I do believe progress should take place in that area in the long term. However I believe right now it's more important that we finalize the existing (already fairly large) specification of ResourceLoader 2 and get it out there. And reserve the other workflow feature ideas for Gadgets 3.0, after we have experienced how Gadgets 2.0 is going to be used by the community.

The current workflow for "personal scripts" (or "potential gadgets") by users who are not Gadget authors or sysops works fairly well. They can still create as many js-subpages under their user page as they like, and have other users importScript these etc. Although these would not be loaded by ResourceLoader, the ResourceLoader library and functionality will be available there (in that they can use mw.loader.load, mw.loader.using, mw.messages.set, mw.msg, mw.html*, jQuery, jQuery UI etc. in their user subpage scripts just as if it were a Gadget in the Gadget namespace)

-- Krinkle

PS: For anyone using this for documentation, this post is not a summary of features new in ResourceLoader 2. There are many new features not even mentioned here at all. See RL/V2SPEC.

Makes sense. So I'm trying to figure out what group permission model would mean for a potential production deployment configuration on WMF sites.

It sounds like it would be simplest to create a 'gadget-developer' group which has all the permissions needed to develop gadgets, including

• editing definitions
• editing gadget source code
• editing interface messages (!).

This group would need to be highly trusted as, like you say, they'd be able to manipulate JS that gets run by default. For that reason, I don't think it makes a ton of sense to practically distinguish definition maintenance from code maintenance from interface message edits -- all of these are potentially highly destructive actions that should only be performed by trusted individuals. So you need to be familiar with policies/practices before you get those rights.

An evolving security model would allow us to lower the barrier over time, but for starters, we could give users with an established track record as gadget devs permission to do centralized gadget development work on MediaWiki.org (as a repo serving all projects), and keep gadget-related permissions limited to admins on all other wikis. That way, we don't introduce complex new roles all over the place: The only new role we're creating is that of a gadget-developer on MediaWiki.org to centralize gadget development by trusted users without confusingly making them all sysops.

Does that sound sensible? If so, that's the security model that I think we should build out in Labs, to demonstrate these concepts in an environment that resembles the targeted production deployment as much as possible.

Sounds good :)

Initially I wanted to separate the definition and development. I still think that is a good idea, however not the way I proposed it. Because it would've only introduced a burdon for developers by having to go through extra bureaucracy with users that likely don't understand it as good as they do. It also didn't make sense since it would allow them to unconditionally edit both existing gadgets and inexistant gadgets but can't define new gadgets (from a security POV, not helpful since harm could simply be done through an existing gadget). Anyway, we agree :)

The "Gadget developers" group makes sense, except for one detail though. It would not be a new group only on MediaWiki.org, but on all wikis. The gadget manager is for managing gadgets in general (replacing MediaWiki:Gadgets-definition), the only new thing is (aside from the visual difference), that wikis marked as "repo" wikis (MediaWiki.org in case of WMF) will have an option in the gadget manager to make them globally available.

Gadgets still need to be editable on local wikis, and after upgrading the Gadgets extension they will no longer be in the MediaWiki-namespace, and as such no longer by editable by a sysop through the 'editinterface' user right.

By default the Gadgets extension doesn't grant any user the "gadget-edit" and "gadget-definition-*" rights. So either

• Grant them to sysops on WMF (on wikis other than MediaWiki.org). That way no right changes are visible, sysops are still the only ones able to edit them. And on MediaWiki.org create the "Gadget developer" user group for it instead.
• Grant them to a new "Gadget developer" user group on all WMF wikis, this means until bureaucrats add users to it on a wiki, gadgets will be temporarily uneditable by local users (however the global WMF user group for gadget developers (currently has global right 'editinterface') will likely be expanded with the new gadget rights, so they will be able to help out on any wikis that don't have local gadget developers.

Either is fine by me, I have no preference.

Yeah, I understand the gadget manger would be available everywhere, sorry for being unclear. With regard to the permissions rollup, I was arguing for the first of the two scenarios you mention, to keep things simple for now.

Wow Krinkle, this looks like an awesome improvement. I have a couple questions. Will the new group created for this include the rights for managing tags (which would be very useful for some gadgets to use tags instead of taking up half the edit summary to indicate a gadget/tools was used)? Can access to this usergroup be a vetted process? I'm guessing the answer to that will be more of a "local" wiki choice than a global thing. Which leads me to a question of whether or not there will be a global-gadgetX usergroup for people who are interested an willing to help with maintaining gadgets on sites that may not have their own js/gadget personnel or even capable/willing administrators to take care of that stuff?

As far as I can see, the issue with i18n and lots of expected edit requests (one edit request per message per language!) is neither solved nor answered.

Maybe it would be possible to integrate the i18n of gadgets with translatewiki:?