Maybe it's time for a "crates-team"?


#1

I wrote a blog post about that topic and would love to get some discussion going on the subject.


Would you like to maintain `uuid`?
Towards a More Integrated Rust Community
(Wrong) Direction of rust
Are Rust crates secure?
Bus Factor +1 for crates
#2

FWIW the GitHub https://github.com/rust-unofficial org exists to maintain abandoned crates and other projects.

Also, the libs team is in charge of the crates.io ecosystem as well (e.g. the libz blitz last year was focused on this)

We should increase awareness of rust-unofficial.


#3

Yes, we definitively have to increase awareness. There are no people listed there, the rust-lang.org website does not list this organization (which would be contrary to the “unofficial” thing, though would be really helpful I guess) and there is not even one crate there, yet.


#4

rust-unofficial has the downside of that it says that abandoned crates are parked there. I want to have crates marked as eligible for community adoption or maintenance, without abandoning them.

It would be great to have a crates-team as fallback maintainership that you can trust, or that at least someone has the possibility of picking up critical issues.

I would like to add a rule that such a crate is wholesale put on adoption if the original maintainers are missing for a set period of time (for example 12 months), and the original maintainers can opt in to a shorter time.


#5

I don’t mind expanding its scope to do this.

We could also have a group of users who you can liberally add as GitHub collaborators and crate owners who undertake this migration when necessary.


#6

@kinggoesgaming asked in this thread who would maintain such an organization.

I would love to get involved in such a thing! Although, before starting on such a thing, we have to discuss. I wrote this blog article also because I will be gone from may 2018 until feb/march 2019 - the reason why I am thinking about the whole subject. Hence, I will only be there for ~3 months for such an organization and thus might not be the ideal lead.

We should get in touch with the community team and ask what they think about the subject.


#7

I’d love to be a part of this, sounds like a great idea


#8

Should we try to create orgs around themes of crates rather than a central dumping ground?

The value I see in this is

  • By having other crates related to a maintainers crate in theme, it’d be easier for them to help support. Yes, they could still do that in a dumping ground org but it’ll be hard for them to identify those relevant crates
  • Cohesive goal, standards, and documentation for the org
  • Less overwhelming than rust-unofficial having hundreds of crates

For example, I think there could be value in a crate-ci org.

The challenge is that it will be difficult to find appropriate themes a priori to organize around. We could leave dump those in rust-unofficial until someone proposes a better home.


#9

If this idea takes off, I’d be interested in participating.


#10

I had some thoughts on this topic recently. I totally agree with the principle of sharing maintenance burdens to fight off burnout (I think a sense of loneliness can be a big driver there). Having a group of people maintaining a group of crates could help justify ‘heavier’ tools that help manage maintenance like buildbots and regular triages for smaller crates. We could also focus on making those tools easier to set up (there are a lot of moving parts in configuring an Org + Gitter + Travis + AppVeyor + Bors + Contributing.md + Code_Of_Conduct.md + issue/PR templates).

Something I’m not so keen on personally is limiting maintainer’s ownership over the crates being maintained to just ‘keeping the lights on’. I wouldn’t want to manage issues and PRs on a library if I didn’t also have the freedom to drive it in a particular direction.

So I’m 104% on board with giving more people more permission to triage/develop/release libraries, and whether that takes the form of a single organisation or many is maybe just an implementation detail. That’s why I like the point @matthieum made on reddit about focusing on transitioning crates.

I spent a long time churning this reply, much more conversation is needed but want to see these ideas move forward :slight_smile:


#11

We should at least have a place - like a thread in this form - where people can list an abandoned crate that they are using and wish to have someone maintain it.


#12

Is it possible to publish a guideline on the creation of crates? The idea would be to start a crate with a group of individuals by default.

The status quo appears to be:

  1. I want to perform a certain function.
  2. I look around and see that there’s a small project that is sortof related to what I want to do, but the crate is ad hoc and would require some work to adapt to my use case. Also, the documentation is sparse for this crate.
  3. Deciding that I can save effort by just starting from scratch, I do so, creating a new, similar crate for my ad hoc purpose with sparse documentation.

See the problem there?

Instead.

  1. I need to perform a certain function.
  2. I start an RFC that gets sent to everyone one signed up to receive notifications on the tags I use to mark my RFC.
  3. A discussion starts as to which existing crate will suit my needs, how to implement the needed additions, or, perhaps, that a new crate is truly required.
  4. The work starts as a group of contributors, making it fast and efficient to implement, and the documentation is updated accordingly.

Isn’t the second case much more useful?


#13

Also related:


#14

https://github.com/rust-lang-nursery/api-guidelines


#15

I scanned through it. So the suggestion is to add the crate RFC process to that api-guidelines document? How is following of this guideline then incentivised?


#16

We don’t want to limit crates to a group of people saying these are “recommended”. Instead we want more people to write idiomatic crates.

Also it is difficult to 1 crate to satisfy most needs and you often need multiple crates that perform the same task but have different features.