Hacker News Reader

I disagree. I don't think the article is saying that.

The article basically says you should have some connection to the project. This is very much the traditional view - you should contribute to open source by scratching the itch you have.

> I'm not a particularly good programmer but I have just recently been trying to contribute to an open source project (Apparently doing it the "wrong way" according to the article!) and its going amazing!

Why do you think the article is saying you are doing it the "wrong way"?

Hmmm after re-reading the article I think you might be correct!

> Heck, with proper supervision the kids themselves can help too. You can do open source as a beginner, you don't need to be a senior for that.

> But you need to be involved in the project and act accordingly, you don't just go and throw bricks around.

I guess I am doing it the correct way! I think the author should have also mentioned this point in the how to contribute the right way so its more obvious.

Your first point is backwards:

> 1.) Use open source software (Fair enough but not helpful)

It should be

> 1.) Send PR to projects you already use.

The idea is that you understand how the sofware is used before triying to fix or improve it. It also work for propietary software, dogffod it yourself and use hallway usability test.

(There are some examptions like fixing typos or transforming the automatic test suit to be run in github actions, but most of the times it's very useful to already use the project to understand what is the correct fix.)

Yeah your right, after re-reading the article that was the point the author was trying to get across!

Regarding the package maintenance item, that is just an example of something that was right for the author, not a suggestion for the general public. It was something they found useful, used regularly, and happened to be unmaintained. This put them in a position to make a meaningful contribution, beyond padding their work portfolio. This is the whole point of #1. You are in a better position to understand the flaws in software you use, and you have a vested interest in fixing them. Picking a random bug on a random project isn't going to give you the same insight.

> However, if I continue to help develop the project them training me now will certainly be worth while as I become better at contributing.

The problem is the 'if' is a big barrier.

I feel like the article documents the author's own experiences (which, to be fair, is a valid thing to do) without emphasising, or really even trying to emphasise, the how. Which really makes it less useful for anyone looking for learnable takeaways.

But hey, it triggered this HN discussion, and I see a lot of replies here which seem more useful for that kind of thing.