Facebook has done a really good job solving the problems of information overload and would provide a good model. The most important step is to group updates from each project. Right now half of my news feed is comments on a single repository. Those should take up only one or two slots.
The next step is to filter according to some metric of "interestingness." This is more challenging, but clearly solvable using machine learning (let us tag posts as interesting or not interesting to train the classifier).
I'd love to see GitHub make the news feed more useful. It's currently the most unpleasant part of an otherwise nearly perfect experience.
That would solve about 95% of my problems with the news feed.
And I'd like a different summarized view for the projects I am only following.
Absolutely. I coded up a replacement using the GitHub API:
It broke when they changed the API, but by then I had found http://defunkt.io/dotjs, which allows you to execute any code in a ~/.js file for a given domain.
So I put $("div.news").hide(); in my github.com.js and instantly had a more relaxing, comfortable life.
I completely disagree with this part of your post:
Facebook has done a really good job solving the problems of information overload and would provide a good model.
But I do agree with these:
The most important step is to group updates from each project. Right now half of my news feed is comments on a single repository. Those should take up only one or two slots.
The next step is to filter according to some metric of "interestingness."
My advice is do it and share the hack. I think the best way to find trouble spots in your UI is to find out what people are writing hacks to work around.
There's a lot of projects I want to remember but don't necessarily care about the daily activity.
And no, browser bookmarks aren't good enough. A nice faved/starred page would show stats and maybe last commit/activity. That's it.
In theory I could just bookmark them using my normal system with a tag of "github" or something but the "Watched Repositories" widget is too useful to miss.
It's not up for public use yet, as i've yet to replicate the watched repos widget inline with bookmarks but next weekend I'll have a crack at it.
A new button will not fix Github's news feed problem. Making the news feed more relevant to users will.
Facebook and GitHub live in different problem spaces and may need different solutions. You probably don't have one friend that literally posts 200 times more posts than your average friend, but GitHub commits can very easily have this sort of pathological distribution. They're going to need to deal with that in a way that Facebook does not.
Pathological distributions can really be a pain in general. This sort of spiky, long-tail distribution can wreck up a lot of good plans.
For that matter, contra some suggestions about "machine learning" solving the problem I'd lay a few bucks that "commits I'm interested in" is so pathologically distributed that it is effectively unlearnable itself.
Maybe for you, but my experience is exactly the opposite. I find the Facebook news feed to be just about as useful as the Github news feed... which is to say, totally useless.
The problem, as I see it, is that G+, Twitter, Github, etc. all make the same fundamental mistake... assuming that "connecting" to an "entity" means "I want to see every update from/about this entity." So, I "friend" somebody on G+ or "watch" a project on Github, now I'm on the hook to see all their updates. But there's NO particular reason to think that the above assertion holds. At best, "friending" a person or "watching" a project says you're more interested in it/them than a random project/person.
These "event stream" implementations really need one or both of two things: The ability to specify more about what it is you're interested in, and smarter ML algorithms to figure out what to show you, based on both declared (or, for that matter, inferred) interests, and social connections, OR the ability to specify filters to exclude "stuff you don't want."
If I had to choose, I'd ask for the latter. Better filters would go a long way towards giving us control of our streams / news-feeds. I'd like, for example to be able to say "I don't want any pictures of cats with funny hats, regardless of who posted them, in my stream." Or, in the Github example "I don't want any commits from project $FOO in my stream."
If I'd seen much (or any) evidence to suggest that the machine learning stuff was smart enough to give me a truly meaningful feed without manual tweaking, I would care less about filters, but so far I'm just not seeing it. Facebook appear to try, but my feed there is still full of crap because they assume too much based on who I follow, not what I'm interested in.
But could you apply it to GitHub where all you care about in Project X is Feature Y or Issue Z?
I guess the easiest way is if you could somehow figure out that the pages the User was looking and commenting on all related to one thing, such as CSS issues or problems with C pointers and only display those issues. I'm not sure if that is doable but the people at GitHub probably don't have the necessary resources to devote to implementing this (at least in the near future), whereas Facebook has more engineers, resources, data, and time to throw at the problem.
> A new button will not fix Github's news feed problem
On GitHub, watched projects could show up in your feed by default, but you can hide them if they turn out to be too verbose.
(edit: put the wrong gitmarks project in here, updated to the one I meant)
>Codeshelver lets you clean up your GitHub watchlist by storing repositories you would like to remember on your shelf. You can tag any repository and search for it later on - until then it won't spam your dashboard timeline.
Codeshelver helps you find that one project that you had seen ages ago, which you did not want to follow (watch), but perhaps use somewhere.
This is the thing i always click watch in the first place, but i never get to the dashboard in reality.
No need to turn off anything, just make it smart.
Just collapsing updates from busy projects by showing the few most recent updates and then cutting it off with a message like "(+ 12 other commits and 3 issues; click here to expand)" would get it most of the way there.
Right now, GitHub groups both of these use cases into the same 'Watch' functionality.
Is that necessary?
I totally agree with the other poster in this thread that said the idea of "following" and "hey this is a neat project" is conflated in github. I'd like to favourite projects for further observation/interest, but I have no real desire to watch their progress day by day.
at least IMO.
Right, but if I'm a customer of your simple project, and a customer of Node.js and Homebrew, then I will never see your update and issue notifications that might actually have more relevance to me than Node or Homebrew because those two have near constant updates.
On the other hand, If I'm a customer of your project that is just as popular as Node or Homebrew, I'll be receiving hundreds of notifications from your project every day. You'd be effectively spamming me.
To fix this problem, we're asking if we could find a middle ground that lets the simple project with a dozen forks and 40 watchers maintain about the same level of notification real estate as the popular project with 5,000 watchers and just as many forks.
yep. the same on BitBucket.
"Little Forgotten Project has two updates? Cool! I'd forgotten all about that neat idea, let's see what they've been up to."
I've often wanted to write and broadcast a note or short msg (not a commit), that is deemed more important than a commit, about project goings-on and updates. Would be good to announce properly when there are serious changes or new features. Perhaps done with tags, but it needs to be prominence some how, it is all lost in the commit feed atm.
I watch projects where I actually care about and want to see the changes. Because I'm doing actual useful things and the social aspects of github help me do that.
I'm not on github to engage in some kind of social network circle jerk popularity contest to collect the most "watchers". I know a lot of people are and it makes them feel really important to follow a bunch of projects and pretend they're "in the know" or part of the project just because they clicked the watch button.
But every site doesn't need it's own different kind of bookmarks, that's a stupid waste of time. Other startups do it to drive viral growth or to "increase engagement" or some other BS reason. Github drives growth by being useful to developers and other collaborators. As soon as they start sacrificing power for people collaborating on code projects in order to satisfy the fanboys they risk losing their primary draw, the good projects that use github because it's useful.
I doubt this will happen, although I can definitely see why they would add an in-site bookmark to appease this crowd since they apparently don't know how to use client side bookmarks.
Perhaps I have bookmark-itus. I bookmark many things I may find interesting later, or want to remember. I end up searching through my bookmarks more often than not, because there are so many of them.
As to watching, I use it to get notified if a project I am interested in has updated, made changes that are meaningful to me, or has come back to life after a long silent period, or if it is something I want to look into later but don't particularly want to have the full update feed for.
That last part would be fulfilled handily by an internal github 'star' or 'bookmark' system. There are stars for gists, why not projects?
*note: I use pinboard.in, which is great.
I absolutely have bookmark-itus, but because of that I have a good bookmark system where I can set a date or interval for it to remind me that the bookmark exists. I think I took this idea from the GTD tickler concept.
I can see the use case for "tell me if this project has done something interesting (determine that magically) but I don't want to see every commit cluttering my feed" type features on github. Just don't break the feed to do it. It's clearly a secondary use case for the feed.
I'm also not sure if this use case is something actually useful rather than just stimulating to users. A site using this idea and github integration along with some Zynga math to optimize the dopamine dispensing combined with twitter, HN and the rest of social news would make sure that I felt like a hacker and never actually produced anything.
I also find the social aspect of github useful for discovery and there could be some new useful features around that use. But certainly not by breaking the watch feature to optimize for passive bulk watching.
I generally only care that a thread/project was updated. If I'm interested, I'll go in and look at what's new. Letting me know more than once just makes it harder to actually keep track of things you care about.
From the article:
>Eventually I noticed, that it would only create an update for each push, not for each commit. So I began to aggregate my commits into batches to push in the middle of the night. Unfortunately, that really slows me down.
He's doing what the Facebook news aggregator does by default. All pushes/commits can generate only one news feed item for a certain time frame: "Author made N changes/updates/commits"
To play the devil's advocate, though, perhaps this should be a part of the learning process of using Github. It would be instructive to all watchers to see what kinds of mistakes a good dev makes (or just be reminded that a good dev makes mistakes as well).
So even though the committers might be mindful, doesn't mean all the users of a project are.
There are times I end up doing a commit just to switch from my laptop to desktop. In Mercurial I end up with a million commits with the message "merge" b/c I really just did a pull of someone else's code and it forces you to do a commit just to get synchronized with the master (even with no meaningful conflicts).
I wish I could nuke all those ugly checkpoint commits and bundle them into a single commit with an intelligent comment when I push to the main server, but that's just not the standard workflow.
I've never used Mercurial, so I don't know if it has any equivalent to that.
But then that gets back to the original problem: how do you get people to do that so github watch lists only contain worthwhile comments?
In fact, git can also handle your second wish by having simply creating a "sync" branch pointing to that extra commit, then when you switch to between your laptop and desktop, pull the sync branch, check out the commit (apply it to your working directory), then switch back to the master branch and continue working (the commit never appears in the master branch).
Git rebase would handle the "forced commit on merge with no meaningful conflicts".
hope I don't sound like too much of a fanboy :)
What I see is that it is incredibly rare for a project to lose watchers. It seems that people are using GitHub's watch feature as a bookmarking service.
On a side note, GitEgo tracks two[1,2] of paulasmuth's GitHub repositories, and neither of them has "lost lost around 30 watchers by the evening." He may be referring to other projects on GitHub, but even Twitter Bootstrap (the most popular GitHub project), almost never loses watchers. Granted, these projects could all be gaining just a few more watchers than they are losing per hour, but the net effect is almost always a gain each day.
I think the real problem is that watching a repository doesn't engage a user in its contents. Watching commit messages fly by isn't as entertaining as reading 140 characters someone groomed for public consumption.
Al3x made 2 commits
Project: [message one]
Diff Project: [message two]
In my opinion as git being a tool to transparently see any and every thing changing. If you some how want less than that, perhaps you shouldn't subscribe to (aka watch) a "repository."
Ultimately, maybe the right thing for github to do would be to group nearby commits, but still summarize them and easily let you dive into them. This is code after all and almost any time I've updated a dependency, it's been because of the small details. In my accounts of the companies I've worked for, subscribing to the repositories we use, seeing every commit has served a lot of value. Just watching because it's some popular repository did not.
There are a lot of interesting projects, but I only want to follow those immediately relevant to what I am doing.
Better yet, RubyGems collects that information without any user input.
It would be awesome if the # of downloads could be shown on a GitHub project page.
I don't think having a timeline where you see all commits of all projects sorted by time really helps. The commits in project A don't effect the commits in project B, so they do not need to be viewed in sequence or relation to each other.
Let me have a dashboard where I can see all my projects then some recent/popular issues and commits to that project, keeping all projects separate.
Don't add a like/favorite/bookmark button, I think that's too many options. Watch already says "I'm interested in this", so we don't need additional buttons to express the same thought.
In the mean time you can checkout the video of it working or if you're feeling brave download the alpha version of the extension.
https://plus.google.com/u/0/b/110983919160550210204/11098391... [video & download links]
>If you commit "too often", people will get annoyed and unwatch you.
So don't watch projects you're not interested in watching and leave the Facebook mentality at Facebook. Issue closed.
I couldn't imagine not working on my projects out of fear that somebody who's feigning interest might stop feigning interest. Who thinks like this?
It's not twitter, stop playing the "follower count" game.
[watch] [fork] [watchers] [forks]
With this I often click "watchers" when I want to watch a repository. To me, much better solution would be something like this:
[watch | watchers] [ fork | forks]
Then, make tags the exception -- since they are likely being used for releases.
Activate a 'quiet' mode? In quiet mode nothing is sent to people's feeds.
Daily Digest mode. Daily digest would do just that. Lump all update in a day into 1 news feed.
I'd be happy with either option.
I have the same problem with RSS. I feel like this is a generic problem that needs solving.