Hacktoberfest 2022

Hey, Nix team! I’m using Hacktoberfest 2022 to try and motivate myself to participate in the nixpkgs repo some more, but I’d like to try very hard to help alleviate additional work rather than create additional work. While I do have some PRs in mind (I have a package or two and maybe a module to contribute), I would wager that helping to grind through issues and PRs would be very beneficial.

My question, then, is “how can an intermediate nix user help most effectively”? Assuming that somebody like myself is (hopefully!) capable of contributing beyond simple version bumps and bug reports, where is the greatest need? A +1 reviewer to upgrade PRs to get them pushed through? Triaging un-triaged issues? Something else that I’m not thinking of? I’d absolutely love to lift the burden of busy work from the contributors who’s time may be better spent in more intricate issues, so please, use this topic to sound off on where those type of needs may be so that I and others can help you. :slight_smile:

5 Likes

Hey @tylerjl, you’re asking exactly the right questions here! I cannot give a meaningful answer right now, and want to make it my next priority to get closer to one. Maybe it actually is: help make more obvious to intermediate Nix users what’s the most valuable thing they can do with their energy and how to find out how to do it.

Maybe, maybe you can essentially find out for your self and add your findings to contribution guides and other documentation. Share with those who follow the insights that you gain from your struggle.

What do you think?

As someone also practically not contributing at all at the moment, my experience from other projects is that when you’re starting out helping out on any large software repository you just always create more work for the person who needs to integrate/review it, at least until you’re trusted enough to merge others’ work yourself.

It’s a fundamental weakness of the merge/review process, because good review inherently means duplicating the “real” thinking work, + some communication overhead. So for as long as you can’t make up for this work duplication by merging other people’s stuff yourself it just adds additional work for the group of people who have merge permissions.

You can try to get around this by contributing something important that your reviewer would have had to do themselves in the short term anyway, but that is by definition something critical, and then makes the review harder again (and probably more likely to create problems, because nobody reviews code well enough to actually duplicate the work).

That, or you surprise them by solving something tricky that they had no idea how to solve in an elegant way, but that’s a very hard thing to do, and nobody will be able to point you at things like this, because by definition nobody knows an elegant solution exists.

It’s really annoying, but it’s a tricky short-term vs long-term situation. There is rarely a good “beginner” issue, almost every project I’ve been on struggled defining those (and spent more time labeling tickets with it than they got out of them being solved by “beginners”). On the other hand, getting up to speed (and enough trust for merge access) is incredibly valuable long-term, and people realize this, so I’ve rarely been in a situation where a maintainer wouldn’t take their time with me.

It is unfortunate feeling like you’re not really helping despite your best efforts in the mean time, though, and I personally agree it is a hurdle to contributing to nixpkgs. I think the trick lies in making people feel like they’re doing helpful work rather than actually making them do helpful work :slight_smile:

Reducing the barriers to “trust” can be helpful too, of course, but defining appropriate levels of trust is a can of worms in its own right.

You could search for first time PRs and review them so that the usual reviewers and merges have less work to do.

3 Likes

It’s not about whether or not you can do this faster yourself or even if it overall is more work for everyone - it is all about growing the number of people who contribute. It’s pyramids all the way down!

Come, join, do anything, get your ideas shot down, argue (respectfully), get things merged. Then rinse and repeat. We collectively generally suck at onboarding people and bringing people up to become full-fledged members despite having (IMHO) one of the nicest communities on the internet.

6 Likes

@fricklerhandwerk that’s a good idea - maybe at the conclusion of the event I can draft up a “landing page” of sorts for contributing to Nix in a very general sense. Obviously we have a CONTRIBUTING.md for guidance with PRs, but it’d be really nice to have a link to send people to that answers my question (“where do I start? how can I help?”).

@TLATER Indeed, I think at this point just putting something constructive out there is a reasonable place to start, at least. Contributors like you and I can help a lot more once we have more experience just doing stuff in the repo and can provide higher-level reviews down the road.

@Sandro that’s a great direct answer, thank you!

@peterhoeg that’s very helpful at the outset of something like hacktoberfest - hopefully folks can see that contributions of any size and type are useful. :+1:

@tylerjl We can reasonably point to anything in the manual, and IMHO CONTRIBUTING.md should do that as well instead of duplicating information. I just suggest that, instead of tackling larger tasks that may quickly turn out to be very nasty cans of worms, you just add the most obviously helpful single thing you can come up with, and continue from there. The larger your change the longer it will take to get it merged, the longer we have this situation @peterhoeg describes.

1 Like