-
-
Notifications
You must be signed in to change notification settings - Fork 15
Are there maintainers? #43
Comments
related #35 There was a contribution on the 8th of Oct so I'm guessing @svartalf is alive 😅 🙏 It would certainly be advisable to get some other maintainers on board both to keep things moving when other maintainers get busy and to avoid the dreaded bus-factor If not then maybe some of these need to be forked into their parent projects e.g. cargo-audit to rustsec etc. But that will negatively impact the cross-pollination of GH Actions related improvements and |
I agree that but we need to ask @svartalf that idea and please him configure repositories.
so I think it prefers for current situation (for just some critical product of this organization.) In this case, I think the forked repository should follow policies like:
How do you think. |
It seems @svartalf is still active. He has left some review comments in this PR: |
The key questions are whether the current maintainer(s) have interest in continuing with the project, and if not, is there someone that the ownership could be transferred to. |
check out svartalf's comment: actions-rs/cargo#59 (comment) |
In this comment, they say they cannot trust third parties for adding new maintainers. What about asking the Rust team to send some maintainers here? |
Hello. I am speaking as merely an individual and my remarks should not be considered an official stance from the Rust project or anything like that. However, it is my opinion that the Rust project and its membership, while trustworthy, is not "magically" trustworthy. To be precise, there are good reasons to trust in Rust, but these reasons do not come from a magical aura that permeates every individual merely upon becoming a team member. To "send over a few maintainers" would risk removing the feedback loops that create that trustworthiness (such as a lot of eyes keeping watch on each other, a lot of people with different use-cases hashing things out from many angles, and so on). And the Rust project has precious little authority to simply dispatch marching orders to a team member to take over a project, as Rust is not a company. Instead, someone would elect themselves to do so. Neither does that mean svartalf would suddenly assent, either. Much as Rust team members are not employees of the project, neither are we your bosses, and so we would have no especial authority to demand svartalf complies. Nor would I want to, at least. I hope that would be true for the rest of us. |
I agree with this entirely. Thank you for contributing your personal perspective on it @workingjubilee . We can create a community of trust here on our own without having an official sign off from the rust-lang maintainers. Obviously, they are not a large team and getting them involved in signing off on every community action would not scale. With that understanding, I would like to reach out to encourage @svartalf to consider delegating some of the responsibility on maintenance for these actions to the community because there is a lot here to handle as one person, especially in your spare time. Is there anything we, as users of these actions can do to help build your trust in our contributions @svartalf ? Or should we proceed with forking the actions when necessary, as you've suggested in your comments elsewhere? |
Note
Sorry, it's not a feature request or a bug report.
It is just for a meta-discussion topic.
Checklists
Do the checklist before filing an issue:
actions-rs
Actions?If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
Motivation
actions-rs
organization's GithubActions are very famous for rustaceans.Workflow example
no workflow. maybe we need to discuss how to help maintainers.
Additional context
No additional context.
The text was updated successfully, but these errors were encountered: