Deprecate the "Maintainer" role

[di]

What's the problem this feature will solve?
Currently, PyPI has two "collaborator" roles:

• "Owners" can do anything they want to a project
• "Maintainers" can only upload new releases.

In #12643, we had a request to increase the set of things the "Maintainer" role can do: namely, yank releases.

While this is a reasonable request and seems to make sense given the "Maintainer"'s current abilities, I'm not sure we should do it. Many project owners have added "Maintainer" roles to their projects assuming that this role only has the ability to publish releases. Applying new abilities broadly to this role would probably be unexpected in most cases and may be undesired in some.

Describe the solution you'd like
Given that we now have new ways to publish without using username/password-based authentication (API Tokens, Trusted Publishing via OIDC) a restricted role like the Maintainer role is less useful or necessary than it used to be.

The permissions model and names of the "Owner" and "Maintainer" roles have always been confusing as well, as "Maintainer" usually is interpreted to mean someone who has the ability to fully maintain the project.

Instead of continuing to support the maintainer role, we should do the following:

• Retain all current "Maintainer" roles (we don't want to break any workflows)
• Deprecate/remove the ability to create new "Maintainer" roles
• Direct users to API tokens / OIDC instead of creating new "Maintainer" roles
• Rename "Maintainer" to "Uploader"
• Possibly split "Owner" into "Collaborator" and "Administrator"
  • All "Owners" would become "Administrators", and "Collaborators" would be a new role that can do non-destructive things to a project, satisfying the original request in Allow a project "Maintainer" to yank a release. #12643.

Additional context
An alternative would be providing a more granular permissions model (e.g. "Maintainers" that can/can't yank a release, and being able to toggle these permissions) but I think this would likely introduce more confusion/complexity than necessary.

[woodruffw]

This is in scope under the maintenance work that the STF has funded Trail of Bits to do on Warehouse!

cc @tnytown

[dstufft]

I worry that the shuffle from Maintainer to Collaborator is a lot of churn for little value.

The underlying problem with "just" adding the ability to yank to the Maintainer role is that the Maintainer role is specifically a limited access role, and we're suddenly increasing the scope of what they are able to do. I don't believe that problem gets better by deprecating the Maintainer role and adding a new Collaborator role, at least long term. If we add another feature that the new Collaborators may want to use, we're effectively in the same spot as we are today-- we have a limited access role where we want to expand the scope of what it can do.

Or to put another way, why do we think that it will be OK to expand the scope of Collaborator in the future, but not OK to expand the scope of Maintainer now?

As far as renaming to Administrator and Collaborator, that's fine with me. I'm honestly also fine just deprecating Maintainer all together and saying the only thing you get is Owner (under some name). It just feels weird to have one limited access role exchanged for another, when I don't think it actually solved the underlying problem of expanding permission scope.

[woodruffw]

As far as renaming to Administrator and Collaborator, that's fine with me. I'm honestly also fine just deprecating Maintainer all together and saying the only thing you get is Owner (under some name). It just feels weird to have one limited access role exchanged for another, when I don't think it actually solved the underlying problem of expanding permission scope.

Deprecating "Maintainer" entirely and having a single role would be my first intuition here, for the same reasons: IMO any scope other than "controls the project" is going to be blurry and subject to the same future pressures on expanding/shrinking access.

For some prior art:

• NPM appears to only have one role in this context (they have multiple roles in an org context, which makes sense), which they call "Maintainer" and is equivalent to PyPI's "Owner" role
• RubyGems only has one role, which it calls "Owners" like PyPI
• Crates (Rust) only has one role, which it calls "Owners" as well

[sethmlarson]

I'm in agreement that the Maintainer role should be reduced or removed long-term, especially with the vision of privileges around publishing living external to PyPI via Trusted Publishers. See: #14300