spotifyd
spotifyd copied to clipboard
Spotifyd
Looking for maintainers!
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!
#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 😁
As someone who uses this 8-12 hours a day, I feel obliged to help out :)
I don't have a ton of time, but I can review PRs, help strategize, and do a bit of coding.
Also, if there isn't one already, a Discord channel would be a good thing to set up.
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:
- Create a new team and add everybody as a member to it. Basically forming some kind of "core" team. Maybe even setting up master as a protected branch so reviews need to happen before merging can be done.
- Those that have interest can start to review and comment on PRs that are ready to be merged. maybe even resolving issues. I'd push the merge button then and we decide later on who we add depending on their activity for example.
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?
@Plecra @marcelbuesing @Ben-PH @MarinPostma @kmilewczyk @slondr @rrichardson
I've added you all to the @Spotifyd/maintainers team.
I've created a backup branch backup_before_maintainers that contains a snapshot of the current repository. No one should have push access to it except for administrators if I set it up correctly. If something goes horribly wrong we can use that to revert it (just in case).
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.
@al-jshen and @notashutosh - I've sent you invites to the team.
@Ben-PH - what link is not working for you?
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 :) That being said, I think a core team of 7 is good enough for the time being. Three requests are pending, so it would be a total of 10 members. @JojiiOfficial and @robinvd would probably be the last persons I'd add to the team. I feel that more would actually negatively impact development during the transitioning time.
