I noticed that the joystick drivers repository has not had any recent changes and there are several open pull requests which have not been addressed by the maintainers. Has this package been replaced or is it abandoned?
3 Likes
Looking at the commit history the last two contributors have moved on from their roles and may not have a much time for open source contribution.
If you are interested in becoming the maintainer of that package I can help facilitate making that happen.
I’m currently a university student and have very little experience in the open source community. I’m interested in becoming a maintainer but am a little doubtful in my abilities. Do you know where I could find some resources about what is expected of me as a maintainer before I make any commitments?
I could also step in and help maintaining the packages. However, similarly, I’ve only maintained one, very low-key, ROS 1 core package so far…
I guess the least we could do is review the outstanding PRs and merge them if they’re okay. However, I’m not sure in this strongly HW-dependent stack, how should we handle PRs to HW we don’t own.
That’s always been a challenge in maintaining hardware drivers. For instance, when I had access to a bunch of Hokuyo lidars, it was very easy to justify spending free time on maintaining that package. Now I have zero Hokuyo lidars 
1 Like
We don’t currently have a specific guide for third-party package maintainers, but we do have one for the ROS core libraries which should be widely applicable. I will say that having one inexperienced maintainer is certainly better than no maintainers at all! I’m more than willing to help facilitate a hand-off from one of the current maintainers if you think that would be helpful.
Realistically, the time commitment for a mature package like this one shouldn’t be too demanding (approximately one day per month). What you and any other package maintainers would be responsible for is:
- Issue Triage: About once a month, you should plan to triage incoming issues (i.e., sorting major and minor bugs from feature requests). You shouldn’t feel responsible for fixing or building everything, but it is good practice to at least review and categorize each new report.
- PR Review: About once a month, you should plan to review any new pull requests submitted by the community. Feel free to enlist other users to help you review incoming PRs.
- Feature Development: If you want to add a new feature to the package, you are more than welcome to do so on a timeline that fits your schedule.
- Releases: If in any given month you fix a bug, add a feature, or merge a PR, you should plan to release an update to the package. If your package has already been released, performing an update is fairly straightforward.
- Annual Maintenance: Once a year, you should plan to update the package for the latest ROS release. ROS releases happen on May 23rd every year, so you would want to budget some time every summer to complete the update.
That’s always been a challenge in maintaining hardware drivers. For instance, when I had access to a bunch of Hokuyo lidars, it was very easy to justify spending free time on maintaining that package. Now I have zero Hokuyo lidars
Feel free to solicit hardware vendors for demo hardware to test against. Alternatively, you can ask for a point of contact at the company who can test your updates on physical hardware. If this is something you are struggling with, I am more than happy to lend a hand. Vendors are usually willing to help if you point out that you are supporting their customers for free; I’ve gotten quite good at explaining the value of up-to-date ROS drivers to them.
4 Likes
Oh, funny, I was just working on a ROS driver for a Bambu H2C.
3 Likes