After reading another post in the users.rust-lang.org forum where a crate author is looking for a maintainer for his crate, I started thinking. Do we need a “crates-team” in the rust community?

Incentive

The Rust community has a lot of great teams. Each of these teams has a different goal: The Core team, for example

is responsible for steering the design and development process, overseeing the introduction of new features, and ultimately making decisions for which there is no consensus [...]

(source)

Because people change, interests of people change and also because the life-situations people are in change, a crate author might not be able to continue maintaining their crates. I, for one, have such a problem: I am about to go on a really long vacation from may 2018 until early 2019. Most of that time I will be off the grid, in a mobile home in northern America. This is a one-time opportunity for me and I am really looking forward to that experience. But because of that I will have issues maintaining my crates in that time. I have 7 projects where I cannot continue development for about one year:

• toml-query
• filters
• kairos
• task-hookrs
• git-dit (and libgitdit)
• is-match

and of course imag, which contains over 40 crates at the time of writing. All of the above are ready to be used (imag is not) and are, in fact, used by others from what I know.

In my case, this is only temporarily: I will be able (and am willing to) continue development on them in 2019. But people change, interests change, people get kids, a dog or some new hobby. The end result is always: They have less time (or no time anymore) to continue developing their crates.

So why not have a team available which takes over maintainership?

What a crates-team would do

The crates-team won't always be able to continue development of the crate, but it might be able to continue maintainership. That is: Merge pull requests which add new functionality (or even just discuss whether this new functionality would be a nice addition to the crate), update the dependencies from time to time, fix and close bugs in the codebase, update the documentation and document known bugs.

The team would consist of people from the community (so basically hobbyists) which are willing to maintain a few crates in their free time. The crates-team would, of course, not take over maintainership for all abandoned crates. It would rather discuss whether a crate shall be maintained by them and then do so (or not).

Some ideas on basic rules for the team:

• Only the following things are in the scope of “maintaining” a crate in the crates-team:
  • Update the dependencies to the newest version if and only if updating to the newest version is as simple as updating the version number in the Cargo.toml file. If it is more complicated, the crates-team is allowed to reject any requests or reply to such requests with a variant of the phrase “You're welcome to file an PR for this!”
  • Updating the documentation of a crate
  • Publish new versions of the crate, the first newly published version should change the cargo metainformation maintenance = ... to passively-maintained.
  • Discuss and (if consensus is reached) merge pull requests which add new functionality to the crate
  • Merge pull requests which
    • Fix bugs
    • Update dependencies
    • Update documentation
• A crate only gets maintained if at least 2 members of the crates-team are willing to maintain the crate (these two get rights to publish new versions)

More rules are possible, of course.

Discussion

I'd love to discuss the subject on either users.rust-lang.org or reddit!

Also, feel free to reach out via mail (the thing which looks like an 'a') (thisdomain) (dot) de.

tags: #tools #software #rust #open-source