Not sure I agree completely, "watch" is when you're actually interested in what's going on in the project. "Fork" is when you want to contribute with code changes. Maybe a "Like" button to show your appreciation would be nice?
Why do you care so much about how many watchers you have? I don't understand the point, certainly not to go as far as bunching commits and pushing at night to keep the watchers happy...
Watchers are (often) the people who use the software you make, and the exact kind of people you want to keep interested in your project. They're the source of useful bug reports and feature requests, and you want to keep them involved in the project as much as possible. I completely understand OP's intent.
> Customers would be more likely to use your project if it were more active, not less.
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.
Sounds like a brogrammer to me. If I am watching a project I usually give input to the pull requests and bugs. To me watching is being a bit more involved than a simple 'like'. Sometimes I feel like too many projects are based around the idea of "I will only develop it if people are watching it" instead of trying to solve a real problem for the author and going from there.
Well, there's also the responsibility thing: if I have (say), 10K watchers, I would feel responsible to keep mySweetProject running and maintained. Whereas if there were 0 watchers, I'd feel fine about ignoring it.
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.
This is a very real problem, but I'd argue it's a problem from the side of the watcher rather than the watched. As a GitHub user, there are two kinds of repos I care about: projects I'm active in, and projects I'm vaguely interested in and might be interested in keeping an eye on. For the first group, I want constant notifications. Let me know anytime anyone does anything. For the latter, I don't care, and probably actively don't want notifications.
Right now, GitHub groups both of these use cases into the same 'Watch' functionality.
That, I can believe. I don't watch any repos, though, so I don't know. I care about the ones I contribute to, because I forked them and issued pull requests, so I want to know how they're doing. Apart from that, I don't really care about watching other people's development live.
Agreed. There are many times I just want to sort favorite repositories that I want to refer to later. I've thought many times about building this using the Github API (like what Favoritizer does for Etsy) but then you would have a whole different website for browsing github.
Yes. This. I "watch" a lot of projects in lieu of favoriting them and because of how "watching" pollutes the timeline, I find the timeline totally useless.
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.
I agree. The timeline is useless. But not that watch button, because i do have all projects i find interesting in one place. Thats absolutely ok for me and works fine.
I disagree. I don't have a button on Facebook for "bookmarking someone." Facebook's news feed has managed to keep the news feed relevant despite massive social changes in my lifetime Facebook usage (everything from high school, to college, to working as a professional software engineer).
A new button will not fix Github's news feed problem. Making the news feed more relevant to users will.
Facebook has metrics like, how often you browse that person's page, how often you comment on that person's post and vice versa.
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.
Facebook's news feed has managed to keep the news feed relevant despite massive social changes in my lifetime Facebook usage (everything from high school, to college, to working as a professional software engineer).
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.
'I don't have a button on Facebook for "bookmarking someone."'
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.
I agree 100%. This has bugged me for a while. I use the watch button to basically favorite something that I don't want to fork. The way the current timeline operates right now is useless to me. Perhaps a way to show activity without regurgitating the commit log in a timeline form. sort the watched repos by recent activity and then when you click on it show some things that happened via ajax.
Additional they should introduce some "version notice", you get all the notices on new versions on your favorites.
Just a simple function for the creator.
This is the thing i always click watch in the first place, but i never get to the dashboard in reality.
>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.
only downside is when I look at a user's profile I like to see what their 'watching' to see what their interested in but if they shelve everything I wouldn't see that
Agree with this. I started out using the watch button as a "watch" button, and ended up using it as a "Fav" button. Having two separate buttons would let me have a list of favorite projects, and a news feed at the same time.
What about only publishing notifications for tags? Most people only use them to tag releases (or RCs) so the creation of a new tag might be the sort of thing people would be interested in knowing about.
Yeah, agreed. I thought for a while that the Watch button would be a good way to keep track of what's going with open source projects I care about. But I've found I pretty much ignore the news feed completely, there's just way too much noise there.
I suppose there's varying degrees to which I care about a project. I do want to know about every commit on the ones I'm actively involved in. On the other hand I'd be way more interested in like high level summaries for the projects that I'm just a user of.
This is really a problem with Github's news feed, rather than the watch button. Facebook had this problem a few years ago but put a lot of work into aggregating similar stories, etc.
I would really appreciate it if notifications were aggregated by thread and updates by project.
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.
>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).
I have never used my dashboard, because I watch so many repos. I use it as a bookmark function, but it'd be great if they replaced it with "bookmark" with a default option of not "following" the updates.
There are a lot of interesting projects, but I only want to follow those immediately relevant to what I am doing.
IMO the one who watches should be able to control which updates he sees in his feed, not the project developer (which is what the article and may commenters suggest). For some projects I'm watching I'd like to see every commit, issue update, etcetera. For others I'd only be interested in new tags that are created. The project developers don't know what I'm interested in. Only I know.
I find that what I take the # of GitHub watchers to mean (i.e. the popularity of a project) is better surfaced by the number of downloads on RubyGems.org, at least for gems.
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.
Twitter allows you to curate lists to filter through the clutter. I think that would apply nicely here. I don't think watching is broken, I think the feed needs some love.
I don't even really look at my feed. There's way too much going on in it for me to really keep track. I basically "watch" repos to bookmark them. "This might be useful in a project at some point; let me make sure I can find it later." Currently watching 92 repositories.
Really, the issue is that the news feed is broken. Even following a relatively small number of people and projects (10 and 29 respectively) my news feed is dominated by the many updates (issues and commits) from a couple of popular projects. The result is that things I might be more interested in from smaller projects are effectively invisible.
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.
Excellently stated. Up until a week ago, I was following around 200 projects on Github. I recently went through and unfollowed almost all of them (I think I left about 5-10 that I really care about). I did all this because the news feed had become completely useless for the reasons you describe above.
+1. Having users micromanage their commits to their repository because of fear of losing "popularity" is not the solution. Automation is the path to the future, let the computer aggregate the content for us and display a cleaner news feed.
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.
For the record, you will only get hacked work-arounds if your product is oriented at developers. Still, I'd rather spend time hacking on my projects than hacking on github's.
I think what I would like is a summarized view of the projects I am committing to. For instance "Cloudname/cloudname (5)" for "5 unseen updates for Cloudname".
And I'd like a different summarized view for the projects I am only following.
My solution to this was to use watching as a way to bookmark interesting repos. But since searching for those was impossible I created GH2Evernote, a service that gets the readme of all your watched repos and adds it to a notebook in your Evernote account.
This makes watching repos useful again, at least for me. I agree that this is broken and I never, ever look at my stream in GitHub. But now I'm making good use of my watched repos.
My proposition is that the watch button means you only see important updates, like when the new major version of Rails is released. The importance should still be decided by the repo maintainer though. I don't agree with bundling commits proposition, because it is not controlled by the maintainer and will not necessarily capture the stuff that is important and present it in a meaningful way.
--quote--
So I began to aggregate my commits into batches to push in the middle of the night. Unfortunately, that really slows me down.
--end quote--
How is pushing a bunch of commits that much different from pushing each commit? Slows him down.. what??
Yep i use watch as bookmark, and as such the feed is useless. There needs to be a Star/Fav thing, and leave watching for important stuff.
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.
There is a bunch of ways to distinguish important updates from the others. First, prioritize updates from projects I am or have contributed to. Second, updates from people close to me in the social graph (i.e. the people I watch on GitHub or people who belong to the same organization as I do). The frequency and size of updates should matter too - an usually silent project with a big update should have an advantage over noisy projects. Filtering out typical bugs (or commits/PRs fixing them) from the top priority ones should be fairly easy too - all the information is already there (comments, labels). Finally, you can go insane and start analyzing the actual code or even use NLP for commit messages/pull requests/bugs and make decisions based on that (for instance, prioritize projects that use similar tech as I do, changes that mention me or touch the code I've created or touched recently).
I think you are overthinking it. We don't need a fancy AI solution to the relatively simple problem of "busy" projects drowning out quieter ones. I don't think it would work very well and, anyway, we have different ideas about what's important in an update.
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.
Facebook faced this exact problem with its newsfeed. The solution? Do what Facebook did. Allow people to watch projects and then subscribe to various levels of activity.
123 comments
[ 0.23 ms ] story [ 172 ms ] threadAl3x made 2 commits Project: [message one] Diff Project: [message two]
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.
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.
Is that necessary? http://ycombinator.com/newsguidelines.html
Right now, GitHub groups both of these use cases into the same 'Watch' functionality.
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.
https://plus.google.com/u/0/b/110983919160550210204/11098391...
A new button will not fix Github's news feed problem. Making the news feed more relevant to users will.
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.
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.
<rant-over />
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.
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)
This is the thing i always click watch in the first place, but i never get to the dashboard in reality.
>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.
yep. the same on BitBucket.
Then, make tags the exception -- since they are likely being used for releases.
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).
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.
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.
Absolutely. I coded up a replacement using the GitHub API:
http://gilesbowkett.blogspot.com/2010/10/node-miniapp-minima...
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.
And I'd like a different summarized view for the projects I am only following.
This makes watching repos useful again, at least for me. I agree that this is broken and I never, ever look at my stream in GitHub. But now I'm making good use of my watched repos.
Update: I dont't know why but my HN submission only appears to me. Here's the direct link: http://www.gustavo.eng.br/gh2evernote/
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.
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.
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.
>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?