Seems like this one is solved by showing the number of subscribers to an issue. I don't think this really needs to be a separate feature.

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.

This issue helps with a lot of projects, +1 is only problem if you are in the 0.1% of projects.

I've thought long and hard about the "voting" mechanism, and I am really, really torn. Tons of people writing "+1" is a very aggressive voting mechanism. It is noisy and loud, which I think is a desirable trait for some issues on open source projects. There are lots of projects with awesome developers that listen to their users and are commendable souls. There are also lots of projects with developers that don't give a shit about what their users want. Yes, yes, "if you don't like it, write your own", but that simply isn't possible for I'd say most projects out there. And so the +1 comments "voting mechanism" has spawned what I call "the new tyranny of 'locked to contributors'", which itself is a pretty good indicator of the kind of developers running a project. There are projects out there which have issues with huge long chains of +1 comments and enormous bug bounties on BountySource, and for whatever reason, the developers have chosen to ignore the issue, eventually locking discussion to contributors. For me, this is a huge indicator about the developers and the project, and I will generally avoid it if at all possible. The reason I'm on the fence is because it will remove this big, loud indicator when there is a star or vote button or whatever. That is much quieter and easier for the developers to simply ignore -- and of course, that's their prerogative, just as it's mine to not use or contribute to a project for the same reason. Anyways, this is my thought process on the whole voting idea.

But none of that matters for either kind of developer, does it? For the awesome ones it's just noise, and the bad ones will just ignore it.

Why does it matter if it is a simple counter? It'll tell you exactly the same information, with a lot less cluster. And it'll help people reading through issues that are littered with it.

Personally I think having a +1 counter is a win-win solution. And I detest all the +1 comment spam in issue threads, it is noisy and doesn't contribute to the conversation.

Until then, why not create a bot that deletes all +1 posts but edits the main post with a counter of +1s?

I didn't say anything about it mattering to the project's developers. I said it matters to me because it's an excellent indicator about the quality and personality of the developers working on a project. It helps me to avoid like the plague some janky project where some popular issues languish in 'locked to contributors' when some other project listens to users. Most importantly, when the time comes that I will want to contribute to a project I use by submitting bugfixes or PRs to support other functionality, I know what the climate is like. I'd much rather know to avoid a project before I even decide to use it than six months into embedding it into my production workflow.