5 ms·

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.

anonicode 11y ago
Yes. When you subscribe to an issue you show that you are at least interested enough to receive notifications about it.
- icholy 11y ago
  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.
- squeaky-clean 11y ago
  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?
joshmanders 11y ago
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.
- michaelmior 11y ago
  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.
  - joshmanders 11y ago
    Subscribing to an issue to see how it plays out and supporting the contents of the issue are two majorly different things.
mmahemoff 11y ago
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.)
- michaelmior 11y ago
  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.
gknoy 11y ago
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).
- lewisl9029 11y ago
  Agreed. This would be analogous to the watch (subscribe) and star (vote) mechanics for repos.
- matthewowen 11y ago
  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.
  - lwf 11y ago
    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.
  - alpb 11y ago
    > 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.
    - morninj 11y ago
      Agreed. Would be great to get an alert only when the issue is closed. That could also work as a rough voting system.
nevir 11y ago
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?"
- michaelmior 11y ago
  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.
lucisferre 11y ago
If people are still +1 commenting (and they are) it is still an issue and not solved by showing the number of subscribers.
- michaelmior 11y ago
  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.

anonicode 11y ago

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

icholy 11y ago
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.
squeaky-clean 11y ago
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?

joshmanders 11y ago

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.

michaelmior 11y ago
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.
- joshmanders 11y ago
  Subscribing to an issue to see how it plays out and supporting the contents of the issue are two majorly different things.

mmahemoff 11y ago

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

michaelmior 11y ago
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.

gknoy 11y ago

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

lewisl9029 11y ago
Agreed. This would be analogous to the watch (subscribe) and star (vote) mechanics for repos.
matthewowen 11y ago
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.
- lwf 11y ago
  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.
- alpb 11y ago
  > 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.
  - morninj 11y ago
    Agreed. Would be great to get an alert only when the issue is closed. That could also work as a rough voting system.

nevir 11y ago

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?"

michaelmior 11y ago
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.

lucisferre 11y ago

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

michaelmior 11y ago
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.