🚨 Looking for co-maintainers 🚨
I am progressively returning from a much needed break regarding my various opensource projects, and am looking for a more sustainable way to maintain them.
I have now been a free software author for almost 25 years driven by:
- A moral sense that authoring free software is the "right thing" to do, collectively building a corpus of code available to all.
- The intellectual challenge of writing code.
- The fun of interacting with like-minded people.
Over time, as sole maintainer, these positive aspects have progressively been outweighed by less pleasant tasks:
- The workload of triaging of issues and pull requests has increased with the projects' popularity.
- There is an alarming rise of issues along the lines of "please help me do X" (often without the "please") or "my use case doesn't work, figure out what's wrong".
- Polishing pull requests is exhausting. More often than not the submitter has done the "satisfying" part of the work (i.e. fixed their problem), expecting the maintainer to finish the work: check RFCs, tidy up the code, write unit tests, write documentation, etc.
- Infrastructure needs a fair bit of maintenance to ensure CI keeps running and binary packages are built properly.
This had lead to a draining cycle of heavy investment in my free software projects, burning out, feeling guilty about neglecting the projects and repeating. A one-person maintainership is just not sustainable, so I am looking for volunteers to help co-maintain the different components of aiortc. To be clear I am not looking for funding, that won't give me more time to spent with my family, run my company or honour my volunteer commitments. The projects in need of help are:
aiortcitselfaioice, the Interactive Connectivity Establishment librarypylibsrtp, the Python bindings tolibsrtpaiortc-codecs, the binary codec builds used for the binary wheelsPyAV, the Python bindings toFFmpeglibraries
The main traits I value for co-maintainers are:
- A willingness to give. This is about helping out the community, not expediting your pet PRs :)
- A realistic view of what long-term maintainership of opensource means. I would prefer someone who can commit only moderate but regular amounts of time to someone who will go all-in and burn out in 6 months.
- High standards of quality. This means researching standards to find the "right" solution rather than the expedient one, strict adherence to full test coverage, an attention to keeping the code easy to read and a willingness to write documentation and examples.
If you care about the future of aiortc please get in touch by responding to this issue!
There is an alarming rise of issues along the lines of "please help me do X" (often without the "please") or "my use case doesn't work, figure out what's wrong".
From my experience, I recommend enabling "Discussions" in each GH project or create a mailing list or refer to SackOverflow or whatever for support/help related topics. Do not handle them in GH issues. Indicate the proper channel in the README, docs and GH ISSUE TEMPLATE and quickly close any GH issue which is about support/help.
The point here is: if there is a increasing number of people using your projects it means that they can also help others. And even if this is not the case, you don't have the obligation of doing it otherwise.
Polishing pull requests is exhausting. More often than not the submitter has done the "satisfying" part of the work (i.e. fixed their problem), expecting the maintainer to finish the work: check RFCs, tidy up the code, write unit tests, write documentation, etc.
Accepting PRs from external users is usually a dramatic process. Unfortunately many of those PRs just cover whatever the user needs for his/her own use case. Those PRs usually don't care about code guidelines, tests, compatibility, etc. When I get a PR like that I notice everything that is missing. If it's not properly addressed in a reasonable time, just close the PR. It cannot become a problem for you.
I can act as backup. Just like @lgrahl I already had elevated permissions but wasn't sure how to proceed on #900
I also volunteer @juberti who still cares about this kind of stuff!
I'm here and I will help out every now and then but most likely won't dive into the more time consuming tasks (reviewing / writing PRs, etc).
I can act as backup. Just like @lgrahl I already had elevated permissions but wasn't sure how to proceed on #900
Much appreciated! This is kind of @lgrahl's call. I mostly wanted to make sure at least one person has full ownership should i fall off the face of the earth, and I think we've got it covered .
The topic now would be to have active co-maintainers who help move the project forward on the day to day. These are probably people who have an actual stake in aiortc being actively maintained .
I can assist you with PyAV and aiortc. I face similar challenges with work-life balance, but I believe in these projects and I want to help you.
Hello,
I would be happy to support aiortc and aioice. (and other related projects if I have time to spare myself).
I work as a WebRTC engineer/data scientist, so I am interested in contributing to this project.
Hey @jlaine I am interested for this, Let me know if I can be of any help
Thanks for all the replies!
I'd prefer co-maintainers to have an established track record of responding to issues / reviewing PRs / contributing code. As I've already had the pleasure of working with @rprata I've invited him as a co-maintainer.
@yuki-uchida @Arvind2222 by all means please start helping out, and we can revisit becoming co-maintainers further down the line.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
You are very annoying.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This is actually quite funny in an awkward way. ðŸ¤