Hi, I dont know if this is the right comunity to ask, please tell me otherwise. I apologize for my poor English, I’ll try my best!
I’m a professional software developer with about 10 years of experience. I have only worked on closed-source enterprise projects throughout my entire career. I am not familiar with the workflow involved in FOSS projects.
Is there a guide that summarizes or documents all the information or standards you need to know to contribute to any FOSS project? This includes the standards for commit messages, tags, and how to propose a new feature or report a bug.
I understand that this may be basic information for many of you, but for me, it feels a bit overwhelming. Also, I think that I’m afraid of working on a codebase that I’m not familiar with. There is also a fear of my own code being judged online. You know, you can never escape imposter syndrome.
I appreciate any info, hopefully I’ll be helping on improving some of my favourite apps in the future.
From my own experience:
- Start using open source stuff.
- Get annoyed by lack of a feature / a bug / something
- Fix it, without ever intending to upstream the changes
- Notice somebody has made an issue about a thing you already fixed
- Send the patches to upstream.
- Repeat ad infinitum.
That’s pretty much how I’ve ended up contributing to a plethora of different stuff.
I don’t think there’s the one process, however, GitHub seems to be the most popular platform. There the process is usually the regular git branch/pull request workflow.
The best way to start would probably be, to simply look up where the project you’re interested in is hosted/has its forum and then ask there. Some projects (like Linux) have a rather formalized process, while others (like many smaller, hobbyist tools) are rather lax.
Each project will have different standards to follow. It will depend on which you are interested in.
I’m a developer myself and from my understanding every project have their own set or rules, policies and guidelines. No two foss-projects are necessarily the same.
Best thing to do is to find a project you like then look at their PR documentation, or maybe hit up someone who’s a regular contributor to that project.
