Skip to content
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

[Repo status] Could you give write access to some contributors? #552

Open
Diegovsky opened this issue Oct 15, 2022 · 12 comments
Open

[Repo status] Could you give write access to some contributors? #552

Diegovsky opened this issue Oct 15, 2022 · 12 comments

Comments

@Diegovsky
Copy link
Collaborator

I noticed Spot has been a bit stagnant for a while. I love this app and would love to help maintain it if possible. Also, I have some features I would like to implement, and some more people seem to want that too (at the time of writing, there are 20 pull requests open).

Would you consider giving me and/or other contributors write access to the repo?

@Diegovsky Diegovsky changed the title [Repo status] Could you give write access to some contributos? [Repo status] Could you give write access to some contributors? Oct 24, 2022
@XGZepto
Copy link
Contributor

XGZepto commented Dec 8, 2022

I suppose maybe it's time to fork this repo and start to work from there?

@Diegovsky
Copy link
Collaborator Author

Yup. I unfortunately don't have as much time as I did before so I can't be the onwer. Hopefully the community decides to fork it and focus efforts on the new fork :)

@mstarongithub
Copy link

I'll chime in here as well as I think that this project is quite cool.
Giving Write Access to a few contributors that know what they are doing would probably be better than forking it as both the flatpak and snap version link to this repo

@xou816 xou816 pinned this issue Feb 11, 2023
@xou816
Copy link
Owner

xou816 commented Feb 11, 2023

(message adapted from a comment I submitted on reddit)

Hi there, thanks for reaching out!

Before I forget: thank you all for your support and interest in the project. I am sorry for not properly handling it for... well, a long time now. I know it must be frustating for users, and contributors especially, to be willing to help only to be met with silence -- I hope they won't be discouraged from contributing to open source because of that.

Long story short, I got progressively less motivated, then busy with real life stuff, and, as silly as this might sound, I ended up building up anxiety just opening up Github because of the amount of notifications, PRs and issues that were accumulating, and have been avoiding it as well as all things gnome since then. I guess I was hoping that the project would quietly go away, as it was never meant to be anywhere near as good as the official client.

Some people have been reaching out and I'd like to ensure a better future for the project. If the above didn't make it clear, this was/is my first time handling a semi-popular open-source project, therefore I welcome all kind of advice from people having experience with that.

First, it seems important to open up access to the project or at least allow a fork to take its place. I have been out of the loop so I don't know if there's an active fork that we could direct people to. If there's none, I'd like to identify maintainers to eventually give write access to. I am a bit reluctant to give that kind of access right away, so I'd like to build trust and start by:

  • identifying people that would be interested/motivated in maintaining spot;
  • involving them in reviewing PRs, I think this is important to see if they're comfortable with the project or if there's something to do to help with that;
  • having them contribute maintenance PRs: updating dependencies, translations, etc; sharing this kind of admittedly less fun work would ensure no one burns out on their own;
  • helping with issue triaging (again, not very fun, so better to be shared).

That sounds like a lot, but I don't need willing contributors to do all of that from the get-go, it's just some of the tasks that a longer-term maintainer would have to engage with eventually. Hopefully it makes sense, but I'd love your feedback on that: I feel like I'm being a little too controlling, maybe.

Secondly, it's probably important to take the time to identify both the maintenance burden (is there something that's hard to do in the project?) and the barriers to contribution (does something need to be documented better or at all?) as well. Again, feedback welcome.

As for me, I'd like to be involved again, working at my own pace. The maintenance tasks and reviewing was quite a lot to do on my free time (dependabot can be quite pressuring!), but it was fun still. Fixing stuff (either me or another maintainer) even just once a month is still much, much better than leaving the project in the dust. That's for maintenance tasks; adding in new feature is a lot more work, which requires a greater review effort, and I'm not sure how to handle that just yet. As I have shown not to be super reliable, I'd love to start by being able to give out write access/promote a fork in the near future, to ensure we don't go that way again.

I'm still trying to order my thoughts, I hope it makes at least a bit of sense!

@XGZepto
Copy link
Contributor

XGZepto commented Feb 11, 2023

Good to have you back! Many of us are more than willing to contribute!

@Diegovsky
Copy link
Collaborator Author

Good to know you're back! I can definitely relate to the anxiety of opening up GH and avoiding it. I would love to help in any way I can.

I'm new to contributing to OSS but I can try and review PRs if needed. I'm also fine with helping maintain Spot in some capacity but more like the monthly (or bimonthly) fix like you mentioned because of other stuff.

Welcome back :)

@Newbytee
Copy link

I've never contributed to Spot, but I just wanted to say that I am so happy that you are handling it this way instead of letting the repository rot.

@samsapti
Copy link

As a Spot user, I'm very happy to have you back! I have contributed a decent amount of patches/issues to FOSS in the past, but I don't think I have the time to be a core maintainer unfortunately, as I'm quite busy with real life and studies. But I would love to help out as much as I'm able to.

(Also, I've never coded in Rust before, so I guess this is a good chance for me to finally learn it!)

@xou816
Copy link
Owner

xou816 commented Feb 16, 2023

Hey thank you all for the kind words :) I see some of you are already busy identifying issues, I'll get to them eventually!

@GeorgesStavracas
Copy link

@xou816 hey, I just read your comments here, and thought that maybe - and only maybe - you could benefit from some unsolicited advice from a random internet stranger that happens to have 10+ years of experience maintaining free software. Please feel free to ignore this comment though, badly timed unsolicited advice sucks, and I don't know if this is the appropriate time.

It took me way too long to learn what I think is the most important strat when it comes to maintainership: delegate as much as you can, ask for help as often as you can for as many people you can, and automate yourself out of your projects as quickly as possible.

The quicker you get rid of the boring and annoying parts, the quicker you'll be able to focus on the fun bits, and on what makes you happy.

Seems like there are quite a few people interested in your project; if it was 1-year-ago me in your position, I'd have asked for pull requests, would have tried to review them all to perfection, and would have burned myself out in the process. Today's me would give them access to the repository, ask them to review and merge each other's code, and if something that makes me unhappy lands, I'd just let them know.

If the issues counts starts growing out of control, ask people to help with triage - testing if something is reproducible and closing old / stale / invalid issues is a great and accessible way that non-coding contributors can help.

Please remember that you're still the author of the application, and this is your little internet feud. The vision for the app is yours, and you can accept or reject any contribution purely based on that. Closing feature requests and pull requests that don't align to your vision is fine, even when they're technically correct.

Lastly, I highly encourage free software developers like yourself to create ways to receive money. Patreon, GitHub, Liberapay, whatever is your choice, promote it everywhere. I think free and open software has higher value than proprietary software, and the people working on it deserve a better paycheck than proprietary, corporate developers :)

Again, apologies if this is unwelcomed. I hope it helps. Have fun!

@p134c0d3
Copy link

(message adapted from a comment I submitted on reddit)

Hi there, thanks for reaching out!

Before I forget: thank you all for your support and interest in the project. I am sorry for not properly handling it for... well, a long time now. I know it must be frustating for users, and contributors especially, to be willing to help only to be met with silence -- I hope they won't be discouraged from contributing to open source because of that.

Long story short, I got progressively less motivated, then busy with real life stuff, and, as silly as this might sound, I ended up building up anxiety just opening up Github because of the amount of notifications, PRs and issues that were accumulating, and have been avoiding it as well as all things gnome since then. I guess I was hoping that the project would quietly go away, as it was never meant to be anywhere near as good as the official client.

Some people have been reaching out and I'd like to ensure a better future for the project. If the above didn't make it clear, this was/is my first time handling a semi-popular open-source project, therefore I welcome all kind of advice from people having experience with that.

First, it seems important to open up access to the project or at least allow a fork to take its place. I have been out of the loop so I don't know if there's an active fork that we could direct people to. If there's none, I'd like to identify maintainers to eventually give write access to. I am a bit reluctant to give that kind of access right away, so I'd like to build trust and start by:

  • identifying people that would be interested/motivated in maintaining spot;
  • involving them in reviewing PRs, I think this is important to see if they're comfortable with the project or if there's something to do to help with that;
  • having them contribute maintenance PRs: updating dependencies, translations, etc; sharing this kind of admittedly less fun work would ensure no one burns out on their own;
  • helping with issue triaging (again, not very fun, so better to be shared).

That sounds like a lot, but I don't need willing contributors to do all of that from the get-go, it's just some of the tasks that a longer-term maintainer would have to engage with eventually. Hopefully it makes sense, but I'd love your feedback on that: I feel like I'm being a little too controlling, maybe.

Secondly, it's probably important to take the time to identify both the maintenance burden (is there something that's hard to do in the project?) and the barriers to contribution (does something need to be documented better or at all?) as well. Again, feedback welcome.

As for me, I'd like to be involved again, working at my own pace. The maintenance tasks and reviewing was quite a lot to do on my free time (dependabot can be quite pressuring!), but it was fun still. Fixing stuff (either me or another maintainer) even just once a month is still much, much better than leaving the project in the dust. That's for maintenance tasks; adding in new feature is a lot more work, which requires a greater review effort, and I'm not sure how to handle that just yet. As I have shown not to be super reliable, I'd love to start by being able to give out write access/promote a fork in the near future, to ensure we don't go that way again.

I'm still trying to order my thoughts, I hope it makes at least a bit of sense!

More than willing to help contribute. I like your approach too, makes sure someone knows what they're getting into with contributing. It would be nice (I know not always feasible) if project owners (looking for maintainers) would do this more often.

@xou816
Copy link
Owner

xou816 commented Feb 26, 2023

@xou816 hey, I just read your comments here, and thought that maybe - and only maybe - you could benefit from some unsolicited advice from a random internet stranger that happens to have 10+ years of experience maintaining free software. Please feel free to ignore this comment though, badly timed unsolicited advice sucks, and I don't know if this is the appropriate time.

Hi! Oh no, no worries at all, this kind of advice is definitely welcome! Thank you for taking the time to write this up.

The "1-year-ago [you] in [my] position" stuff is a good summary of what happened (even though this is a fairly small project, it got overwhelming at times). I guess that's how we learn!

I like your approach to this -- letting people work on something they care about and take some responsibility for it, without stopping myself from standing my ground / having my opinions. I'm not sure yet how I'd actually implement this, but it sounds like solid advice that I should at least draw some inspiration from.

This has given me a lot to think about. I have yet to learn and mature from this, and I really appreciate you chiming in a very humble and helpful way. Thanks a lot!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants