What is the current process or strategy by which gets decided when a pull request gets merged or pushed to the build / test runner?
From my pov, it seems like the only way for a PR to get merged is to catch a maintainers attention (I assume fixing an issue related to a milestone), otherwise you land in the general “maybe-later”-pile.
This is generally fine considering zfs limited time and funding, but causes the the Pile of PR’s to grow, with out of date branches, that are unaware of each other.
How can we actually “push” non-milestone or enhancement / quality of life PR’s without burdening the zfs staff?
Should every non-maintainer PR be linked to an issue and be closed if it does not?
Should every issue raised this way be argued for intensely?
Are we just too lazy in documentating our code and intent for them to be merged easier?
Are non-milestone issues actually not that important, regardless of how they may look to the contributor?
From my experience I’d say that your time is indeed best spent working on issues that have already been triaged and are ideally part of an upcoming milestone, especially if you’re a new contributor. Beyond that building a certain rapport definitely helps, the more you contribute the more likely your PRs will be looked at (I realize this is a bit of a chicken-and-egg problem, some persistance is required).
I’d encourage you to join the ZSF Zulip channel, if you have an idea and ideally a concrete use-case you can talk about it there and ask for help implementing it if needed. You can also ask for feedback on your current progress which will facilitate reviewing your code later. If you already have a PR up that’s passing CI and is ready for review you can also send a friendly reminder on Zulip up to once a day for it to be looked at.
WRT the PR itself, having a short text that describes the changes you’ve made, a couple of tests to prove that the changes actually work and a reasonably clean and easily traceable commit history with meaningful commit messages of course also helps to make your PR easier to review.
Unfortunately there will always be a remaining chance that no one will find the time to review your PR before merge conflicts start piling up, no matter how high quality it is. That’s just the reality of the resources the core team has as of now.
Unfortunately each commit or rebase forces another CI run, even if you rebase from a tested master branch. This end up eating ressources and potentially taking so long, that other branches get pushed while waiting, forcing you to rebase again.
So one should only rebase if there are conflicting files.
If there’s a step that has a bottleneck, adding more to that step is the opposite of what the system needs.
As someone not involved with the development, my suggestions would be
before writing opening a PR, focus on making sure that this PR is something that the team is actually interested in or able to put attention into.
it’s okay to link a PR to an issue and then just close it.
make it easy for them™ - the easier your PR is to understand, review, and test, the less work it will take to get through the bottleneck. an extra 15m of your time here could be huge here.
I’d like to ask the team, if I see a PR that I’m interested in and want to help getting it merged, is it helpful if I review it and mark it, or is that a waste of time. I guess pointing out problems is helpful, but maybe “approving” is unwanted, just want to check.
Since this is an issue specific to ZLS I recommend going to their discord and just talking to people. I think open source maintainers usually appreciate someone introducing themselves and being part of their community