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).

Devils advocate: if you think it is important, then why don't you want to know when it's fixed?

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.

    > why don't you want to know when it's fixed?

Knowing when it is fixed/closed is very much different than getting emails about every single comment going on about that issue.

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.

Agreed. Would be great to get an alert only when the issue is closed. That could also work as a rough voting system.

Launchpad pushes people into two options:

- 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.

> Devils advocate: if you think it is important, then why don't you want to know when it's fixed?

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.

Agreed. This would be analogous to the watch (subscribe) and star (vote) mechanics for repos.

I don't think showing number of subscribers is a good selection of if that subscriber supports the issue. It could just mean they want to see what's going on before they weigh in.

I watch a lot of repos, therefore I'm automatically subscribed to all and new issues, that'd show me as supporting everything.

I'm referring to people who explicitly subscribe to a given issue. It's true that this would not allow people watching a repository to explicitly register their interest but I think the percentage of interested parties who are watching a repository is quite low. (GH could estimate this by checking +1 comments on issues for watchers.)

I think the advantage of using subscribers is simplicity. Adding another feature that is arguably similar to the existing subscribe complicates things.

Subscribing to an issue to see how it plays out and supporting the contents of the issue are two majorly different things.

I think this is more of a perception issue.

A concerned user will feel like they are adding more weight by "starring" it (or "voting" / "+1"ing it) than "subscribing" to it. Even if they really mean the same thing, ie adding to a counter and notifying on updates.

(And I doubt it's a good idea to separate these functions, even if some people will protest they have a corner case where they would want to do one but not the other. It adds unnecessary complication.)

I agree that starring or voting seems to add more weight than the current subscribe mechanism. However, I think if the presentation of the subscribe UI and the subscriber information is changed, this is a solvable problem.

It'd be nice for GitHub to prevent (or at least annoy) people who make "+1" comments

e.g. "Did you mean to subscribe instead?"

I think that would probably frustrate users more than anything. Positioning the subscribe option more prominently (along with the number of subscribers) might have the desired effect.

Yes. When you subscribe to an issue you show that you are at least interested enough to receive notifications about it.

Eh, I don't like getting spammed with notifications when I'm subscribed to a popular issue. Maybe that will be less of a problem with fewer people posting +1 comments, but still. I wish I could just get a notification when the issue is closed.

Sure, but what if I don't care about being notified of ongoing discussion for an issue, and instead just want to be notified when it's been closed, or maybe a pull-request has been submitted?

If people are still +1 commenting (and they are) it is still an issue and not solved by showing the number of subscribers.

The problem is that there is currently no way to see the number of subscribers on an issue so it can't be used as a signal of interest. I don't understand how a suggestion to change user behaviour can be proven false because the undesired behaviour exists before the change.