“Good first issues” are usually not good first issues | Hacker News Reader

“Good first issues” are usually not good first issues

am17an.bearblog.dev

24 pointsam17an9 comments

How many projects have actually had productive contributers join out of an abstract desire to contribute.

Whenever I've contributed to outside projects, my motivation had been to avoid needing to maintain a fork. And whenever projects I'm a main on have had outside contributers, they very clearly had clear objectives they wanted the project to meet.

The much more important instructions for new developers is how to contribute guidance. Along with generally good documentation and design so they can actually make the changes they want to make.

Seriously, every project needs to have the "inner dev loop" in the README as bullet points. Nothing sucks more than taking two days to figure out how to even build, and once built, how to actually install/run/debug it. Especially for projects that use a fleet of repos that all interact or involve multiple libraries that need to be carefully orchestrated to actually run.

> I just wish more projects took the time to making this page more useful. When you create a "good first issue", think of it as paying it forward. You enter a contract with a fragile newbie; be precise, helpful and unassuming.

I love this. It’s no surprise that OSS projects need the occasional backlog grooming.

> But I've found this page to be downright helpful in most cases.

Perhaps you meant to say “UNhelpful”?

> Perhaps you meant to say “UNhelpful”?

Yes, thanks for pointing it out!

This might just be an instance of a larger problem: it's a lot of work to onboard people. To really do it well requires personal attention.

One of those things that personal attention is required for is helping people find a task that they can do. Having a list of tasks available that someone can read through makes half the journey so much easier.

There’s an additional difficulty here which is the actually good first issues tend to be completed early in their existence, so the long-term steady state is issues that are much more difficult for some reason or another (even if they aren’t stale)

Often I will leave low-impact work undone, so that someone new can attend to it. The feeling of "I actually did something" is so important for new contibutors.

Grafana has this problem in spades. The Curse of Knowledge is very loud sometimes.

Reply on news.ycombinator.com