Thread:Talk:ResourceLoader/V2 testing/Questions about permission model and developer workflow/reply (3)

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.