-
Notifications
You must be signed in to change notification settings - Fork 640
Ability to invite teams that you're not a member of #1366
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
You can definitely add teams as owners... what gave you the impression that you can't? |
Here are the docs for owners, which includes how to add a team as an owner: https://doc.rust-lang.org/cargo/reference/publishing.html#cargo-owner |
Worth noting that adding this option would just bring back the same bus factor problem. If I add my-buddy as a collaborator but not an owner, and then I disappear, now they can publish new versions, but they can't add or remove other collaborators, so if they disappear the crate is now dead with no resolution |
@carols10cents AFAIK teams can be added to crates by team's admins, but teams can't be invited to own other crates by people who are not team admins. |
@kornelski That's fairly important from an anti-abuse point of view. A Github team is not an entity we can easily get permission to be added for, there's no email address we can associate with it. |
Of course I'm not suggesting adding without confirmation. That has been awfully abused on GitHub. However, maybe the existing team members logged in to crates.io could approve? |
To clarify a bit, this aligns with the current distinction between owners and teams. Individual users are treated as owners and have full control over the crate. When a team is added, the team members have publish/yank permission but are not able to add/remove owners. (At least, this is my understanding of the code, I haven't tested this locally.) So if a crate has 1 owner and 1 team, and the owner goes MIA, then the bus factor effectively aligns with the bus factor for managing the org/team on GitHub. It's no longer possible to add/remove owners/teams to the crate, but at least publish/yank permissions can still be managed via the team. It might be possible to treat org/team admins as crate owners, but I think that is more complexity than it is worth and may result in user confusion over exactly how permissions are handled (and thus is probably RFC territory). |
Would it be possible to have permission levels for individuals? i.e. ability to add individuals as either a co-owner or as a collaborator only? The collaborator would have ability to make releases, but not add nor remove other owners/collaborators. That's how it works on GitHub. |
I think that would be possible, but probably not easy at the moment. Just from a UI perspective, this would also have to land in The workaround for now is to create a team, but that's not particularly convenient if you don't already have a org. |
There are actually two features being requested in this issue, which confused me. I've updated the title again to make this issue about adding the ability to invite teams that you're not a member of. The ability to add individuals who can only publish but not change owners is actually a duplicate of #48. |
@kornelski I believe another way of solving this is to mention rust bus in one of crates.io page, or maybe the page to upload crates like @Darksonn mentioned 2 years ago. https://users.rust-lang.org/t/bus-factor-1-for-crates/17046/66?u=pickfire |
I think #48 will work for rust-bus better. Ability to add new owners, but not remove any existing ones, is actually more useful. |
Lots of crates have only a single person who is allowed to publish any updates. This is a huge responsibility and pressure on the sole maintainers. It's also a risk for crate users, since the crates may require security or compatibility fixes, but the maintainers can't be relied on (despite best efforts they can't be expected to maintain crates 24/7 — forever). Forking of abandoned crates is not a good solution. It's a messy process that still requires chasing maintainers of dependent crates, who may also be unavailable. And then the forks with sole owners are still a single point of failure.
To avoid the Bus Factor = 1 problem (discussion) I would like to encourage crate authors to allow other people to publish their crates. They could add other people as "backup" owners, who could act in case the original owner disappears.
Current ownership features on crates.io could be improved for this use-case:
Ideally, there should be a group of trusted volunteers who could be invited as "backup" admins of crates. Unfortunately, GitHub teams can't be invited by non-team-members on crates.io.
Adding individual people as owners gives power to kick out the original owner. That requires a lot of trust. It would be easier to add other people if crates.io allowed adding people as collaborators with only publish/yank permission.
What do you think about implementing either of these features?
The text was updated successfully, but these errors were encountered: