It may not be the best approach but i usually just open a PR or create an issue and offer a PR.
They usually let me know if it's lacking or my approach is wrong.
There's no shame in not knowing something.
this post was submitted on 17 Sep 2023
68 points (100.0% liked)
Free and Open Source Software
17932 readers
42 users here now
If it's free and open source and it's also software, it can be discussed here. Subcommunity of Technology.
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
founded 2 years ago
MODERATORS
You know that you are good enough at coding when your Merge/Pull Request gets approved. So get on it!
Rather if they get merged without edits.
I've seen even minor changes without flawed technique or style being discussed and changed for days before getting merged.
But it's also an excellent way to learn from pros. If the PR is worth it, they will spend the time for review and work with you until you fixed everything.
Eh, excellent code still gets discussed. Your approach might be unique and they haven't thought of it before. Or you may have perfectly suitable code, but it doesn't consider other parts of the project that you're not familiar with. Discussion isn't an indication of bad code, unless the only thing being discussed are mistakes.
That would be amazing, when your submission cause to improve the entire code base quality!
Just look at issues in software you use.
Start with a simple project. Clone the code and try to build it (this is already a very big step in software development, so don't be angry with yourself if it takes a while). Poke around in the code, change some stuff, get a feel for the architecture. Then see if there is an issue that you could help with. Ask questions on the projects communication channel(s). Most developers will be kind if you ask for help or advice.
Good luck! 🤞
There are (roughly) two types of projects:
-
Projects that have coding standards that are documented. If you want to contribute to one of these projects then read the coding documentation and follow it. People will help you write code that fits the standards.
-
Projects that don't have coding standards. When you look at such a project you'll see endless layers of shitty hacks that mostly work, sometimes. Add your own shitty hack to the pile and as long as everything still mostly works, you're good.
Seconding this and wanted to add:
It's more or less the repo owner's job to keep the codebase organized. So if they created a set of standards, follow them. If not, submit as clean a PR as you can.
Even without clearly defined coding standards, always try to match the style of whatever code you're contributing to. It may make your code stand out less, but will make it easier for everyone, even your future self.
As soon as you can solve an issue! I found a bug in a Yelp WordPress plugin back when I barely knew any PHP and figured out how to fix it, because I needed that plugin to get paid for the project I was working on. I submitted a pull request and they accepted it! That's the first contribution I ever made to a corporate project. The people in charge of the repository will give you feedback if they want things changed, and can provide a lot of guidance. Just start committing and you'll learn a lot.
Every problem looks impossible until you see the solution, and then it was obvious the whole time.
The feeling never goes away, instead you do what some other commenters have suggested:
- pick a project
- get it building locally so you can fix something
- pick a bug from the list
- get to work. Understanding what to write means understanding what the solution is, which means understanding the problem and the scope of it, what parts you can fix and what not. This process is more akin to going on a nature hike than painting the view, but people always seem to assume coding is more like the latter.
Tbh, you will likely be able to eventually solve any bug, given time and effort. Reaching out to discord groups in the language or product domain when you have questions will speed the process up.
When choosing a bug, if you start with one that is possible to reproduce, it might help following the instructions to reproduce it while debugging the app and observe what happens. This can be a way to start understanding how it all runs. Bugs without context or hard to reproduce are usually more complicated and you might need a better knowledge of the code to have an idea of where to look.
I have a feeling there are people far worse at coding than you being far more active in projects. If you don't start, will you ever?
How do I know when I'm ready to solve and commit to projects?
There are a few ways:
- You notice a problem, write some code, compile/run it, and it works. 🎉
- Download a project with some tests, set up the testing environment, do as per point 1, run the tests and keep fixing your code until they don't fail anymore. 🎉
- Do as per point 1, submit the PR... and many people will tell you whether you've missed something. Depending on their character, they might be helpful, ignore you, or rarely be assholes. YMMV. 🎭
- Fork the project. Now you're in control, so proceed as per point 1. To make your life easier, write some tests, set up a testing environment, make it easy for others to replicate, document stuff, both for you and for others, describe the general architecture to have a high level view of it, and so on. 🎉
Since you're asking, you're definitely not ready. Learn a projects formatting style for the code, work on open issue, submit patches, listen to all critiques and criticism.
Submit and the others will say when you're good. If you want to learn code correctness and proper security of code, study and go through OpenBSD's code. You could read the code for openNTPd and the code for OpenSSH, then move on to reading kernal code for OpenBSD.
In the sense I think you're asking, never: contributing a fix or an improvement is never a one-and-done, fire it off and forget it edit. Each contribution is a request to open a dialog. Implicit in each pull request are multiple questions, perhaps including "is this a good idea", and "do you like this attempt to do it".
If the project maintainer who reviews your PR doesn't like it, they can expend the effort to try to explain why, and teach you. So try to make their job easier, by opening with a clear explanation of why you're doing it, and if what you did involved design decisions, why you chose as you did.