I think it makes sense to have a difference in meaning between "I want to be e-mailed updates about this" (subscribe) versus "I think this is important/valuable/necessary" (star/vote).
Starring instead of subscribing is basically the issues equivalent of "Hire, but not for this team". If you limit it to people who care enough to subscribe, you only get the people who actually are invested in it, and avoid the people who think it should be fixed but who don't actually need it to be.
- Receive all emails about this bug except comments - Only receive email when this bug is closed
There's also an "this bug affects me", which records that and then gives you the option to subscribe to either of the two options above. Seems like a happy medium.
> why don't you want to know when it's fixed?
Starring issues (as in Google Code Project Hosting) meant "I want to see this getting fixed" and subscribing issues on GitHub does not show anything like that. If I am not mistaken, you only see a list of people “participating” to an issue, you don’t get to see list of people getting emails about that issue.
Because I've implemented a workaround (after spending a few hours tearing my hair out wondering why the straightforward version didn't work) and I may or may not ever remove the workaround, not to mention I might have dropped the project or changed company entirely by then.
I may or may not care that it's fixed (though I probably do in the chance that I have to do this again in the future and have by then forgotten about the need for a workaround), but I do want to notify somebody that I have hit that issue and have had to work around it, and that it would be nice if future users didn't go through my own experience.