Michael Nelson: Five Unspoken Rules For Contributing To Open Source Software
Published
November 28, 2017
Contributing to open source software can be frustrating for developers accustomed to working in isolation. That’s because you’re no longer just dealing with software, but with people who have their own biases, emotions, and agendas.
Some difficulties new contributors encounter include: not knowing when to contribute vs write companion software; not communicating meta information; disregard for etiquette; impatience regarding discussion; and ignorance of what makes contributions hard to accept for project maintainers.
This presentation will help illuminate some of the unspoken rules of contributing to open source software that will help you be a better contributor.
Event
Speakers
Tags
Language
Download
Subtitles
Subtitle this video →
An 
Creation
WordPress.tv 
November 28, 2017 at 5:29 am |
I disagree, and I might get hate for this but…
1) You can open a PR and run. A PR does not have to be merged, it’s not like something you’re showing at a trade fair, or selling. It’s not a marriage contract or adoption paper. It’s just a way of giving code back to authors & projects without overloading inboxes.
2) A PR is not always something you choose to do. Under some licenses, it’s an obligation to give code back! If you’re changing code to a project, it’s also just good manners to offer them your changes.
3) A PR being mainlined is not your obligation when you raise one! It’s not a puppy, a child, or any form of complex commitment.
However
1) Absolutely make it clear what is changed, and why
2) Your vision, or how you see it fitting in (or not)
3) Being mainlined is nice if
* You have time
* It’s important
* It’s going to someone without the skills to maintain
The reason is simple. It’s documentation of what you did and why. That’s it.
People need to be much less thin-skinned and reactive to terse input from those that don’t have time, or disagree with them. Rather than post to chastise them on issues, write a bot to point out contribution guides, code of conduct etc. If they are that busy, they’ll read one line and mark as read. The point is that it saves you time otherwise wasted because a bot can be there when you sleep, when you’re sick, or when you’re “not in the mood”. Also, the tone of a personal message can lead to the person raising the PR or issue blocking you, wasted time arguing, forming an opinion about you (this open thing works two ways).
Sometimes I’ll post an issue then post pertinent information, how it was fixed, or an enhancement suggestion. I’m not demanding your time, or coding skills, it’s just documentation so that someone other than me can see it, choose to contribute, or take notes. It’s searchable on Github, so it’s generally useful. Instead of closing, just tag with the default “wontfix” (blacklist) or only use a whitelist to browse issues (which shouldn’t be your backlog, but that’s another rant). Again a bot can do these things. Sometimes I’ll post a PR or Issue I have no intention of merging to mainline, or any action. It could be stop-gap fixes, internal, or things we advise clients against that they insist upon.
OSS is much richer than people are making it. Some are de-valuing software to make it work for them individually by enforcing it fits their personal bubble, assuming bad-intent, making up rules that are too narrow-band. Right now the response is to treat everything as SPAM, unwanted, not good enough. That’s more of a problem than ignoring.
LikeLiked by 1 person
November 29, 2017 at 9:51 pm |
Interesting insights lewiscowles2015… yeah I hadn’t thought about open source projects where the license requires you to contribute modifications back to the original project.
I also hadn’t thought about times when you have no intention of getting the PR merged into the project, but instead provided it as a type of record, saying “hey, I did this with it. Maybe it was good, or maybe it was bad. But either way, it’s more information to consider.”
My main point was that if you want a PR to be merged, and if you want to learn from the project maintainers, it usually takes more than pull-and-run.
I’m very unfamiliar with writing bots like you’re describing. Would you suggest any tutorials on that topic? Although I am personally not a fan of interacting with bots instead of people. But I can see how it may as well be a bot if the human would say the same thing…
> OSS is much richer than people are making it. Some are de-valuing software to make it work for them individually by enforcing it fits their personal bubble…
I don’t totally follow what you’re saying there. Are you saying project maintainers decrease a project’s value by requiring it fit their vision and their use-cases?
> Right now the response is to treat everything as SPAM, unwanted, not good enough. That’s more of a problem than ignoring.
That’s a good point too. So it sounds like your suggestion is project maintainers should write a bot to handle the easy, repetitive interactions, so that they have more time to more seriously consider more involved contributions. Is that right?
LikeLiked by 1 person
April 2, 2018 at 9:39 am |
Sorry I missed this https://github.com/alexellis/derek is an example from OpenFaaS maintainer Alex Ellis.
Also I was not saying maintainers are decreasing a projects value (too broad). Just that sometimes they could do with taking a step back from their notion of how it works. (Closing issues because something is out of scope for example).
LikeLiked by 1 person
November 29, 2017 at 2:05 pm |
Here is the blog post with the same content: https://cmljnelson.wordpress.com/2017/10/04/five-unspoken-rules-of-contributing-to-open-source-software/
And here is the original video I played during the presentation: https://www.youtube.com/watch?v=6cMjq0PbXR8&feature=youtu.be
LikeLiked by 1 person