Hacker News Reader

Comment by rvz | Hacker News Reader

This reminds me of the comments section or sometimes a mailing list for a particular bug in a driver or a low-level component and most of all the replies were from 'users' who weren't helping to solving the actual problem in the discussion. Then one day an unknown contributor not only was able to reproduce the bug but also sent an actual fix and ended up gaining commit access to the project after staying there for a while.

Whenever I hear the 'mythical legend of the 10X rockstar developer', I think of them. Mozilla needs more of those developers to reproduce AND send patches to interesting bugs like this. Not the whining copypasta forum-posting 'users' calling themselves 'developers' who take many open-source projects like this for granted and don't appreciate the time spent by the maintainers of the project.

Nowadays they're usually doing this on a developer social network through every maintainers nightmare 'The Issues Tab'.

View on HN

Hah! As an open source maintainer for a mildly popular repo a big chunk of my time is spent weeding out people filing issues and opening PRs for trivial changes (like adding a line to the README file) just so they can claim to be a "contributor". Meanwhile there are a ton of issues that are ready to code with a full explanation and are even marked as such ("good first issue" or whatever else) that stay untouched.

Regardless of community engagement, perceived interest, Github stars or whatever else — finding a developer willing to spend actual time and effort to make a project better is very, very rare.

Which repo, out of interest?

Yeah, people who drive-by PRs to unnecessarily fix a minuscule style or dependency-version issue is one of my pet peeves. I don't spend a lot of time on it, but this kind of cynical game playing sucks. These kinds of contributions produce a net loss for OSS, not a net win.

I submit lots of one-word grammar and writing fixes.

For me it's not about the reputation boost - it's that I see a minor flaw and can offer a quick fix, rather than just moving on and pretending I didn't see it.

It's like picking up litter when you see it on the street.

That said, I'm not a maintainer of any open source project with actual users, so I'm not familiar with the kind of gamesmanship you undoubtedly see once a project is popular.

I've made a bunch of one line PRs that I'm worried are perceived like this, but they're always a fix for something that cost me a lot of time. Examples include adding quotes around CSS base64 URLs (our base64 string included //) and changing the case of some headers in documentation (headers were downcased upstream and the example in the doc failed silently). Are these the kind of PRs you don't like?

Not at all. It isn't the size of the PR that matters, but I generally want contributors to:

- Discuss their changes beforehand (usually on the issue page)

- Use patterns and practices that the rest of the codebase follows

- Listen to comments and feedback

- Write tests

While the work is "free", it should still be treated professionally.

> - Discuss their changes beforehand (usually on the issue page)

Interesting. When I last looked at contributing to open source, some general advice was to offer up code even if its likely the wrong approach. The idea being that maintainers are busy, and there's lots of people that drag on their time without ever contributing anything. Showing you're actually willing to put in time and effort will make the maintainer more likely to guide you in the correct direction because you've already shown you're willing to spend time on the issue.

I feel the same way. Although I have only been starting to contribute recently, I thought that by offering code first via pull request I wouldn't be perceived as a whiner in the issues section.

This is definitely true. I'm not a fan of Issues discussion with random people who are not known to be reliable contributors. Talk is cheap, show me the code.

"Given enough eyeballs, all bugs are shallow."

https://en.wikipedia.org/wiki/Linus%27s_law

Reply on news.ycombinator.com