Maintainer and Code PR review situation

[hoffie]

It seems to me that we are currently a bit understaffed regarding maintainers who work on the code side of things. While docs are nicely covered by @gilgongo and @ann0see, it's a bit more difficult with the code repo:

• @softins announced that he'll likely have less time for Jamulus in the coming weeks and maybe months
• @pljones seemed less active than previously in the past weeks as well
• @ann0see seems to be really active right now.
• Personally, I'm active some hours per week, but I still have lots of items on my TODO/review list.

I'm not trying to sound accusatory or demanding regarding availability at all. I've been inactive for several months in 2021 as well. After all, Jamulus is free time work and especially summer months might shift focus to outdoor activities instead.

This is problematic

• when there are PRs around topics which neither @ann0see nor I feel confident about guiding/approving (maybe due to lack of knowledge or due to someone else having unmerged work on that area), those PRs keep lingering (examples: Adding global commandline parameters #2599),
• when there are foundational PRs where explicit approval by all code maintainers makes sense (e.g. Code style change: Replace clang-format off/on with TODO/TEST comments. #2600),
• when we are relying on lazy consensus so that every maintainer has a chance to chime in,
• when either @ann0see or me raise PRs ourselves, as there'll only be one of the wanted two maintainers to review/approve (of course, we could admin-override and this can be done for obvious PRs, but for more involved topics we shouldn't do that).

I thought about requesting to onboard an additional maintainer, but I'm not sure yet. Currently, mostly expertise about Jamulus' history and several fundamental code paths (audio, network, protocol) is missing in my opinion.
I'm mainly posting about this in order to highlight this topic and have an explanation for contributors (@pgScorpio is still waiting for several PR review due to this situation, for example).

[ann0see]

Agree. Availability in a FLOSS-free time project is difficult, especially if you don't want to give too much preasure on anyone. I did have the feeling some time ago too and didn't get much feedback. Activity came up again a few weeks/months later, So it seems to be always in waves.
Yes, since Volker left, knowledge of the how the code works was lost, is spread around in multiple heads (and we need to identify whose heads that are ;-)) The key would be to find people who know the code well enough to review and engage the community to start reviewing.

We're in the good situation that the community is active in discussions, bug fixes, PRs and issue fixes. However, engaging in code reviews is difficult?

I must also say that for many PRs, I struggle deciding how to continue since I'm not fluent in C (++), so help is highly appreciated.

So what can we do to move this forward?

• I know @mirabilos as Debian distributor might know a lot about FLOSS maintainers and these kind of problems. However, he's usually not on the maintainer side, I think. What about @trebmuh who works in a semi-large FLOSS project?
• Find someone who knows C++ well enough. This person should be able to maintain and move the project forward (It would be good if we would be able to work like Volker did: Idea --> Issue --> PR --> Merge --> Release; Excluding much overhead) --> Post a discussion on Facebook? However, that needs someone who is really interested in moving the App forward: Intrinsic motivation as key point.
• Find someone with cross plattform knowledge. I am a Windows, Linux (somewhat macOS and iOS) user, but not that much a Windows/macOS/iOS and in no terms Android dev.

[ann0see]

By the way, the website only needs one approval by a Wiki admin:
That's currently the main dev team and some translators like ignotus. And the website is much less critical than the code repo.

[mirabilos]

ann0see dixit:

* I know @mirabilos as Debian distributor might know a lot about FLOSS * maintainers and these kind of problems. However, he's usually not on * the maintainer side, I think.

I’m actually more on the maintainer side than on the packager/downstream side ;-) just, not on GitHub. I don’t have any solutions for staffing/time or review or communication or coordination topics, either, though, I’m sorry to say — these are h̲a̲r̲d̲ problems (for techies, especially). bye, //mirabilos -- (gnutls can also be used, but if you are compiling lynx for your own use, there is no reason to consider using that package) -- Thomas E. Dickey on the Lynx mailing list, about OpenSSL

[ann0see]

@ignotus666 @henkdegroot @dcorson-ticino-com @jujudusud
Since you are long term contributors, can you help out getting the repository cleaned up a bit? Identifying old issues etc?
I've given you the ability to manage and triage issues.

Please have a look at https://jamulus.io/contribute/Administration if you don't know it already and comment on any issues you'd like to close and why.

Furthermore, it would be great if we got some reviewers/testers of the PRs. Who has a C++ background and wants to move the project forward?

[ignotus666]

I wish I had a better grasp of things but the application stuff is way over my head... I don't feel confident enough to be able to answer "why" I'd close an issue other than "because it's old/stagnant". But a lot of them seem to be encompassed by several ongoing open, sprawling fronts that I can only vaguely understand.

In my profession spring and autumn tend to be very busy periods with little time to spare. Maybe this happens in others too, hence the peaks and troughs in activity.

There are a couple of website (po4a) niggles I'd like to attempt to address, but I'm going to be swamped with work until at least mid-June...

[henkdegroot]

Happy to be little bit more involved and sounds like triage is a good place to start.
No problem to perform testing of PRs. Code review will be a bigger challenge but also depends on the changes made.
I am not a day-to-day programmer at all....

[ann0see]

@reinhardwh you were quite active with feature requests and according to your GitHub profile are interested in Jamulus. Would you also be able to do some testing/translating/reviewing for the Website and or the App?

[reinhardwh]

Downloaded the DE files and start getting familiar with Poedit
In case I find spelling issues in EN text: page "Running a server" - "ecourage" - what to do?

[ann0see]

I'd git checkout a new branch based on next-release, fix it and then open a Pull request to the next-release branch on the website repo (the files are here: https://github.com/jamulussoftware/jamuluswebsite/tree/next-release/wiki). Probably you can do that either via GitHub.com or locally on your device

[reinhardwh]

Hello ann0see
updated the DE translation for "Update Running-a-Server.po"

What's the next step after "Committed"?

[ann0see]

You need to open a Pull request: https://www.freecodecamp.org/news/how-to-make-your-first-pull-request-on-github-3/

Maybe also the following file helps (without the translation stuff): https://github.com/jamulussoftware/jamulus/blob/master/docs/TRANSLATING.md

[reinhardwh]

Thanks for the guidance
Just opened the Pull request.
Please check if all is good.
Then I will continue with next DE translation.