3 ms·

> As an open source author, I prefer to discuss features with people after they send their first patch. Sure for the developer that is easy, but I don't feel w

by antirez 16y ago

> As an open source author, I prefer to discuss features with people after they send their first patch. Sure for the developer that is easy, but I don't feel well when I think at all the wasted work. Imagine running a company this way... Or compare the two models in this very real world scenario: "that's my patch, looks good?", "no sorry it was already a work in progress and is almost finished". With instead "what about adding this feature?", "it's already in the workings, thanks, but we could like to have that if you like to contribute". But perhaps your open source project has a different nature compared to Redis. Being Redis composed of commands and data types, it is very similar to a programming language. And if you think about evolving a language in this way, via pull requests, it is easy to realize how this can't work. It's a lot more about design.

rmetzler 16y ago
I guess it wouldn't harm to state the patching policy inside the README file.
- antirez 16y ago
  In Redis we have a "CONTRIBUTING" file in 2.2 and unstable where this is stated very clearly.
  - rmetzler 16y ago
    +1 Adding a license and contribution policies to an open source project are great preconditions to get bugfixes and feature contributions. But I wonder why then sending you pull requests is an issue?
ekidd 16y ago
Perhaps I was overly harsh. :-) Different projects have different needs. Some projects work best with a small number of designers and core contributers, and a larger number of people who submit an occasional bug fix (or good bug reports). In a project like that, bringing a perspective contributor on board can take several hours of my time. If I tried to invest that time for everybody who said, "Hey, I'd like to implement feature X" or who sent a dodgy patch, I'd never make any forward progress. So in self-defense, I now encourage people to start by contributing a small, simple patch. That gives me a good idea of how much time I should invest on bringing them up to speed. Imagine running a company this way... Essentially, a potential contributor's first patch is a job interview. Once they demonstrate that they can help the project, then it's worth spending a lot of time with them. But even in interviews, I want to see code.
jfager 16y ago
I think it's a bit paternalistic to be concerned about this because of "wasted work". One of the best ways to learn about a piece of code is to start hacking on it, regardless of whether or not any changes you make or features you add will be needed or wanted by the upstream project. If someone does the work unsolicited and then complains that you're not merging it, that's a problem, sure. But otherwise, you shouldn't feel bad about what other people choose to do with their own time.
jerf 16y ago
Hmm, "the sum of all wasted work by proven developers dealing with people who have no intention of following through" vs. "the sum of all work wasted by people who follow through to some extent and don't get their patches accepted for some reason"... honestly, it's a tough call which is larger even on a straight-across time comparison, even before we account for the fact that the first group of people are getting more productivity per hour.

by antirez 16y ago

rmetzler 16y ago

I guess it wouldn't harm to state the patching policy inside the README file.

antirez 16y ago
In Redis we have a "CONTRIBUTING" file in 2.2 and unstable where this is stated very clearly.
- rmetzler 16y ago
  +1 Adding a license and contribution policies to an open source project are great preconditions to get bugfixes and feature contributions. But I wonder why then sending you pull requests is an issue?

ekidd 16y ago

Perhaps I was overly harsh. :-) Different projects have different needs. Some projects work best with a small number of designers and core contributers, and a larger number of people who submit an occasional bug fix (or good bug reports). In a project like that, bringing a perspective contributor on board can take several hours of my time. If I tried to invest that time for everybody who said, "Hey, I'd like to implement feature X" or who sent a dodgy patch, I'd never make any forward progress. So in self-defense, I now encourage people to start by contributing a small, simple patch. That gives me a good idea of how much time I should invest on bringing them up to speed. Imagine running a company this way... Essentially, a potential contributor's first patch is a job interview. Once they demonstrate that they can help the project, then it's worth spending a lot of time with them. But even in interviews, I want to see code.

jfager 16y ago

I think it's a bit paternalistic to be concerned about this because of "wasted work". One of the best ways to learn about a piece of code is to start hacking on it, regardless of whether or not any changes you make or features you add will be needed or wanted by the upstream project. If someone does the work unsolicited and then complains that you're not merging it, that's a problem, sure. But otherwise, you shouldn't feel bad about what other people choose to do with their own time.

jerf 16y ago

Hmm, "the sum of all wasted work by proven developers dealing with people who have no intention of following through" vs. "the sum of all work wasted by people who follow through to some extent and don't get their patches accepted for some reason"... honestly, it's a tough call which is larger even on a straight-across time comparison, even before we account for the fact that the first group of people are getting more productivity per hour.