I have to confess something: I am not that eager to become a contributor of open source projects. I have made several commits into the main line of python, wpa_supplicant and GStreamer but it was not because I wanted to become a contributor of the project but because I found an issue, which looked to be very likely to happen to other users and me in the future, so I did. Therefore, my contributions were not as noble as others by enthusiastic contributors.
I highly respect all the contibutors of the open source projects regardless of what they have in mind. It is partly true that experience in open source will beautify your CV making an impression on some people. Some of the juniors tend to admire the open source contributors, although not many professionals think the contributors are more skillful engineers. At least, the contribution ensures the contributor is capable of finding an issue from current source code of the project and coming up with a resolution to the problem.
By the way, the reason I think that the open source contributors deserve their reputation is their attitude.
They are proactive as no one asks for it, themselves are those who fix a bug they found, and they are willing to change their own style into the rule of project owner for contribution.
As well as they are volutary since most of them are not hired for the maintenance of the project. No one pays for it but the devotion takes contributors' own private time which is the most precious resource of human being. Usually, there is nothing left but self-satisfaction as an individual commit is going to be buried by hundreds or thousands of others. The work is for the sake of other people who will face the same bug.
Get into the situation
Let's assume that you already have enough spirit of charity. Prerequisite fulfilled. While you are using one of the open source library or something, you have encountered an issue that it does not work as intended. In this case you are given 3 choices. You may switch to another open source, report the bug to the maintainers of the project, or start debugging of the issue. When you read a document like 'Getting Started' and found a typo or something wrong, the choices are given in the similar way. You may ignore it, report to the maintainers, or fix it on your own.
For both situation, the roads to the contributor are the last ones, though reporting a bug could also be regarded as contribution in a broader perspective. Somehow the contribution would go through the reporting step.
How to?
Mostly, the contribution begins with reading CONTRIBUTION file. That kind of a file or a section elaborates step-by-step instruction and rules to do contribution. After reading through it, you will submit a bug report to its designated bug tracking system, such a s Bugzilla or Jira, or send email to the group of maintainers as specified in the document.
At this point in time there is much possibility that your report is treated as NOT A BUG. Don't be disappointed. This is quite natural that the project owner is being defensive. It is not always easy to understand the intention of an author behind the code so the one you think it is a malfunction can be an operation by design. If you still think it is a bug, you need to convince the person in charge of the project or its module. I'd say the contribution process is full of debate, taking much more portion than code work sometimes.
If the bug is recognized as a problem by project maintainers, you may wait for them to resolve the issue or start debugging by yourself and make a fix. You may also post the code snippet to the bug reporting system as a draft telling them you have an idea for the fix. If you manage to solve the issue by your code work, you may submit the code to the source code management system which should be described in the CONTRIBUTION file. Again, this process involves discussion on the approach and the method. The maintainers may become more conservative during the review stage. This is also natural. To claim a bug and make a fix for it means the current operation is going to change to work in a different way, which may have side effects on its relevant functions. Many documents including Python Developer's Guide have stated this point.
"Put yourself in the shoes of someone whose code will be broken by the change(s) introduced by the pull request. It is quite likely that any change made will break someone's code, so you need to have a good reason to make a change as you will be forcing someone to update their code."
In the review stage, maintainers or CI/CD systems will check if your code contains any violations against the project's coding convention, verify the fix is working as its purpose, and perform the build and the unit tests. Once it is revealed everything is fine, then all you need to do is done. As a last turn, they will set a scope of the branches or versions for the application of the patch and merge it.
And you? Gratitude and Congratulations. You've become a contributor of the project who makes this software world better together.