
How not to handle open source contributions - Illniyar
https://github.com/angular/angular.js/pull/4694#issuecomment-327013707
======
yesimahuman
I give Angular the benefit of the doubt having been on the other end. It's
easy to just merge PRs. It's much harder to make sure those contributions fit
a bigger vision, don't break existing code bases, work in a backwards
compatible way, are documented and expose proper public API's etc. It's risky.
Should they have reviewed it earlier? Perhaps, but that's easy for us to say.

~~~
Illniyar
I haven't been on the other end, so I don't have first hand knowledge but it
seems to me that it's far easier to dismiss contributions because you didn't
make them or they don't fit into your careful plan then giving up complete
control and cultivate a strong contributor community.

All the reasons you ascribe to it aside from "documented" aren't applicable
here. The feature was in the bigger vision, it was well tested, backward
compatible, etc...

The only reason touted for not accepting it is that they wanted to get another
feature in first.

------
Illniyar
4 years after the original pull request was more or less denied because of
"we'll do it as part of a bigger thing" the angular team asked the contributor
if he is willing fix conflicts and merge again.

I think it's really the worst way you can handle open source contributions,
and it actually typical of the angular team behavior.

~~~
Sujan
How else should they handle it now? I see no real alternative.

~~~
Illniyar
Merge it themselves and thank him, or write the implementation they wanted
originally and ignore the commit. Asking the guy to come do the work after
they rejected him 4 years later is extremely rude.

