4 ms·

As an open source author, I prefer to discuss features with people after they send their first patch. GitHub allows me to sort potential contributors into 3 cat

by ekidd 16y ago

As an open source author, I prefer to discuss features with people after they send their first patch. GitHub allows me to sort potential contributors into 3 categories: 1) Programmers who talk a lot without sending patches will be gently discouraged by the lack of a forum. 2) Programmers who send dirty patches, or who don't write unit tests, can be given some quick mentoring and asked to please resubmit. 3) Programmers who send clean patches with unit tests and well-written commit messages can be welcomed with open arms and fulsome praise. If you're a UI/UX expert, or a designer, then please substitute "blog post with pictures" for "patch". All types of skills are valuable.

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.
tzs 16y ago
As a programmer who has way more things to do than I have time for, no way am I just going to go off and code a patch for your project without first finding out if you'd be receptive to it. I'd feel like I wasted my time if I sent you a patch that was clean, had tests, and otherwise met all your requirements, but you rejected it because my proposed feature doesn't fit in with your philosophy of how the program should work, or if it turned out you were already coding that feature and your code was far enough along that you preferred to stick with it than switch to mine.
- ElliotH 16y ago
  I think Open Source development works a lot better where people implement features/fixes that they themselves want/need, at least for the first few patches. This way, you haven't wasted your time by writing the code to scratch your itch because, even if it is rejected, you can still patch your own version and have the feature you want.
  - shadowfox 16y ago
    > even if it is rejected, you can still patch your own version and have the feature you want One longer term issue there is that you are now stuck maintaining this code through any changes the upstream authors choose to make in the future (if you really want this feature that bad)
- ekidd 16y ago
  As a programmer who has way more things to do than I have time for... I think this is a perfectly fair response. Good patches take me about 10 seconds to merge, and bad patches take me 20+ minutes, because I have to (1) understand what they're supposed to accomplish, (2) write unit tests, and (3) rewrite the code. In a case like that, it's usually a waste of everybody's time. In general, when I start contributing to a new project, I begin with a bug fix, and include both unit tests and a detailed commit message. Then I plan on rewriting it at least once, because the upstream project has perfectly valid constraints that I don't understand.
grandalf 16y ago
To be fair, I've submitted a variety of pull requests that have been ignored... no comments, no response, etc. At least with the pull request format, if the author is too busy to maintain the project he/she could theoretically just accept requests and spend about 2 minutes a month being maintainer.
KaeseEs 16y ago
'fulsome' means the opposite of what you think it means.
- jholman 16y ago
  "Fulsome" means "abundant". I think that was correct, from the context. The fact that it is often used sarcastically only means that you need to determine from context whether it's sincere or insincere. I think it was clear, in this context. http://en.wiktionary.org/wiki/fulsome http://en.wiktionary.org/wiki/fulsome
  - KaeseEs 16y ago
    That's not the most common usage listed; the most common, which also happens to match the fixed phrase you used, is "offensive to good taste", the second most common is "disgusting, sickening, repulsive", the third most common is "insincere", cf. http://dictionary.reference.com/browse/fulsome http://dictionary.reference.com/browse/fulsome
    - jholman 16y ago
      1) The phrase that _I_ used? When did I use it? 2) Okay, fine, we'll use YOUR reference instead of MINE, even though they basically say the same thing. What they say is that there are multiple meanings, and some of those meanings are the opposite of one another. In situations like that, the reader gets to work it out. It's not a case of having simply used the word wrong, as you claimed. In fact, both dictionaries (wikt, dictionary.com) specifically mention this in their usage notes. So why are you citing a source that agrees with me? Scroll down in the link YOU chose, to where Collins Dictionary senses 2 and 3 are consistent with the OP's intent. Scroll down in the link YOU chose, to where the Online Etymology Dictionary says that for 50 years now it is coming back into fashion to use it in the original sense of "abundant". If you're a descriptivist, then the fact is that people use it this way. And if you're a prescriptivist who prefers original meanings, then use the original (15c) meaning. Prescriptivists who only know about 100 years of history are only fooling themselves. Don't get me wrong, I'm all for pedantic corrections, it's a bad habit of mine too. But only when they're correct. You said "ekidd, you're using this word wrong", but actually, ekidd's usage was perfectly valid, as even your source of choice admits.

by ekidd 16y ago

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.

tzs 16y ago

As a programmer who has way more things to do than I have time for, no way am I just going to go off and code a patch for your project without first finding out if you'd be receptive to it. I'd feel like I wasted my time if I sent you a patch that was clean, had tests, and otherwise met all your requirements, but you rejected it because my proposed feature doesn't fit in with your philosophy of how the program should work, or if it turned out you were already coding that feature and your code was far enough along that you preferred to stick with it than switch to mine.

ElliotH 16y ago
I think Open Source development works a lot better where people implement features/fixes that they themselves want/need, at least for the first few patches. This way, you haven't wasted your time by writing the code to scratch your itch because, even if it is rejected, you can still patch your own version and have the feature you want.
- shadowfox 16y ago
  > even if it is rejected, you can still patch your own version and have the feature you want One longer term issue there is that you are now stuck maintaining this code through any changes the upstream authors choose to make in the future (if you really want this feature that bad)
ekidd 16y ago
As a programmer who has way more things to do than I have time for... I think this is a perfectly fair response. Good patches take me about 10 seconds to merge, and bad patches take me 20+ minutes, because I have to (1) understand what they're supposed to accomplish, (2) write unit tests, and (3) rewrite the code. In a case like that, it's usually a waste of everybody's time. In general, when I start contributing to a new project, I begin with a bug fix, and include both unit tests and a detailed commit message. Then I plan on rewriting it at least once, because the upstream project has perfectly valid constraints that I don't understand.

grandalf 16y ago

To be fair, I've submitted a variety of pull requests that have been ignored... no comments, no response, etc. At least with the pull request format, if the author is too busy to maintain the project he/she could theoretically just accept requests and spend about 2 minutes a month being maintainer.

KaeseEs 16y ago

'fulsome' means the opposite of what you think it means.

jholman 16y ago
"Fulsome" means "abundant". I think that was correct, from the context. The fact that it is often used sarcastically only means that you need to determine from context whether it's sincere or insincere. I think it was clear, in this context. http://en.wiktionary.org/wiki/fulsome http://en.wiktionary.org/wiki/fulsome
- KaeseEs 16y ago
  That's not the most common usage listed; the most common, which also happens to match the fixed phrase you used, is "offensive to good taste", the second most common is "disgusting, sickening, repulsive", the third most common is "insincere", cf. http://dictionary.reference.com/browse/fulsome http://dictionary.reference.com/browse/fulsome
  - jholman 16y ago
    1) The phrase that _I_ used? When did I use it? 2) Okay, fine, we'll use YOUR reference instead of MINE, even though they basically say the same thing. What they say is that there are multiple meanings, and some of those meanings are the opposite of one another. In situations like that, the reader gets to work it out. It's not a case of having simply used the word wrong, as you claimed. In fact, both dictionaries (wikt, dictionary.com) specifically mention this in their usage notes. So why are you citing a source that agrees with me? Scroll down in the link YOU chose, to where Collins Dictionary senses 2 and 3 are consistent with the OP's intent. Scroll down in the link YOU chose, to where the Online Etymology Dictionary says that for 50 years now it is coming back into fashion to use it in the original sense of "abundant". If you're a descriptivist, then the fact is that people use it this way. And if you're a prescriptivist who prefers original meanings, then use the original (15c) meaning. Prescriptivists who only know about 100 years of history are only fooling themselves. Don't get me wrong, I'm all for pedantic corrections, it's a bad habit of mine too. But only when they're correct. You said "ekidd, you're using this word wrong", but actually, ekidd's usage was perfectly valid, as even your source of choice admits.