Bolstering community maintenance

[TotalKrill]

I must say that Bevy has one of the best communities. I also believe it can become even better!

I have noticed that most well-used crates are actually getting well maintained as well, but its often the case that they still are only one developer with push-rights to crates, and the only one with merge-rights to github/gitlab. And people are people with limited bandwidth and limited time.

This has sometimes ended up with plugins not being updated to match the latest bevy release in weeks, even with a merge-request submitted and tested by other users.

Sometimes this holds multiple other dependent crates back as well and then it can become a bottleneck.
The only solution I see to this problem is if the original maintainer gets backup. This is sometimes quite scary, because it means inviting others to modify your work. But I believe by having a suggested way and method of requesting help with maintenance work around crates, the prospect would become less threatening, and reduce the burdens of open-sourcing your plugins. Sometimes its just a question about not wanting to think about these issues, mostly because its not interesting to many developers.

I heard of a discussion about "blessed" crates, but I could not find it. So here is my suggestion to lessen the barrier of co-maintainership

Define Concept and Role of a Backup Maintainer

Define a role and title that can be given to persons "Backup Maintainer" for example, this would be a list of rules ( enforced by permissions if applicable ) along the lines of what a backup-maintainer may or may not do, and violation this would mean they would get their permissions revoked.

This could be done by providing a template or similar for this role.

A backup Maintainer May, with permission from main-maintainer, or if no response from main-maintainer within 5 days

• merge pull requests deemed bug fixes
• merge minor "chores" such as update to be compatible with latest bevy, or update dependencies, typos, or add examples
• push such updates to crates.io when necessary

Some way of requesting to become Backup Maintaner, or request looking for a Backup Maintainer

This would be to provide a forum ( probably a discord channel), or providing a defined way of indicating that one would like to either have a backup maintainer, or to become a backup maintainer.

For example, we could prepare a template that people could use to indicate they have read the rules, they want to comply with the rules and they want to help the maintainer with those chores to bolster the community of bevy. This could be in the form of an issue on github, with a guide that would let the main maintainer have this small checklist that potential applicants would have to accept. This could even be a recommended text to the README on the project, or just a link to discord or whatever. As long as it becomes effortless for the main-maintainer, the entire thing is meant to help alleviate some of the tedious work from a main-maintainer of a plugin.

The workflow for the main developer could be like: read section on bevy website, copy template to github/gitlab repo, hope someone wants to help

and the workflow for the potential maintainer could be like: Read bevy website or see issue on github, indicate acceptance of rules, await acceptance from main-dev.

Guidelines in bevy book, readme or similiar

Once these things has been defined, it would need to be communicated that this information is available. It would be best if it was reachable through the main bevy-website, with a short step by step list of how to easily take get help from the amazing bevy community

All of these things are already happening on crates and github repos in general, but i believe that having a framework to start from could massively help reducing the barriers to putting such a framework in place! What do you guys think?

[nicopap]

Rust has an organization called the rust bus which exists for important crates from individual contributors. I could imagine favorably a "bevy bus" (let me rid on it please!) That would be a welcome addition. It's not a fun thing to think about incidents, but it's part of our reality and we need to deal with it. I think a bevy bus formed by very involved community members could be a great addition.

An example of a bevy plugin where a bevy bus would have been useful is bevy_jfa which is now 2 versions out-of-date despite update PRs existing.

The "blessed crate" discussion probably referred to the bevy nursery (you can read more in the link)

For the rest of your post, as you mentioned the bevy community is very co-involved and you often find PRs for new bevy versions before it is out.

You point out some maintainer are a bit slow on the uptake (although I'd say that 1-2 week is an extremely reasonable reaction time to update a crate), and you recommend extending push rights at least for those crates.

It is a very difficult thing to trust third parties with push rights on your repositories. For many reasons: Can they be trusted? Do they have the same code review skill and requirements? Do they understand the scope of the crate? Do they understand what they are allowed to do? Do they follow best security practices? etc. A slip up need to happen once, and the trust of your users is thoughtfully breached! I perfectly understand why someone would be hesitant to add co-maintainers.

I think a model based on the rust bus could have great potential, guidelines and pledges help a lot with trust. Correct me if I'm wrong, but I think the guidelines written in the rust bus post are are refined and more appropriate version of yours, and I would be in favor of adopting a similar organization for bevy.

[TotalKrill]

While I read through the rust bus, it's a nice way of doing things as well.

But the issues you mentioned with trusting a third party, those are what I would like to address primarily. The rust bus solves the issue with abandoned crates. Not with easing the burdens of maintainership.

I wish to bolster ecosystem health, being a maintainer of popular crates can be taxing, by having a clear framework for responsibilities and what a backup-maintainer may or may not do, we can bridge the barrier of that initial trust.

Once bevy reaches 1.0 and there are even more third party crates, I believe a "bevy bus" would make more sense. Currently all of bevy is still dependent on @cart, but he is amazing at building community and scaling the organization around bevy.

Rust bus is more like a will, the backup-maintainer idea is more like helping hand to crates that are well functioning, to keep that functionality in a quick moving ecosystem by introducing parallelism to maintenance.

Thus clearly defined permissions and rules, to avoid affecting a vision of a crate or plugin. But allow keeping up with mainline bevy and bugfixes which would otherwise add up is what I am proposing.