Bus Factor +1 for crates

Yes, this is a problem. I’ve made a feature request to allow inviting teams, so that non-members can add them:

there should be a group of trusted volunteers

You emphasized “group”, while I’m more worried about “trusted” :wink: Especially with the current “message me and I’ll add you” approach.

  • I verify who asks to be added and accept only people who have been in the community for a while.
  • The feature request I’ve linked to will eliminate the need to add users to the GitHub group, since they will be able to give ownership of crates without belonging to the group.

(I might be off topic here, but it’s related to abandoned crates, so hopefully not too off-topic)

Could there possibly be a distinction between abandoned crate and finished crate?

crates.io just shows the last updated time, but sometimes there’s simply nothing the author can add and it becomes difficult to assess the usability of the crate.

Would be nice if there’s a “pulse” signal or “heartbeat” that the author or the group can can trigger to essentially say “Yep the crate is still being looked after, just nothing to do atm, that’s all”.


crates.io supports badges for specifying maintenance status of a crate: https://github.com/rust-lang/crates.io/issues/704


Trust is definitely tricky. I think for this to work it needs to be wholly clear and transparent about what its goals are and who’s involved.

I would favour a separate organisation whenever possible like we did with uuid, with the bus factor team having permissions on crates.io and a separate team having ownership of the repository in its organisation.

There’s a bit of a difference in approach between centralising maintainership under a single umbrella organisation, and distributing it amongst disparate teams. I’m in favour of decentralisation here.

It doesn’t necessarily need to factor in to this at all though if it’s only concerned with being able to push a fork to crates.io under the same name. That’s where I think the question what does it mean for the bus factor team to share ownership over a crate? matters.


It is a tradeoff. Centralised organisations brings about reputation and trust though. For example you are more likely to use a crate from rust-nursery or serde than some random user.

In Github org, you can create teams and assign only those members to certain repos.

Though i’m fine with either approach.

It might be a good idea for everyone in the org to set their visibility to “public” instead of the default “private” so everyone can see who’s involved and who would get access to their crates. For members, you can do that at https://github.com/orgs/rust-bus/people.


Thanks for pointing that out. Have changed it for my profile :slight_smile:

@kornel do check: iron out of maintenance. A big project though but probably a good repo to start the bus with

Iron has an org with 7 people, so I think they’re covered.

Yeah I know but they can’t maintain it any more

Anyone wants to co-maintain sodiumoxide crate? You can reply here or DM me or on gitter and will follow up with you.


What is the difference between cargo owner --add rust-bus-owner and cargo owner --add github:rust-bus:maintainers? The latter fails for me.

The second command is listed as primary command (for example, in Github’s org description), and I hesitate about the first command because of it may add a regular owner, not less privileged group owner like Rust Bus is supposed to be as far as I know.

If I indeed need to use the first command, maybe it should be advertised more than the second?

Shall there be a Github README.md badge for repositories opted into the Rust Bus program?

Please use cargo owner --add rust-bus-owner. We’ve tried the other command first, but as you’ve found out, it doesn’t work for everyone. I’ve updated the org description.

The rust-bus user is visible on crates.io crate pages. I think that’s enough, but feel free to add a badge to your repos if you like.

Added rust-bus-owner for two crates, but only the first got through. Some bot hit API limits? Or is it manually approved?

Crates.io requires them to be approved manually. I’ve added the second one too.

What about an organization for the purpose of squatting crates? Since crates.io doesn’t have any formal way to release squatted crates for others to claim, we could have an organization whose purpose is to hold squatted crates so that other people could apply for those crate names for their own crates.

Additionally, we could preemptively start squatting any good unclaimed crate names, to prevent anyone from maliciously squatting them which is a problem that crates.io still doesn’t want to clamp down on.

I have around 400 -sys creates that I no longer want due to changing the organization of winapi, so I’d be happy to take the charge on something like this.

1 Like