For quick/simple patches, I find the pull-request approach to be way less hassle. As much as I value the open source process, I simply can't be bothered to join the mailing list, post, wait for a reply etc etc for every project I write a trivial patch for, especially if it's a project I'm not planning to hack on a lot. Life's too short.
At least this way, if the project authors want my patch, they can get it easily. Otherwise I'm happy for it to just sit in my fork.
Common sense is required - sending a pull-request out of the blue for a large or structural change is asking for trouble. For trivial patches it's very convenient.
But the kind of pull requests I receive are often fairly large. New commands implemented or other large changes.
It's not even so much the size of the patch, but rather how much it gets into the design, I think. If someone sends a largish bugfix patch that doesn't touch design then that seems ok to me. Even if you don't like the actual patch, you'll probably do your own similar (but correct) patch.
But sending even a smallish patch that messes with design would have been better with discussion first. Even small tweaks to architecture, API/ABI, UX, etc. need careful consideration.
This workflow is natural to me:
1. Someone reports an issue
2. A patch is provided
And if someone sends a pull request (without opening a ticket first), what should I do if I agree with the feature/bugfix, but not with the way it was solved? The issue isn't fixed yet, so it's wrong to close it, but it feels weird to keep the pull request open (since I've actually rejected it). I want to close the pull request only!
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.
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.
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.
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.
But I wonder why then sending you pull requests is an issue?
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.
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.
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)
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.
Pull requests are also not bug tickets. We'd prefer that you ask on the forum if you'd like to discuss feature changes, or file a ticket (http://docs.jquery.com/How_to_Report_Bugs) in the bug tracker.
GitHub's pull queue doesn't provide a lot of control, which makes it less than ideal as a first-contact mechanism for a busy project. Requests can only be opened, closed, and sorted by three relatively weak criteria. That's one reason why we prefer to use the bug tracker for managing things, we have a lot more options for reporting and prioritizing there.
The best bug reports are pull requests:
It was just another post around the same subject from an equally hardcore NoSQL hacker.
Before GitHub, these sorts of projects were announced on IRC, and were then discussed on IRC, so that everyone participating had a better idea about what direction the core developers wanted the project to be taken in. This made it more likely that pull requests were for features/bugs that the project team actively wanted people to work on.
GitHub is missing this kind of environment, so it's almost inevitable that first contact between maintainers and potential contributors usually comes in the form of a pull request.
I think the real solution here is for Github to add a feature where pull request notifications can be sent to arbitrary email adresses (though you can probably hack around this today). This way, if the project does have a mailing list, and prefers to discuss pull requests there, then the mailing list is not out of the loop.
I understand what you mean about the majority of mailing list discussions not starting with a patch though. On github, it would be nice if you could attach a pull request to an existing issue (last time I tried this it didn't work).
Perhaps "pull request" is a bit of a misnomer? Technically speaking it's correct, but if the idea was more that you can interleave patches with a discussion, maybe it wouldn't seem so unpalatable to your way of working. If the discussion doesn't end up merged into "master", just close the issue in question as "wontfix" or similar.
These projects are generally smaller than redis though :-)
It's also where design decisions are recorded so that people can come along and read about them in the future.
Excellent article: it points out one of the things I don't like so much about people's use of github, in a constructive way.
Git-backed wiki how-to: My "wikis" currently simply are HTML pages served by gitweb right out of the repo, however I am experimenting with gollum and smeagol. That is: if your repos are on some server of your own, not github. I have no exprience with github and won't be caught dead using it.
- Should it be out of service for a long time, I'd have to move to a different server and risk losing contacts that only know me by my github name/URL.
- Most importantly: On my server I have repos that are more open that 'private' but less open than 'public'. E.g. I hand out invites to a repo to attendees of a meeting. Or I limit by location using geo-IP.
Posting a changelist for review also posts to the dev mailing list for discussion and approval.
What do you do when the only response is "use the alternatives" and they just plain don't work the same way?
Or if this happens too often and you are truly convinced that this should not be the case:
code code code -> open a mailing list -> fork the project.
if you are right the original developers will eventually merge everything and there will be again a sigle project handled in a bit less dictatorial way.
Github is a great tool used this way.
For instance instead of polluting the thread about the design with a stupid thing about: "you could also check this other syscall" that's better served by an inline github comment.