I understand. I really do. I get nervous too when thinking about submitting the “ifs” and the “elses” to an existing open source project. Finding the time and the courage to submit code to an open source project is still difficult for me. Here are some opinions of mine that I offer to you. Hopefully it will help you along.
Find a problem
This one is simple. Really it is. The next time you are using some code that is open source and you happen to run into a bug, odd behavior, or some needed functionality, take some time and figure out if you have the ability to fix it or add some value to the project.
I recently found some strangeness in Guard. It was running my tests twice and after about fifteen minutes of work, I finally came to the conclusion that I needed to understand what was happening.
I spent some time tracing what Guard was doing and realized that if my Guardfile had duplicate definitions, it would run for every one present. For me, this was no bueno.
Evaluate the community
Know your skillz
I cloned the Guard code base and took a look around. I could see that it was a solid project but it didn’t smell of elitism. I felt that my talent was up to the task of contributing as it didn’t appear that super-duper-primo pull requests were required right out of the gate. I prefer this, because you can get your ideas merged, and then refactor them later once the idea is vetted.
Validate the issue doesn’t exist
My buddy Matthew Turland points out that newbies should take the time to check issues/PRs to ensure that a fix hasn’t already been submitted as you don’t want to duplicate work.
This basic project reconnaissance helped tell me that my potential contribution, if not included, would be at the very least appreciated.
Be a polar bear
When it comes to the code I submit, I’m totally open to “eating my young” and assume that any code I write is just one turd shy of making a full toilet. Detaching myself from any emotion concerning my hackery will leave me in a much better position to grow.
Don’t be a douche
It may go without saying, but here it is again. When submitting a bug or pull request, I always try to be polite. Even if upon my communication, I realize that the community I’ve engaged is completely full of dicks. At that point, I politely exit the conversation and never go back to the project. I don’t Facebook or Twitter the community’s douchery. Seriously, humbleness is a virtue here and is a better approach. My time is better spent on finding a community that will accept me, rather than hating one that won’t.
Follow community guidelines
Since this is my first interaction with @thibaudgg and Guard, I went into a lot of detail with the issue. I tend to do this by default. But it helps articulate to the community that I spent time understanding and verifying what I’m trying to accomplish.
In my submission (pull request) I included what I felt the problem was right at the very top of the post. But I concluded with the value proposition. Articulating that by including my feature, it would help the project achieve (X).
In this case, my code was appreciated and accepted. Which is a great feeling when you get to be included in something. Even when the contribution is small.
However, when I get rejected, I tend to ask for suggestions on what it would take to get my code or idea included. Asking for advice or help is surprisingly a skill that many people suck at. I can only assume because many people’s egos don’t allow for them to be wrong. Too bad for them. Because by embracing my failure I get a world of value out of it in the form of friendship and learning. People will willing teach me things for the incredibly cheap price of simply admitting I don’t know the correct answer and then asking for their help.
It is the continual hustle in the face of rejection that needs encouragement, especially when you strike out. Track down the people that praise the hustle. And if you need some support find me on twitter and I’ll give you a high five and do whatever else I can to further your success. I’m happy to help.