How not to handle open source contributions

github.com

24 points·Illniyar··5 comments

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.

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.

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.

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

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.

Reply on news.ycombinator.com