-
Notifications
You must be signed in to change notification settings - Fork 453
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Looking for maintainers! #682
Comments
#602 certainly looks interesting to me! I'll have to find time to read through the code and see if I'm equipped to help here 😁 |
I would be willing to try. |
I'm keen. |
I'm interested |
I would love to |
I'm willing to help out somewhat, if you'd like more people involved. |
As someone who uses this 8-12 hours a day, I feel obliged to help out :) |
Super happy to see that so many has shown an interest in contributing! As @sirwindfield said, none of us have been able to dedicate the time that this project needs/deserves for some time now. How do we proceed, practically? Should we just add everyone who has shown an interest here to the organisation? |
The only two options I have in my mind are these:
If we set up the branch as protected I'd just go for option 1. We have enough people that showed interest which would result in enough review candidates. Edit: We still need to add people to crates.io. It's possible to give whole GitHub teams publish rights, so we either re-use the team from option 1 or create a new one called publishers and just add a handful to it. Having publishing rights means being responsible for working and correct deployments. So if some people do not want to deal with that, a separate team would be the better approach. What do you think @simonpersson? Does option 1 sound good to you? |
@sirwindfield - option 1 sounds fine to me. Will you set it up? |
Will do so today! |
@Plecra I've added you all to the @Spotifyd/maintainers team. |
How do we communicate with each other? |
I've created a backup branch Communication can be done inside the team view: https://github.com/orgs/Spotifyd/teams/maintainers. You should see a box where you can start a discussion :) The current branch restrictions enforces 2 reviewers per PR. I think that this should be enough. If, over time, it becomes clear that the number is too high, we can reduce it to 1 I guess. |
I will keep the issue open for some more days, maybe we're able to find some more people that want to get involved :) Thanks for helping us out with the project. It definitely deserves more love than we put into it lately. |
Hi, I'd like to help out! :) |
I'm getting a 404 when I click through to it. |
I'd like to help! |
@al-jshen and @notashutosh - I've sent you invites to the team. @Ben-PH - what link is not working for you? |
I'd like to contribute/help as well. |
Would love to help! I use this project for hours a day as well. |
Sure thing! Just for later reference, if you are one of those individuals that wants to contribute to the project your't need to be in the maintaining team to do so. Resolving issues, maybe asking for the progress on ones that have already been started and peer-reviewing PRs (commenting or starting a discussion on the implementation details) can also be done without push access. Maintainers are mostly responsible for merging and reviews, as well as other meta stuff. Some will probably also try and implement bug fixes or new features. But the size of the projects results in a lot of new issues, duplicate issues that have to be filtered, or even simple support questions that you guys will be responsible to resolve. They're more of the puppeteers who setup the stage properly :) |
@simonpersson got it working |
I want to help too! |
I've been maintaining the crate for some time now. Sadly, I do not have a lot of time left to even review PRs. I spent most of my time that I dedicate to programming on university projects and open source libraries that I happen to use in them. That doesn't leave the time needed to properly review/merge and publish new versions of Spotifyd.
I hope there are some people with Rust knowledge that would be willing to help me out and keep the project up and running. It doesn't (and shouldn't!) be a single person as it is a lot of work. I'd prefer 3+ people. That way, PRs can be properly discussed if the need arises and there will always be one person who can (peer-)review PRs.
If someone is interested, just comment on this issue!
The text was updated successfully, but these errors were encountered: