I agree that Github offers superb code browsing, and their issue tracker seems to be reasonably usable for small projects.
However, I fear that Github's issue tracker might not work at scale. I closely follow just one "large"[1] project that's hosted on Github; most of the developers on that project are accustomed to Bugzilla. Now I've never even used Bugzilla myself, but here are some things off of the top of my head that I remember them longing for:
1) The ability to attach files to issues.
2) The ability to denote dependencies between issues and generate dependency diagrams.
3) The ability to assign priority to issues (achievable using tags, but perhaps there's some advanced functionality I'm not aware of).
4) Ability for users to vote on which issues are most important.
5) Advanced search options (sometimes just having even basic search would be nice... half the time I have better luck searching their issues via Google than using Github's own search tool[2]).
6) A responsive web front-end.
The reason that they use Github's built-in issue tracker in the first place is because everyone and their mother has a Github account, so it lowers the barriers to entry for filing a bug report. And there's no question that they've benefited enormously from this, and the user-engagement that it enables. But the detriments to productivity are real, and the advantage of Github's network effect hasn't stopped them from repeatedly considering migrating their issues to Bugzilla.
And I don't think it would kill Github to abandon their "tags fulfill EVERY USE CASE" position and bake in some more features for advanced users, especially if they hope to capture a bigger share of the more "serious"[2] projects out there (which would only be to their benefit, considering that "serious" projects are the ones that are willing to buy paid accounts for all the users in their organization).
[1] "Large" in this case meaning: hundreds of Github forks, thousands of Github stars, hundreds of thousands of lines of code, a half-dozen full-time developers, and, most pertinently, several thousand issues (and growing at an increasing rate).
[2] Case in point: I just now tried to search for the issue wherein I offered to do the legwork of migrating their database to Bugzilla should it come to that. The title of the issue contains the word "Bugzilla". The text of the issue itself contains the word "Bugzilla" multiple times. Several of the comments contain "Bugzilla". And yet a search for "Bugzilla" using Github's issue search tool reveals only one issue, completely unrelated to the issue I was looking for.
[3] "Serious" in this case meaning: a codebase with hundreds of thousands to millions of users, dozens of full-time developers, and hundreds of thousands of issues.[4]
[6] While you're here, fun fact: I once went looking for the Github project with the largest number of total issues, and here's what I eventually settled upon: https://github.com/mxcl/homebrew/issues
However, I fear that Github's issue tracker might not work at scale. I closely follow just one "large"[1] project that's hosted on Github; most of the developers on that project are accustomed to Bugzilla. Now I've never even used Bugzilla myself, but here are some things off of the top of my head that I remember them longing for:
1) The ability to attach files to issues.
2) The ability to denote dependencies between issues and generate dependency diagrams.
3) The ability to assign priority to issues (achievable using tags, but perhaps there's some advanced functionality I'm not aware of).
4) Ability for users to vote on which issues are most important.
5) Advanced search options (sometimes just having even basic search would be nice... half the time I have better luck searching their issues via Google than using Github's own search tool[2]).
6) A responsive web front-end.
The reason that they use Github's built-in issue tracker in the first place is because everyone and their mother has a Github account, so it lowers the barriers to entry for filing a bug report. And there's no question that they've benefited enormously from this, and the user-engagement that it enables. But the detriments to productivity are real, and the advantage of Github's network effect hasn't stopped them from repeatedly considering migrating their issues to Bugzilla.
And I don't think it would kill Github to abandon their "tags fulfill EVERY USE CASE" position and bake in some more features for advanced users, especially if they hope to capture a bigger share of the more "serious"[2] projects out there (which would only be to their benefit, considering that "serious" projects are the ones that are willing to buy paid accounts for all the users in their organization).
[1] "Large" in this case meaning: hundreds of Github forks, thousands of Github stars, hundreds of thousands of lines of code, a half-dozen full-time developers, and, most pertinently, several thousand issues (and growing at an increasing rate).
[2] Case in point: I just now tried to search for the issue wherein I offered to do the legwork of migrating their database to Bugzilla should it come to that. The title of the issue contains the word "Bugzilla". The text of the issue itself contains the word "Bugzilla" multiple times. Several of the comments contain "Bugzilla". And yet a search for "Bugzilla" using Github's issue search tool reveals only one issue, completely unrelated to the issue I was looking for.
[3] "Serious" in this case meaning: a codebase with hundreds of thousands to millions of users, dozens of full-time developers, and hundreds of thousands of issues.[4]
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=800000 [5]
[5] Help I've gone mad with footnote power [5]
[6] While you're here, fun fact: I once went looking for the Github project with the largest number of total issues, and here's what I eventually settled upon: https://github.com/mxcl/homebrew/issues