"Github is the ultimate no-bullshit company. Any new announce is about some good feature or small improvement that matters"
It's funny that you should say this, because I have pretty much the exact opposite impression. Most of their feature announcements are for dubious changes that don't make my life better (web-based CLI? Stars-vs-followers?), but more to the point, they've left really important things to languish (for example: their code search sucks, and their issue tracking system is just barely usable.)
I don't get the sense that GitHub is rowing in the same direction as a company. Their product isn't improving in any consistent way, and for all of the changes that they announce, I'm having a hard time of thinking of the last one that made a positive impact on my life. Certainly, I've never before needed to create a file in github via the web, and I probably never will.
Well I guess here it is really about tastes because I think the bug tracking system is one of the best features of the site.
The feeling you have of them not moving in the right direction probably is about their development model where internally people think at improvements and submit a pull request or something alike, but I guess they also have some long term projects that try to pursue as a whole.
But well the real point here is that we are talking about different things. I mean, you may not be happy with what they accomplish and I may be happy instead, but the company is in general focused into evolving their product while not annoying users.
"I think the bug tracking system is one of the best features of the site."
It's a fantastic tool for avoiding annoyance with bug reports by losing track of tickets. It's perfect for that.
Seriously, though: any ticketing system that doesn't have a way to assign and sort by priority is just fundamentally broken (and no, tags don't count). But almost everything about the usability of the thing is goofy: bulk updating allows you to inadvertently delete tags (oops! hope you didn't need those!), you can't filter based on assignee, and it's easy to get stuck in a view where managing/filtering tags is impossible, with no indication of how to get to the useful interface again (why do they even have a view like that?)
But truth be told, I recognize that GitHub isn't an issue-tracking tool. That's fine. I have these sorts of complaints about nearly every part of the web interface. It's gotten to the point where I avoid using the web UI whenever possible -- it's just a hosted git repo, nothing more. And given that the product is little more than a UI wrapper around git...well, I feel like these are pretty core problems for a user-focused team. So what are they focusing on, anyway?
This is definitely a taste thing. I've worked with issue systems that support priority in the past and found them frustrating - I much prefer being able to invent my own concept of priority using tags (which is exactly what we've done using GitHub issues). I also find the web UI a joy to use, and frequently refer to it over using command-line or desktop git browsing tools.
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
I think that the stars vs followers update was far from useless. That improvement was absolutely fantastic.
I (and I assume lots of other people) were following repositories because they liked them, the same way someone might bookmark a page because they liked it. But this meant they got every commit and issue update for lots of projects, which was unnecessary clutter.
Github realized this and made a distinction between liking a repository and actively following its every change.
The stars/followers update says a lot about how good Github is at stepping back and looking at the user experience as a whole.
"The stars/followers update says a lot about how good Github is at stepping back and looking at the user experience as a whole."
Ehh...it says that a lot of github's popularity is amongst people who do things like "following repositories because they like them", without actually being interested in the details of the projects they "follow". (Meanwhile, the rest of us are over here bookmarking webpages with our bookmark button, and trying to use GitHub to write code, and finding the system lacking...)
I've never "followed" a repository, unless I actually wanted to, you know...follow the repository. But you do raise a good point: GitHub lives in this weird hybrid world that's grown well beyond a simple tool for writing code. Nowadays, much of their user base is there because they think it's everything from a social network, to a blog host, to an online resume. It's probably not surprising that they've lost some focus.
> it says that a lot of github's popularity is amongst people who do things like "following repositories because they like them"
Yes, why not? I'm happy to star the repo which has the code my phone is running, just for later references. It might be far from the most useful feature at github, but what does it tell about me? Why are you being mean, if I may ask?
> Meanwhile, the rest of us
You and parent and maybe grand parent use this "rest of us". What does it mean? That you need to bring with you the "rest of us" (your team, your friends?) to make a point.
Mind you, under the hypothesis I understood it properly, I actually agree with your core point, which is that github is sometime giving the impression to feed the crowd with new features that are a tight bit superficial.
But this point is 98% uninteresting if you don't bring a laundrylist of mind-breaking feature you think should be coded instead. I'll help with a few:
- Commit forwarding to same repo at other hosts
- Use github as git-svn interface
- Private repos (I seem to be the only one to not want everyone to peek at my shitty hardcoded bashrc)
- Shared repo templates (eg create a new repo with a python gunicorn setup ready made, after filling a few fields), a la Linode recipies
- Allow-all repos, anyone can commit to it.
- Shareable user created repo analysers, code checkers, commit hooks.
I have no idea if any of these ideas is sane, but at least it should leave a bit less negative trails on this board.
It's funny that you should say this, because I have pretty much the exact opposite impression. Most of their feature announcements are for dubious changes that don't make my life better (web-based CLI? Stars-vs-followers?), but more to the point, they've left really important things to languish (for example: their code search sucks, and their issue tracking system is just barely usable.)
I don't get the sense that GitHub is rowing in the same direction as a company. Their product isn't improving in any consistent way, and for all of the changes that they announce, I'm having a hard time of thinking of the last one that made a positive impact on my life. Certainly, I've never before needed to create a file in github via the web, and I probably never will.