6 ms·

Great job! Next item, be able to star issues. That would help a lot and we are able to avoid +1 comments.

michaelmior 11y ago
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.
fapjacks 11y ago
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.
- sondr3 11y ago
  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?
  - fapjacks 11y ago
    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.
Touche 11y ago
This issue helps with a lot of projects, +1 is only problem if you are in the 0.1% of projects.

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.

fapjacks 11y ago

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.

sondr3 11y ago
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?
- fapjacks 11y ago
  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.

Touche 11y ago

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