Many engineers forget when contributing to Open Source projects that behind all projects we have people.
We don’t know the people on the other side (project maintainers) and how they will receive our contribution, this generates the need for communication to be clear, and we don’t assume that the maintainers (contributors) have the same knowledge as us (we have no way to know what other people have knowledge), even concepts that we find obvious is important to make clear in communication (issue, pull request and so on).
Don’t be attached to code — code is a way to get to the solution of a problem. It may be that your implementation of code or communication is not clear, do not take negative feedback to the personal side, in general contributors look at the implementation that is coming — but remember that this is not a rule, I cannot speak for all projects and/or people.
When you’re on the project maintainer side: look at each contribution as the best possible contribution from the person, they (the person who built it) have left their tasks to contribute to a project that isn’t theirs, try to understand why they had an affinity to the project — this will help you create a community (you’ll have help to maintain the project). One of the things that I think is “successful” is when you have a community involved with people with diverse realities and needs, it helps the project grow. Especially when we can give attention to new contributors, training leaders is essential to any project.
Good contribution my friends, I hope I have encouraged you to contribute with some Open Source project.
Portuguese version at avelino.run
