[willthames]

This seems illuminating.

"The only complaint that I have here [about Salt] is that they are sometimes less rigorous than they should be when it comes to accepting code (I’d like to see more code review)."

Keeping high quality across a project requires discipline. And that discipline can sometimes seem cold.

"pull request welcome" is at the warm end of the spectrum.

[mpdehaan2]

Yeah I don't think we've ever meant "pull requests are welcome" as a "screw you guys!". We actually mean it's welcome.

When we don't want something, it's more like "I don't think we are interested in that feature".

The big green web merge button on Github is a scary beast, and if we risk a few users for stability and taking our time, I'm cool with that. I think a lot about running a successful project is working with a contributor and helping them get the pull request into good shape.

Those that can deal with the process and power through it become better contributors for later.

We want to very much avoid being Wikipedia, while still being a canvas for massively widescale contributions.

anyway, stability to us is very important. Security and usability (and docs) are important. Those things come first before we take on new features.

Will and I disagree from time to time, but in the end, we're both way better for it, and he keeps me honest.

Anyway, for those reading the article - read all commentary, and try both. Try Puppet and Chef too. If you like Ruby, you might really dig Chef even, and we're ok with that. It's all good and there's plenty of users to go around :)

[geerlingguy]

And in my experience, submitting a well-reasoned, simple pull request to add a small change or fix a bug always results in a merge.

As someone who also maintains a few (much, much smaller) OSS projects on GitHub, I really understand the 'no' mentality. It's often much harder to say no, but usually I try to put it in a positive way (yes, this is a worthwhile idea, yes, it looks like it could help in this situation, but no, I won't be merging it because I don't think most of the project's users would benefit from its inclusion).

[mpdehaan2]

Yep, we definitely try to.

Part of the difficulty comes from the dynamic changes of GitHub. 10 years ago, usually folks would discuss a change prior to submitting code.

Now, it's more common for someone to assume code is wanted, and then it's easy to be a little disappointed when you find an upstream would want it implement differently.

In all though, GitHub has done wonders for standardizing contribution processes.