Proposal: Create a "Stylo Maintainers" team

Motivation

We have previously discussed wanting to diffuse responsibility for maintainership so that:

• We can reduce the burden on the core set of maintainers who currently need to maintain a very large set of crates.
• We can expand the set of maintainers without expanding the number of people who permissions to do absolutely everything (which is problematic from a security perspective). Indeed, by setting up a number of teams like this, we would likely be able to actually reduce the set of people with "everything" permissions.

This would make it clear to new contributors who is responsible for this section of our codebase. And would also support a regular publishing schedule for the crates.io versions of the crate.

Responsibilities

• Reviewing and merging pull requests
• Keeping Servo version of Stylo in sync with Gecko version
• Releasing new crate versions

Publishing permissions

The Stylo Maintainers team should be formalised as a Github team within the Servo organisation. This team should be given publishing permissions over the "crates in scope" below. This will allow any set of two members of the team to publish the "stylo" set of crates (the second member being required for the Github code review for the version bump).

Optionally: servo/stylo github repo admin permissions

Ideally every member of the team should also have the permissions necessary to perform a "sync" from Gecko's to Servo's copy of Stylo. This implies the ability to force push to the main branch. However, as we want protection from accidental "force push to main" even for people who should have the permission to do so, the current setup is that force push is generally forbidden for everyone. But repo admins can temporarily disable that permission, force push, and then turn the protection back on again. Therefore it would be better to give the team admin permissions over the servo/stylo repo. Admin permissions would not be required for the servo/rust-cssparser repo as there is no force-push based workflow there.

I'm anticipating this being controversial, so I will in advance say that the rest of this proposal could be accepted without this provision. But I'm putting it in here, because I still think this is what we ought to do. A work around is that the maintainer can create

Crates in scope

From the servo/stylo repo:

• stylo
• selectors
• stylo_traits
• stylo_derive
• stylo_dom
• stylo_atoms
• stylo_config
• stylo_static_prefs
• stylo_malloc_size_of
• to_shmem
• to_shmem_derive
• servo_arc

From the servo/rust-cssparser repo:

• cssparser
• cssparser-color
• cssparser-macros

From the servo/app_units repo:

• app_units

This is intended to represent a related set of crates that form a informal "module" of related functionality. And also the set of crates that Stylo depends on and may need to be published as part of Stylo crates.io release.

Proposed initial membership

• Emilio Cobos Álvarez (@emilio)
• Martin Robinson (@mrobinson)
• Oriol Brufau (@Loirooriol)
• Nico Burns (@nicoburns)

This is intended to represent the group of people involved with the Servo project who are already the de facto maintainers of Stylo.

Start by reviewing the proposed responsibilities, membership, and permission model in issue #137, then inspect the GitHub organization settings for the servo/stylo, servo/rust-cssparser, and servo/app_units repositories. Confirm the publishing scope for the listed crates and resolve whether repository admin permissions are included. Done means the Stylo Maintainers team is created with agreed members and permissions.