3 ms·

> There are workflows which gasp do not mesh well with github. If we're discussing open source collaboration, it is hugely beneficial to NOT have your own uniq

by ef4 12y ago

> There are workflows which gasp do not mesh well with github. If we're discussing open source collaboration, it is hugely beneficial to NOT have your own unique workflow and instead adopt one that a large community of people are already using. In the time it takes to read your special "how to submit a patch" document, I could have already been done if you were using a de-facto standard workflow like Github's. This has a material impact on how much contribution you can expect to get from others. This is yet another case of Worse is Better. Ubiquity trumps perfection. I have heard it argued that making contributions harder to submit is somehow a good idea, because it keeps lower quality contributors out. This is very much mistaken, and even someone as cantankerous as Linus is on the record saying that encouraging more patches, even annoyingly naive ones, is in the long-term interest of the project.

hueving 12y ago
>I have heard it argued that making contributions harder to submit is somehow a good idea, because it keeps lower quality contributors out. This is very much mistaken, and even someone as cantankerous as Linus is on the record saying that encouraging more patches, even annoyingly naive ones, is in the long-term interest of the project. Yet Linux is not being developed on Github. Clearly the missing data in the github workflow is so detrimental that it's not worth the extra developers it might attract.
- ef4 12y ago
  > Clearly the missing data in the github workflow is so detrimental that it's not worth the extra developers it might attract. There is historical path dependence. Linux has changed workflows before, but each time it was controversial. I can see where it wouldn't be worth igniting a holy war. The more interesting question is what new projects should do. Even Linus puts new things (https://github.com/torvalds/subsurface https://github.com/torvalds/subsurface) on Github.

by ef4 12y ago

hueving 12y ago

>I have heard it argued that making contributions harder to submit is somehow a good idea, because it keeps lower quality contributors out. This is very much mistaken, and even someone as cantankerous as Linus is on the record saying that encouraging more patches, even annoyingly naive ones, is in the long-term interest of the project. Yet Linux is not being developed on Github. Clearly the missing data in the github workflow is so detrimental that it's not worth the extra developers it might attract.

ef4 12y ago
> Clearly the missing data in the github workflow is so detrimental that it's not worth the extra developers it might attract. There is historical path dependence. Linux has changed workflows before, but each time it was controversial. I can see where it wouldn't be worth igniting a holy war. The more interesting question is what new projects should do. Even Linus puts new things (https://github.com/torvalds/subsurface https://github.com/torvalds/subsurface) on Github.