The per-organization email settings is actually the best news out of the bunch - now I can stop checking my personal email so frequently at work.
I'm hoping this feature also fixes the long standing problem with github commits via the web interface (merges and minor edits) using the wrong email addresses in the permanent git history - which always seemed like a huge bug to me.
UPDATE: Nope, it hasn't fixed that. Organization repos still use my default personal email address in the logs even after changing the notification routing.
It works fine when I commit locally (as yes, it's just a normal old git repo) - just via the web UI, it always uses the email in my github account marked as 'default' even though the repo obviously belongs to the organization, not to me.
If you haven't already, you should notify the kind people at Github. They respond within minutes, are friendly, and, most importantly, they actually react on what you write them. Who'd have thought?
We've made some REALLY BIG changes to the way that notifications work at GitHub.
We're sending you this email because we love you. Also, the amount of email you receive from GitHub notifications is going to change and we want to make sure you don't miss anything important. First, check out the new notification settings:
I hope Github's new round means they are going to be more responsive to customers. I like the company and the founders and team I know there, but it's been frustrating to have to wait for features like this for months and months.
Maybe someday we can attach images/docs to issues... I mean, why would you ever want to attach an image to a site rendering issue when you can try and describe it at length and still fail? Sigh.
Agreed. I've heard 'use dropbox' so many times here, and it's still shitty.
However, for the specific case of misrendered HTML skitch is def the best option, even if your software supports attachments. So few clicks, totally worth it.
This is the most important missing thing in github issues, but for what is worth, we solved it using dropbox links, it's reasonably straightforward (screenshot, save to dropbox folder, get link with right click)
On my own "Stars" page (https://github.com/stars) it's paginated, there's no sort, and there's no search; I'm having trouble imagining many use cases where this page is actually useful.
However, if you go to your public profile page, and click "starred repos", you can see a single-page list of all your starred repos (e.g. https://github.com/<username>/following).
Strange to say the least, but at least there's a single page where you could search your starred list...
Not having the ability to search seems like a bit of an oversight, if I remember correctly the previous "watch" list was on just one page so you could use the browser to search by name. Now it's called "stars" and it's paginated ... not so easy.
Previously the watched repos were displayed in a widget on your News Feed page exactly like the current "Your Repositories" widget. It has a nice fast filtering text box. The stars page desperately needs this back.
They sent out what I thought was a very well done support email for this feature:
Hi friend,
We've made some REALLY BIG changes to the way that notifications work at GitHub.
We're sending you this email because we love you. Also, the amount of email you receive from GitHub notifications is going to change and we want to make sure you don't miss anything important. First, check out the new notification settings:
https://github.com/settings/notifications
You can configure which notifications are sent via email, and which email address they're sent to (per organization!).
Which repositories do you receive notifications from? Any repository you're watching. You can manage the list here:
https://github.com/watching
Going forward this page will be the home base for understanding which notifications you receive. You're automatically watching a bunch of repositories based on your permissions — it's probably a good idea to go through and unwatch repositories you're not interested in.
Check out our blog post to learn more about our new notification system, our new stars feature and improvements to notification emails:
I don't see the faux in it. It seemed pretty sincere to me, and I'm pretty cynical.
GitHub is one of the companies that take deliberate effort to make me really them, from their clever 404 page, to little details such as this. Zappos is another.
I'm wondering. Do lots of other people find this off-putting?
They are not distinct enough to be 2 different actions. Especially having 2 totally different pages is a horrible thing(notifications and news feed) Why not just combine 2 of them together and create more polished feed?
For now, I have to disagree. I only want to watch the libraries/projects that are critical to what I'm building. This is a very small set of repositories. I have wanted the ability to star interesting things for awhile.
I like the distinction. I am used to "Star"-ing something in other web apps and I can quickly tell whether or not I am watching or bookmarked a repository when they are two separate things.
It's bookmarking (a la a browser) vs. following (a la Twitter). Those behaviors seem quite distinct to me, warranting different UI actions rather than following and following-except-not-really-following.
I like the change in notification behaviour, but now I'm missing the list of watched (or now starred) repositories on the feed page that used to sit underneath the list of my own.
I literally used this list numerous times everyday to get quick access to certain repos, now I have to click the 'starred' tab to get a similar list which means an extra page load.
I think this is a bad move and an example of feature creep. Were users really asking for this? The problem was that the stream was overloaded with irrelevant projects you may have watched on a whim. It seems like they solved that with the notifications drop down. I'm not sure what the point of Starring is.
I agree they could have done a better job of explaining the why for starring, but I assume that starring is a way to keep track of repositories you are interested in, but which you don't necessarily want to see filling up your activity feed.
I use watch to help me find repositories I'm interested in, but don't necessarily want to see notifications about. Watched repositories are autocompleted when you begin typing a name in the search field. So starring looks useful to me.
I think it's pretty useful. I had tons of projects I'd watched just because they were cool and I wanted to use them in my next projects, not because I actually wanted to follow their development.
If I understand correctly, you can now keep track of a repository in two ways: starring it or watching it. If you star it, it's more like a "favorite" in that you can find it easily in the future, but that's it. If you watch it, its activity shows up in your stream much like before. This allows you to separate repositories you like and will want to find later from repositories you want to participate in and follow the development of.
The point of starring is to do what you probably wanted to do when you watched a project, which is bookmark it without it cluttering up your watch list. Personally I think the star feature is great -- now I don't have to use Codeshelver, which was cool too but kind of half-baked.
How so? At first I thought it was a renamed 'watch', but since it doesn't put any data in your timeline, I can't figure out what it is for at all. I mean, it's a pretty button and all, but...
Getting to the starred lists and to the watched lists require a considerably different navigation. (e.g. why is there a "Stars" tab beside the "Issues" tab but no "Watch" tabs? Why are my own repos starred instead of watched?)
It appears that happened automatically. Your watches list is now full of all the things you used to implicitly get notifications about, which was not a materialized list anywhere before.
GitHub, you should have made it so any repo that you had watched previously remained watched AND starred.
It looks like everything is now starred but unwatched so no one will receive any updates on the feed anymore unless they manually go through all their repos and choose to watch them.
I think this is the behavior most people are going to prefer. It seems like it's pretty general to use "watch" for what is now a "Star" (i.e. something you find interesting but don't want updates from) so this will probably please the most users.
I mean I totally agree. Being able to favorite something without getting updates is great. I just think that changing the default behavior (aka coming to the site one day and having nothing new in your feed) is a little bit strange.
Strange, for you. A lot of us are unfortunately leechers (and there are more of us than yours). We don't (sadly) participate in big- (or medium-) sized projects and mostly do our own stuff and thus don't really care about specific commits in Node.js, homebrew or rails. When there's a new version we're excited and will use them, but the internal and day to day operation and progress of those projects are of little interest to us.
Yeah I know what you mean. It totally goes both ways. Perhaps giving the users an option during the upgrade then to keep the existing stuff watched or unwatched would have worked, but things like that are usually a slippery slope.
I think it's intentional. Many people watched repos to show support, but didn't really want the notifications. Hence, their notifications feeds filled up, and they never really looked at them.
For most people I reckon there aren't many no-push-rights repositories they'll need to re-watch.
Seems the new notification system impacted the news feed filtering of the 'switch account context'. I am now seeing lots of activity for organizations I am a member of in my personal context. I guess this is a side effect of 'watching' those repos?
I have also had this happen to me--I am part of a fairly large company on github, so this means that suddenly I don't see anything in my strema except for posts about that company, so I had to unwatch nearly everything in it, which I would rather not have to do.
I would really, really like per-file watching (or even finer granularity, though I can't imagine the use) In collaborative environments, having github tell you when something has changed without going through the commits yourself would be cool.
Excellent! I've been using watch for bookmarking interesting projects but I didn't really want to see all their activities (commits). Stars solves this problem. I think they're missing a search functionality for stars though.
Was there a warning about this update? I heard about 10 minutes of commotion in our office due to this update. Mostly surprise at the timing which was the middle of the work day on a Monday.
Me either but I would have appreciated it since it is probably the most used 3rd party service for our company. We will be moving to their enterprise setup in the near future anyway so it should not be an issue for us going forward.
It was a tricky migration to make. We felt the warning would have just caused more confusion, and that it was best to get everyone upgraded at the same time.
This change is only slightly better than the previous implementation. What we (and most I know) need is per-repo settings. Our organization has nearly 20 repos.
Considering that the Gitmark Chrome extension has been doing the equivalent of "starring" for a long time, than yeah, I'd say it's probably not that hard.
I'm hoping this feature also fixes the long standing problem with github commits via the web interface (merges and minor edits) using the wrong email addresses in the permanent git history - which always seemed like a huge bug to me.
UPDATE: Nope, it hasn't fixed that. Organization repos still use my default personal email address in the logs even after changing the notification routing.