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 .
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.
Recently I have seen my fair share of this type of action when it comes to pull requests being closed without dicussion or comment.
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.
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 right 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.
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.