Maintainership Guidelines

[KodrAus]

Let's collect our experiences stabilising and maintaining Rust libraries into some resource that others can use as a source of inspiration and knowledge-sharing.

This could take the format of a detailed book, a curated list of articles, anecdotes... Anything! As a starting point, some topics we might want to discuss could be:

Tactical tools for maintenance:

• Useful bots for managing issues and coordinating changes
• Setting up CI and other useful services, like gitter for chat

More open topical things:

• What's stopping you from stabilising your library?
• What does it mean to trust someone else with the keys to your kingdom?
• How can you deal with feature requests you don't want to support?

I'd love to hear your thoughts on what shape this could take and what it should say! All suggestions, experiences and other feedback are welcome.

[epage]

gitter for chat

+1 for this. I think its crucial to have a clear way to communicate with the maintainers.

• Useful bots for managing issues and coordinating changes
• Setting up CI a

Sounds like this might be related to some of the work I've been doing. I have a goal of reducing maintenance burden and have started crate-ci for this including documentation. I've slowed down my work on it as I've been wanting to get some features out in cobalt and do some development for the CLI-WG though I think there will be some overlap on that latter one with this WG.

[kinggoesgaming]

Dependabot recently added support for rust and can create PRs to update dependencies

[epage]

That looks awesome! Started giving it a try

• Example of upgrading Cargo.toml
• Example of upgrading Cargo.lock

See reddit for more of my thoughts.

[KodrAus]

@epage sorry for taking so long to circle back here! crate-ci looks like an excellent resource. I was hoping that work on moving repositories into new organisations would lead to some nicer tooling around configuring all the moving parts, like CI.

Would it be in scope for the crate-ci book to discuss specific CI providers, like Travis and AppVeyor, and how to set them up for organisations (AppVeyor in particular has surprising behaviour with teams because members have the same visibility to GitHub projects as the account owner)?

[epage]

Would it be in scope for the crate-ci book to discuss specific CI providers, like Travis and AppVeyor, and how to set them up for organisations (AppVeyor in particular has surprising behaviour with teams because members have the same visibility to GitHub projects as the account owner)?

Yes it is. Currently the setup instructions are pretty basic (just around scheduled builds) and the bulk focuses on the CI config files since that is where I assumed the troubles would be but going into more details about gotchas would be helpful.

And yeah, appveyor isn't as straightforward as Travis. I'm usually too lazy to figure it out and just have the project under my name :(