GitHub and my open source life

I agree completely about revisions on PRs. Also, proposed patches often spawn much broader technical discussions that are much better on a mailing list than on a random commit (that will likely become unreachable later since it's not going to be accepted). Nothing beats the archival quality of mailing lists and if you start your code review there, you never need to make the choice to "move" a discussion from GitHub to a mailing list. The problem is that mailing list review requires a lot of discipline and some popular MUAs make it especially painful.

The value of PRs and other models is that they degrade more gracefully to lack of experience/discipline, and (perhaps) to casual involvement (subscribing to mailing lists with delivery turned off is fine as long as there is a convention to Cc people that are likely interested in a specific change; not many people know about subscribe-without-delivery).

I am a huge fan of Gerrit, other than its UI. I ran it along with Jenkins[0] at a previous company. Its review model is far, far, far superior to Github's. As you said, it keeps successive patch sets, and allows for diffs against previous patch sets, rather than only against the original parent. This allows for you to see only the most lastest changes, so you don't have to wonder if anything else was changed and review the entire patch.

> $ git review

I actually wrote a bash script with the same name and a few other shortcuts before my company started working on OpenStack. I was quite pleased with the workflow I provided the team I was on.

  $ git start <new-branch> <branch-from>
  $ <do work as normal>
  $ git review
  $ git finish  # removes the branch

These three commands along with the git-flow branching model[1] (but not the tool itself), leads to clean, sensible history in my opinion.

I respect that Github tries to maintain a low-barrier of entry to increase use and ease, but I believe there's a way to maintain it while still having a great patch-review model.

0: http://jenkins-ci.org/ 1: http://nvie.com/posts/a-successful-git-branching-model/

I type out the instructions on how to squash a pull request so often that I just posted it to my blog, so I don't need to type it over and over: http://blog.steveklabnik.com/posts/2012-11-08-how-to-squash-...

That said, I do like pull requests: you might lose the history locally, but the PR contains a 'see outdated diff' that shows what it used to look like.

I'm using GitHub more and more — ultimately because so many more developers are willing to submit patches there than elsewhere (presumably — at least — because they already have a clue what they're doing, rather than having to work out how to submit something).

In the end, what I've ended up doing is using Travis CI with its GitHub hook, which gives the whole suite of tests against each and every patch, as well as using external code review (mostly using Critic (https://github.com/jensl/critic), which supports explicitly rebasing branches, collapsing reviews into all pending commits, and so on, all gracefully — unlike GitHub's code review).

While I'd like something better, the issues it throws up (not using the default code review system most obviously) as well as — as you say — the complexity of submitting a PR, are, in my opinion, outweighed by the extra contributions that are got by using something other developers are already comfortable with.

A coworker and I recently discussed how Github ought to invest some time into templated workflows. Conventions like "make a branch per pull request" can be mandated by a repo owner, as could "rebase all your commits". At minimum, providing a TODO list for pull request submissions would be good.

> When I ask people politely to rebase all the commits they're sending into one, most don't know how to do it.

Very easy solution to this problem. 1) Make note of it in CONTRIBUTING.md. 2) Do it for them. Check out their branch, rebase/squash/fix whitespace/etc and merge.

Do you (or anyone else) have a link to this alleged Torvalds rant about PRs?

I have mixed feelings about the idea that all contributions should be squashed. I see the attempt at fastidiousness, but I also think that git makes it very easy and reasonable to keep multi-change history while linking it to only one commit in the eventual target repository.

I do wish it was easier to rebase a branch such that backmerges were pulled out where possible, cleaning up the graph at least, but I tend to look at my soup branch (master, usually) with git log --first-parent most of the time anyways and that's not much different from if they'd been squashed.

"My rule of thumb: If you have more than 10 contributors, at least 4 of which are active daily, it may be worth it to invest in some real infrastructure."

Disclaimer: I'm the creator of GitSense. We are working on a solution to make GitHub pull requests enterprise ready.

I do agree that GitHub's pull request model is not quite enterprise ready, but they have a solid foundation that you can build on top of. With their API, were able to build a solution that I believe will address most of its short comings.

For example, my first concern with GitHub's pull request system, is it is at the repository level. With Gerrit, you can see requests at the branch level. With our enhancements you'll be able to track pull requests from different repositories at the branch level:

http://screenshots.gitsense.com/enterprising-github-pulls.ht...

We are also able to address the concern of dealing with new commits. With our Smart Attributes technology, it is very easy to flag what commits you have reviewed.

http://screenshots.gitsense.com/enterprising-github-pulls.ht...

And then refine the list so you'll only have to deal with the newer commits.

http://screenshots.gitsense.com/enterprising-github-pulls.ht...

We also take care of the problem of not having a side by side diff. With our solution, you'll be able to use side by side diffs to review pull requests.

http://screenshots.gitsense.com/enterprising-github-pulls.ht...

I don't have a strong opinion about this particular thing, but it seems like a decent idea.

But let me speak more generally.

Sometimes it seems like some people have a very "logical" way of looking at ideas. It's like every idea is interpreted according to some metaphysical schema and judged by whether or not it's conceptually harmonious and untainted.

In this case, the schema is "equality," which ironically means that any concrete idea that addresses disparity is prematurely judged as faulty or tainted.

It's stunningly obvious that the open source community is dominated by males, even if it's not more so than the programming community at large. This is a matter of statistics, it's not complicated. This paper http://jitm.ubalt.edu/XXI-4/article3.pdf cites a figure of 1.5% OSS developers being women, which doesn't seem entirely implausible.

This simple statistical fact should mean that some women who do want to pursue an interest or career doing open source work might indeed have use for the kind of thing we're discussing. So why not?

There IS a disparity between genders in tech. This is so obvious. Why on earth would you call this an unbased idea?

That there is a disparity doesn't mean that there is an "essential" or "necessary" disparity. It just means that at this point in human history, women are extremely underrepresented in this particular section. In that situation, it seems more than appropriate to set up various measures to support diverse engagement.

I would say this is a great idea for the same reason having more minority male english teachers in minority schools is a great idea. For whatever historical reasons, certain groups are underrepresented. This snowballs when youth try to get a foothold into the field, since they see no one like them succeeding. Is it logical to have more confidence (a huge indicator of success in just about anything) when the teacher looks like you? Probably not, but that does not stop it from being effective.

People say that they want more diversity in tech. Perhaps ironically many also go to great lengths with proudly proclaiming how nerdy they are, and building a whole subculture that is heavily associated with fields like programming, science, etc.

If they want more women in order to get more diversity in the field, why are they so deeply entrenched in and identify so strongly with a specific subculture? Is the goal really to have a diverse array of people in the field? Or is it to get yet another "I'm such a nerd!", only with different genitals?

Not completely contradicting you, but just pointing out- they've open sourced a lot of stuff:

https://github.com/github

That is true, but they do that so they can continue to serve their business easily. Would you rather them be open source and take away all the free hosting? Furthermore, they are easily the best product in their category. If you want an open source Git Service, use gitorious or something.

It may be easiest to look at small projects you are already using (but want to fix something... or just, write better documentation, which may be the best start).

There's no reason to invoke No True Scotsman here. There are valid justifications for both open-source development (as described in the article) and closed-source development (e.g. IP).

Why should people have to work for free? I have a skill, I expect to get paid. I don't see my plumber doing pro bono work at the weekend.

Not everyone has to adhere to your philosophy. You license your code for me to use, that's your prerogative. Don't complain when people don't give anything back.

Can you give context what is Tapbots and why should they OS/contribute their work?

Contributions to open source projects are like gifts: you shouldn't take them for granted, and particularly you shouldn't expect them as a baseline.

The true hacking ethos is one about creation and isn't specific to code.

writing, i assume?

I'm totally hacking this comment.

It's probably more of a joke than any pretentiousness...

I don't actually know what "hacking code" means, either.

A hack writer is a term that massively pre-dates the usage of the word hack in technology, often used to describe journalists or pulp novelists, so I would assume that it is a deliberate play on words marrying more than one meaning of hack.

Which would also mean that the term "hacking text" in this context is itself a bit of a hack.

...

edit - I went for a look at old uses of the word hack as it pertains to writing and found that there is another variation in meaning, that of "hack words".

Here it is in use from the 1858 periodical, "The Ladies' Companion", in a passage that as chance would have it is discussing the creative usage of words -

"Of the influence which German literature Jean Paul and others has had on Carlyle enough has been said elsewhere. This influence certainly shows itself markedly in his style though by no means detracting from its originality.

It has given to him a somewhat burdensome richness of compound words and a few unfamiliar derivations. He is fond of seizing upon the primary meaning of a word and bringing out that meaning forcibly by contrast and repetition. He introduces innovations of foreign words to a great extent and not unfrequently uses simple ones in an obsolete or new sense.

These may be looked upon as faults but it will be found that his foreign introductions are mostly from languages which form the basis of English having an affinity to accepted English words and that they invariably have a peculiar significance which could not have been given by more common expressions. His obsolete or new senses too show generally an evident reason for their adoption.

He is fond of hack words - a kind of slang of the day; for instance, "sham", "jargon", "gigmanity". He uses such words as watchwords of the time wherein he writes, as bearing in them a nineteenth century view of things."

from here - http://books.google.co.uk/books?id=gLIRAAAAYAAJ&dq=%22hack%2...