Tay Ray Chuan home archive

not starry-eyed over github's new stars

Sun, 2 Sep 2012 08:10:08 +0800 | Filed under thinking aloud

A couple of weeks back, github introduced "starring", ostensibly to separate notifications from "tracking".

Sounds good. I've always wanted something like that. My apologies to those following me for the flurry of activity; I've shifted a couple of repositories from my browser's bookmark store to use the new star system.

But not everything that glitters is gold.

Confusing terminology

Let's say there's a cool new Github repo on Hacker News. I have no use for it right now, but I want to stash it somewhere handy so that I can use it in the future on a project. It's a high-activity repo so I don't want any notifications lest my feed gets flooded.

So...shall I "watch" it and put it on my "watchlist", so that I can get back to it next time? (This is what eBay calls it.) Or should I star it, like I do with my bookmarks (Chrome, Firefox)?

That's my main gripe with the new watch-star mechanism - it's too theory-laden for my liking. Instead of having to choose from "Not watching", "Watching" and "Ignored", why not say notifications on/off/none?

Backward-incompatibility

As part of the transition from watching-only to watching-and-starring, all repos that I was watching were switched to starred ones, except for repos that I've forked.

Huh? Couldn't this be made optional? Maybe I really do want to keep repos watched. Now I have to plough through my starred repos, open them, and click watch.

(I said maybe.)

I'd move on if it was an API introducing a backward-incompatible change (with ample notice, of course), but here we can do better - eg. a prompt upon visiting Github, like what they did recently with SSH keys and verifying emails.

Great job, Github, on separating notifications with "tracking" (starring), but you can do better.

blog comments powered by Disqus