I'm enthusiasts for everything tech. One will find me typically writing about tech and programming. And a life long learner with gaming and coffee problem.
Gloria Asuquo is a Developer Advocate🥑 and Front-end developer. She is passionate about sharing her knowledge of open source, web development and encourages the adoption of tech as a career.
Let's be honest, most open source developers will tell you that their project welcomes newcomers. It's definitely more true of some projects than others.
For a given project you're going to want to start by looking at more peripheral ways of contributing. In fact fixing a typo in the readme could be a good way to double-check if maintainers are welcoming pull requests, but beyond that: improve the documentation. Does it have a website? Does it have tutorial content? These areas tend to be open to more and easier improvements than the core code, and your newcomer perspective may be quite valuable! If you work on the test suite, this brings you a little closer to the code, and can often be a useful area to add to.
But which project? If a project is used as dependency in many other things, particularly if it's a small limited-scope component, then changes will have widely felt consequences. In these cases it's going to be hard to make a change. Any pull request will have lots of people looking for reasons why it shouldn't be merged (although on the plus side, if you do manage to make improvements, it will be more impactful). You probably don't want to start there. As a general rule, you should look at projects which are more towards "end applications" rather than big "components" or "frameworks".
In fact that could be generalised because you also don't want to pick a super-popular end application either! Same problems if your change will go in front of lots and lots of users, then it's less likely to happen. So actually you're looking for something not too popular, but this is a balance, because obviously you'll find it less interesting contributing to something which nobody is using! Perhaps you want something which is popular within its niche. So this brings me onto the topmost tip... you have to find something that interests you!
I just came across this site: up-for-grabs.net which is an attempt to answer your question. Or at least it's a list of open source projects where they've tried to label issues which a new contributor might find easier to work on. Take a look through the projects for something that interests you, and then through the labelled issues.
To be honest, I personally tinker on the periphery of many things and can only fantasize about making more substantive contributions or even being a maintainer of projects with many github stars, so maybe I'm not the best person to dish out this advice. On the other hand I think people who have their head deep in maintaining a project find it hard to empathise with newcomers. You may find some people's idea of a good beginner issue is a little unrealistic.
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (3)
I shared a post related to it you can check it out hereAwesome Link
Thank you for recommending. Will check it out
Let's be honest, most open source developers will tell you that their project welcomes newcomers. It's definitely more true of some projects than others.
For a given project you're going to want to start by looking at more peripheral ways of contributing. In fact fixing a typo in the readme could be a good way to double-check if maintainers are welcoming pull requests, but beyond that: improve the documentation. Does it have a website? Does it have tutorial content? These areas tend to be open to more and easier improvements than the core code, and your newcomer perspective may be quite valuable! If you work on the test suite, this brings you a little closer to the code, and can often be a useful area to add to.
But which project? If a project is used as dependency in many other things, particularly if it's a small limited-scope component, then changes will have widely felt consequences. In these cases it's going to be hard to make a change. Any pull request will have lots of people looking for reasons why it shouldn't be merged (although on the plus side, if you do manage to make improvements, it will be more impactful). You probably don't want to start there. As a general rule, you should look at projects which are more towards "end applications" rather than big "components" or "frameworks".
In fact that could be generalised because you also don't want to pick a super-popular end application either! Same problems if your change will go in front of lots and lots of users, then it's less likely to happen. So actually you're looking for something not too popular, but this is a balance, because obviously you'll find it less interesting contributing to something which nobody is using! Perhaps you want something which is popular within its niche. So this brings me onto the topmost tip... you have to find something that interests you!
I just came across this site: up-for-grabs.net which is an attempt to answer your question. Or at least it's a list of open source projects where they've tried to label issues which a new contributor might find easier to work on. Take a look through the projects for something that interests you, and then through the labelled issues.
To be honest, I personally tinker on the periphery of many things and can only fantasize about making more substantive contributions or even being a maintainer of projects with many github stars, so maybe I'm not the best person to dish out this advice. On the other hand I think people who have their head deep in maintaining a project find it hard to empathise with newcomers. You may find some people's idea of a good beginner issue is a little unrealistic.