Contributing
What is a good, smooth and practical way to start contributing to Open Source? There are certainly many ways to do it, and there is probably no bad ways as long as you are polite and friendly, but I will describe how I do it.

Find a project

You probably have a project, a tool or service that you already use and perhaps even like that is Open Source. Maybe the tool has a flaw that annoys you, maybe it has an error message that reads wrong or it misses a key feature you think it should have.
That is your initial target. If you want to limit your work to a project that uses your particular favorite programming or framework, then maybe you need to search for your target wearing those binoculars. The point being that it is a good idea to pick something that you use and preferably like as a staring point. It will give you the right incentive and is more likely to be fun.

Watch the project

The tool you picked is written and maintained by a team somewhere. Maybe they have a forum, a mailing list or just an issue tracker on GitHub.
By starting to monitor their activities, their communication and reading up on their docs etc you can quickly get a feel for the project and a sense of how they communicate and develop their products. Ask a question and judge them by their response. Read their code of conduct. Verify that you agree with the chosen license.

Dip your toes

If the project still seems interesting, you can make your first move.
Find an issue, fix a problem, improve the documentation, something. Make the change to the best of your ability and send it off to the project - following the rules and guidelines in the project. Contributions can of course be non-code related. Localization and QA are also fine starting points for technical contributions. Why not help out with marketing and advocacy?
Be fully prepared that as a newcomer you will make mistakes, big and small, and there are probably rules and patterns you missed that your contribution are not adhering to. Expect several rounds of reviews, comments and suggestions of doing your change differently.

Critique

Do not take review comments personal. They do not describe your person. They are comments and feedback on your contribution. Feedback can be tough to hear after you have worked hard to provide your improvement, but stay aware that it is meant with the best possible intention to provide feedback to you for this and future work, and to keep the project to a high standard.
Learning to take review comments is a necessary step. Be humble, follow advice, iterate, send updated versions.
It should also be noted that not all suggestions may be valid and correct. Push back on comments when you disagree with them.
Be patient when waiting for reviews and feedback on your work. The maintainers of the projects are often volunteers and working on this in their spare time and through coffee breaks. Allow them ample time before you send reminders. Maybe the maintainer is on vacation or takes care of a family emergency.

Dive

When your first contribution has been accepted/merged there is nothing stopping you from stepping up your game. Pick a bigger topic, write a bigger feature, fix a more complicated bug. The sky is the limit.
Once you feel confident enough, the project will also of course greatly appreciate when you help out in bug reports and review other contributors' contributions.
Copy link
Edit on GitHub
On this page
Find a project
Watch the project
Dip your toes
Critique
Dive