question for free software maintainers
how do you go on holidays?? I'm at the point where I get 20-25 GitHub emails per day (issues, PRs, discussions, replies). I'm scared to think what I will come back to if I leave for a week or two
@YaLTeR I don't receive that many emails, so... I just go on holiday.
But on a more helpful note, I admire the way GoToSocial developers go on holiday: they announce it in advance, and then lock the repository. No new issues or PRs accepted while they're away.
@YaLTeR I can't speak for Github emails but I do get a lot of sponsor emails, and other channel related stuff and frankly not everything needs my attention and there's very likely some things that you might find that can be filtered out for yourself.
@bugaevc you know, i never thought about that in this context (i guess because of all the other more important contexts to think about it in)
now i wonder, how bad was it? how large was the inbox and what did you do?
@YaLTeR the inbox / GH notifications backlog was huuuuge; it took me months to deal with things once I was back. But also I asked you to maintain my project 🙂, and in other important projects I was involved in, I wasn't the only developer.
@YaLTeR if you don’t have anybody else that can cover you with issue triage, then: add a notice that you’re off for a while, and disable GitHub notifications entirely. Also: find somebody that can cover you with issue triage.
@ebassi i guess disabling (or at least filtering out everything that's not a PR or i'm not explicitly mentioned) is the way to go. About finding someone to help with issue triage, that would definitely be a big help, but I'm not sure how to go about it. Currently can't really think of anyone else consistently frequenting the issue tracker
@YaLTeR onboard other maintainers so you're no longer alone in the project :) The only feasible long-term solution, even if releasing some power (e.g: other people make decisions too) feels scary. Let me know if you want to talk about strategies on how to do it.
@pabloyoyoista how would you find such people? I can't really think of anyone else even frequenting the issue tracker. For PRs, I gently asked a few times that PR reviews from people with accepted PRs would be helpful, but I don't think anyone showed up yet
@YaLTeR hi, happy niri user here since a few days - thank you for your work.
what is important to the project is not your ability to respond fast, but your ability to prevent the hobby from becoming a full-time unpaid job - i still fail at that.
the solution is: on-boarding, then delegate, delegate, delegate. if nobody else is there, tell the people in your issues that you're at capacity and could use extra help.
@YaLTeR I turned off email notifications for GitHub years ago, never missed them ...
if I want to see what's happening to my GitHub issues / PRs / etc., I explicitly need to visit github dot com in a browser 😅
@YaLTeR it can surely be hard. Two strategies I have found useful have been: advertise it, tell everywhere that you want more contributors and maintainers: interviews, talks, etc. and have a place where people can show up if they want to help. The second one is speaking out things that you could get help with (like "help welcomed" or "newcomers" labels in GNOME), both in issues, but also in PRs. Writing down as many of your thoughts as you can also help. So that people that want to help know how. My feeling is you're already doing this in some ways though.
Finally, having a look at https://github.com/YaLTeR/niri/graphs/contributors it seems it might be hard to get a lot of help, though. You are doing an absolutely incredible job at maintaining this project, you seem to be everywhere, and able to do all the tasks that a project needs. There is this hard-to-break pattern, where people won't show up if somebody else is already doing the work. If a project is amazingly maintained, most of the nice neat features are fixed promptly, etc. then people will turn around to something more urgent. If you leave gaps (for example, because you let people know you are on holidays, that would be great if others could help with X in the meantime), then it's easier that people show up.
But honestly, writing a compositor that is not mainstream in Rust in a huge feat, so getting help might be a bit hard regardless. You are doing an amazing job though, really hope to see you succeed!
@pabloyoyoista right, i should probably make it more obvious that i'm looking for help with issue triage and PR reviews. As for newcomer issues, honestly I'm reluctant because that just means more PRs that I need to review... Which sounds like a bad local minimum to be stuck in (much better when people do help implement things *and* with reviewing those PRs than nothing happening) but it's hard to get out of
@YaLTeR Don't make the mistake of trying to solve every reported problem or answering every question. Especially if you are managing the project alone. You're seeing the inherent risk of burnout of doing this now, ahead of time, which is very good. Prioritize your own needs and your health.
I am intentionally leaving some small bugs in my projects unfixed. Critical problems should of course be fixed. But there are advantages to leaving some things broken.
Unsolved problems will attract new contributors. Unanswered questions will attract people who are motivated to help others. If you fill out all this space yourself then people might get the impression that no help is needed and spend their time helping out elsewhere.
This is also true for work, it seems the hole that is easy to fall into is a trap both for professional activities as well as hobbies. If you do everything yourself all the time at work your manager won't even think of hiring someone, and if you don't take breaks from your personal OSS projects it'll be harder for people to chime in too.
And in both cases, you're indeed probably headed for burn-out.
@YaLTeR people often tell me "you know, I like [this project], but there's JUST ONE LITTLE ISSUE THAT is preventing me from..."
and then I say "if I had the time to deal with everyone's one little issues, I'd need a massive sponsorship or universal basic income". i divert a lot of my efforts into helping other people get started, because that, in the long run, saves me time (even if that approach fails sometimes).
@n0toose heh, relatable. i need to figure out how to find people to unboard
I have written a few things that might help you:
https://docs.oscollective.org/resources "Growing Your Contributors"
https://www.harihareswara.net/posts/2024/trust-new-maintainer/ "Whether And How To Trust A New Maintainer"
@YaLTeR projects like gotosocial announce that they go on holidays in a more organized manner - the world may be chaotic but you don't have to lose yourself in the midst of it all, especially not due to social media pressure.
@YaLTeR glad to hear you think some of those can be of help. Regarding newcomers... Anybody able to pick up and write code for a compositor written in Rust is surely somebody with decent skills already. It's totally fine to don't give the most attention to people that show that they don't have the skills. The good thing of Newcomers is that they don't yet have another project to maintain, so it's sometimes easier to keep them around than established contributors. Maybe something like: "Thanks for your PR! Unfortunately it's now in the queue after these other 3 PRs (or label) that I need help reviewing. If you can help testing and reviewing some of those, I'll get faster to your PR" might already get you somewhere. But surely the trade-offs are very personal though.
@YaLTeR if possible, try to onboard contributors as maintainers.
You workload already sounds insane.
The constant arrival of new tickets will most burn you out.
I have been in a similar situation as maintainer, and with some luck, and most importantly other people helping, escaped the situation.
- replies
- 0
- announces
- 1
- likes
- 2
@YaLTeR I wish I had good news for you. I came back to over a thousand this week. Honestly, if I was going to do anything with AI it would probably be to deal with them.
I try to go through what I can in the morning until I’m fed up with it then move on until tomorrow.
Getting them out of your face on a weekend is pretty valuable.
We really need tools for this, even if it’s just an email pause/blackout outside of our scheduled working hours.
@YaLTeR announce a pause, tell people to lay off for a while 🤷♂️
@YaLTeR I was always lucky that I never maintained any popular open source projects completely on my own.
If I were in your position, I would disable email notifications during my holiday and glance through the opened issues and PR that have been opened since then.
@YaLTeR Hello, I just switched to niri a few days ago and I'm sticking with it because it's so great. whatever happens, you're not obligated to catch up to all those emails and you deserve a rest many times over. if you burn out, it'll be worse in the long run than letting issues pile up. take a rest, come back later and enjoy the work, don't let it be stressful. niri is fun, and it would pain me if the maintainer is burning out from it
@nihl @stsp i think i'm managing code issues well in this regard. i don't rush to fix every small problem just because it exists, i'm pretty chill about it
for me the bigger hurdle is responding to all the issues and questions (especially where i feel my design feedback or justification is needed, which is something i feel often) and reviewing incoming PRs
@YaLTeR @nihl Hmm, is this feeling really justified, given the time sink it seems to create for you?
Not everyone deserves an answer, especially when a topic keeps coming up repeatedly. I would suggest to resist the urge to put things right on the spot every time. Let people be wrong on the internet. Others who are already more familiar with your project and development goals can correct them if needed. It does not have to be yourself every time. You can always decide to get involved and provide guidance once there is a real chance that some PR would get completely derailed and waste a lot of your or someone else's time.
@YaLTeR @nihl I discussed issue tracker design ideas with a friend recently and one thing which stuck with me was the idea that public issue trackers should have a queue of pending new issues which have not yet been triaged by a developer. And once that queue hits its (configurable) limit the next person trying to add yet another issue gets asked to please try again later because the queue is full.
@YaLTeR I have 200 emails per day already so I always bring my laptop to holidays, or maybe it's just called remote working while traveling :)
@felixonmars oh no
if i brought my laptop to holidays, knowing myself, i would end up with no holidays
@brainwane @n0toose thanks! Definitely some food for thought here, especially around the "sole maintainer" parts—since I'm not at the bigger open-source project stage yet