Let's stop for a moment and think about what comes after platinum? Let's stop and think about who is your Mom's favourite child? The answer is Mahdi Yusuf. Nice to meet you. I am a software developer. P.S. I am sure your Mom loves us equally. Mahdi is a DZone MVB and is not an employee of DZone and has posted 16 posts at DZone. You can read more from them at their website. View Full User Profile

Code of Conduct: Open Source

12.17.2012
| 1902 views |
  • submit to reddit

I am writing this mostly out of frustration with developers. Hopefully this can shine some rules of conduct when discussing software on a medium like Github.

Being a developer, I understand that there are many things combating beautifully crafted software but thats the beauty of open source:

  • Your time.
  • Your release dates.
  • Your requirements.

Another beauty of open source is collaboration and collective effort to craft better software .

Responsibility

In my mind a group of people behind a project have a certain level of responsibility to the people who use their software, to those who potentially would like to contribute, and to those who contribute.

Contributors provide additions that improve the project as a whole and improve the use of the software for its intended audience and within the maintainer’s vision.

Maintainers

Recently I have seen my fair share of this type of action when it comes to pull requests being closed without dicussion or comment.

pull request

Your display of autocracy is fully within your right, but please don’t spare us of your banality. Say something, Why isn’t it a good idea? What can be improved for inclusion?

I would love to see this taken a step forward where maintainers outline what they think will be needed in the next release. Organized in issues with milestones, Github has all that is needed. So that contributors have clear places to contribute and to look for improvement.

Now an obvious counter argument is to say I can do it better myself, and it takes as much time to write the issue than to write the code. Not true, Linus does this quite effectively with the kernel albeit way more harsh with poor pull requests they still recieve his feedback.

Contributors

You have two options:

  • Maintain your own fork of the project.
  • Contribute to the collective.

Most people think if my change isn’t going to be accepted why should I improve the project. I don’t know maybe to solve problems you are having? If enough people voice that same concern maybe its worth contributing back. If not maintain your own fork. :)

That being said if maintainer has some stylistic choices for his project or general feedback be an adult and take the criticism lightly.

If it’s a big feature you want to write; talk to the maintainer first see if they have thought about it. Before you go and write all this code and have it rejected for reason X.

Also there are many ways to contribute to a project that many people overlook but are very much needed.

  • Testing (I have never seen tests get rejected)
  • Documentation.
  • Reviewing other Pull Requests.
  • Raising reproducible issues.

Conclusion

As maintainer we should be willing to accept and list where our software can be improved.

As contributors we should be willing to put the work in to conform with the philosophies and visions of the project we are contributing to.

Published at DZone with permission of Mahdi Yusuf, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)