In a recent blogpost, Loris expressed how Zig team cares about the contributor pipeline. And they want to invest in people that could become regular contributor.
I personally I’ve contributed a few times to Zig, allowing nvptx compilation, and fixing C calling convention on x86_64) but I find it very tedious to contribute to Zig with PRs waiting for month without feedback. And I feel it used to be easier few years back.
I’m not really sure if it’s a me problem, or if others have similar experience.
Have you already contributed to Zig ? Have you been discouraged to contribute more ? If yes, why ?
If you’re someone with write access, do you find reviewing PRs is a good use of your time ? If no what could be improved ?
This is not the fault of the Zig team, and I am not interested in starting any flamewars here, but the fact that Zig switched to Codeberg is unfortunately a major blocker to me as a screen reader user from contributing. Not only does Codeberg have closed-source proprietary JavaScript CAPTCHAs at least for screen reader users to sign up, that just screams open source and friendly, but the Forgejo team and Codeberg by extension are not interested in fixing accessibility bugs. I opened two issues about minor problems in Forgejo months ago, and got one or two replies from maintainers, but no actual development. Yes, I know I could go fix it myself, but I’m a systems software engineer who just finished college and has a job coming up, I don’t have the time or want to fix everyone else’s broken shit.
All this being said, I 100% understand and even respect the Zig team’s choice to move off of GitHub. Their reasoning was sound and I’m ideologically aligned with the Zig team on this matter, and I personally absolutely hate GitHub myself. But the sad fact of life for me currently is that it’s actually usable with technology I need, and it’s part of what pays the bills currently, so I’m stuck with it. Of course, I don’t expect the Zig team to move platforms again just to appease the teeny minority of blind users, but maybe another way of submitting patches could be good? The Linux kernel does a mailing list, not sure if that’s the best, but some way that doesn’t require me to go through the horrible Forgejo UI would make me want to contribute a ton I think. IRC with links to .patch files? I absolutely love Zig and would like to contribute to its standard library in particular.
I’ve had mixed experience. If I find a small problem with system integration, like something wrong in std.c, it was merged quickly by Alex and it was very encouraging. For anything larger, the lack of feedback is indeed extremely demotivating, to the point that even though I’d like to help with the standard library, especially the new Io, I’m only sending essentials that I need for my own implementation. Plus, it seems that communication about larger features happens internally, and then a large PR appears and is merged with little review, so to me it feels like contributing to a commercial project, where the company has some goals, and just accepts bug fixes. I really don’t mean any of this as critique, everyone can manage their project the way they want, but the situation did discourage me from being more active.
I have been trying to start contributing the last couple days and don’t have any complaints yet, but I haven’t been at it long. The build process etc was pretty pain-free (although the test suite takes forever!).
There has been some debate about why PRs take longer to merge. Some argue that it’s due to the size of the team, or as someone mentioned, the team engages in internal discussions and prioritizes accordingly.
FWIW, I consider status quo to be in a horrible state, and plan to prioritize this after the 0.17.0 tag. Everyone agrees there are big problems, but we don’t yet have internal agreement in ZSF about how to attempt to solve them.
If you are still looking for ideas: In Cubyz I had some success with moving part of the workflow (PR categorizations, prioritization and preliminary review) to semi-trusted volunteers. You can see the categories and descriptions here: PRs to review · GitHub
This of course isn’t going to be a full solution, but it greatly reduced the management overhead for me and reduced the chance of losing PRs, since they are all tracked.
Not quite the same idea, but Mitchell Hashimoto’s Vouch system is also worth looking at. I’m sure it’s been discussed here before.
Every project has a definite group of trusted individuals (maintainers) and a larger group of probably trusted individuals (active members of the community in any form). So, let’s move to an explicit trust model where trusted individuals can vouch for others, and those vouched individuals can then contribute.
I think it would help the community to onboard more people to important Zig projects. I‘m thinking of stuff like „all your codebase”, ZLS, Aro, translate-c, even dvui.
There is a lot to do in the ecosystem besides compiler work.
Getting more people to be involved with Zig itself is a trade off. I know from first-hand experience that you can move faster with a team of 10 excellent engineers than with a team of 100 mediocre ones. And my guess is that even 10 excellent ones and 100 mediocre ones together might be slower than just the 10. Splitting up everything into different projects can work but requires stable, versioned, tested APIs. For example, there could be a team responsible for async IO.
I totally understand this is a complicated task.
I also understand that some topics are best kept under the control of the core team.
Like std.Io is still in flux and you’re probably the one with the clearer vision to where you want to push it, and unsolicited contributions won’t help.
There is already a “contributor-friendly” tag on Codeberg issues, but feels a bit under-used (32 issues out of 500) with most of them requiring very specific OS knowledge.
I also like the idea of having a second ring of semi trusted reviewers to pre-approve PRs, to channel the energy of the core team on the more promising PRs.
The irony of that blog-post was not lost on me, but I am glad and happy that the core team recognizes this as a problem and I agree with the previous poster that it’s of no use to start a flame war or write incomplete lists of their good/bad experiences.
there’s no irony, there’s an entire section of the blog post titled “growing pains” that explains the issues with scaling contributor poker.
In the early days of Zig it was possible to invest on every new contributor, but now the project has grown to the point where the amount of incoming PRs far exceeds the amount of energy core contributors have at their disposal to play contributor poker.
In practice this means that there have been instances of good PRs that have gone un-reviewed for extended periods of time, potentially causing valuable contributors to lose interest in contributing to Zig.
This is something we have mentioned in our yearly financial reports, and more importantly it’s an issue we’re actively aware of, and that we hope to solve (or at least mitigate) in the future.
Unfortunately, not only is this an inherently hard problem to tackle, but AI has made things worse.
My hope when starting this thread was to better understand what is the main energy consumption from the maintainer side, and try to brainstorm ideas on how to diminish the amount of energy required from the core team.
Like the idea of having pre-reviewers checking a PR meets a number of requirements before asking for a formal review.
This is actually tremendously valuable advice, ultimately any progress wrt the Zig compiler project is up to Andrew and the core team, but there’s certainly projects like allyourcodebase that have a much lower bar to both entry and of quality to merge (not to say that ayc is bad or that it allows slop, but for example I explicitly allow incomplete ports of the original build script so that one can scratch their own itch and leave the rest of the work to somebody else('s itch)).
Interestingly raysan is not asking for “contributions” but for “maintainers” dedicated to specific area.
Do you think Zig could work like that ? Assign maintainers to specific area where they have more room to make progress ? It kinda already does, some backends are mostly community developed, but I don’t think I saw that discussion in the open.
I think it could work in the same way as Linux, where you have subsystem maintainers that merge certain PRs that are finally all merged together by the BDFL or a higher authority