Hacker News Reader

Comment by laurent123456 | Hacker News Reader

Regarding adding +1 to issues - rather than doing this, up-vote the issue on GitHub (thumb up). This can be useful to maintainers because they can sort by thumb up and see the most popular ones.

Adding a +1 comment really does nothing - it's just one more useless notifications for everyone, and it won't allow filtering or sorting issues. People might even unwatch the issue because of this and thus missing useful comments.

View on HN

> This can be useful to maintainers because they can sort by thumb up and see the most popular ones.

TIL, but I also think it's not really clear what a reaction does. Does adding a reaction to a comment in an issue thread bump the whole issue, does it have to be added to the top issue to show up in sorting? I think a global "Vote for this issue" button would make this a bit more clearer than just a reaction within the issue.

I was always under the impression that just adding a reaction wouldn't actually give the issue a bump. Maybe it would be good if Github actually guides people towards it by either saying something like "You added a comment reflecting a +1, do you want to add a vote for the issue instead".

> Does adding a reaction to a comment in an issue thread bump the whole issue, does it have to be added to the top issue to show up in sorting?

Yes it needs to be added to the top post. It's not really an official thing I guess, but for popular projects these reactions add up, and it helps getting a clearer picture of what matters to users.

It is "official" in the sense that GitHub lets you sort by these reactions.

The point here is to not bump the issue. My GitHub notifications are a mess, and bumps cause me to unsub from notifications to issues in my own repository. There’s also a 0% chance a bump is going to cause me to reallocate my evening, so it doesn’t help get the issue moved forward.

Bumping doesn't necessarily mean "sending an email to the maintainer and everyone on the issue", adding a reaction can also "bump" an issue in the sense that it bumps it to the top of the list if sorted by "thumbs up reaction".

Perhaps I misunderstood the author, I assumed '+1' in this context meant the thumbs-up reaction. I'm certainly feeling much more charitable towards the OP if they literally meant people commenting "+1" (which is unfortunately a thing), but I think in a lot of contexts "+1", "thumbs-up", "like" are interchangable.

It’s literally people commenting. There’s a subset of users that haven’t noticed or haven’t understood the reaction buttons.

OP here. Thumbs up is great, commenting with the string “+1” is not great, commenting with “Why this this not done yet, this is very important to me. I might switch to another project if you don’t implement this.” is terrible.

Totally fair, and for what it's worth I agree. When I read the original post, I thought by '+1' you just meant the thumbs up reaction

Then again, adding a comment may prevent a bot from auto-closing the issue.

I've never really understood the point of these bots. I could understand if an issue had a test case attached to it, and the bot was auto-closing the issue if/when the test passes. That way, if it is resolved when fixing some other bug, or when refactoring, the issue is closed. But closing an issue due to inactivity gives the false impression that the issue has been resolved.

It depends a bit in the project and maintainers motivation.

However: Many projects swim in a sea of open tickets. Too many for the maintainers to keep an overview. By auto closing you make it clear to observers that currently this thing likely won't change and by forcing to reopen the maintainers can get users to tell them whether the issue still persists without having to try themselves. Generally there is little worth in keeping many years old tickets open, hiding recent issues while probably not being an issue anymore for whatever reason.

How do old tickets hide recent issues? The default is to show the newest ones first, isn't it?

Same, I find these bots really annoying. I guess they might be necessary/useful for popular projects where a small team of maintainers is trying to stay on top of a massive pile of incoming issues. But for the most part they seem misguided. (Especially the ones with a really short (like 30 days) activity window.) If an issue still exists in the project, why should it be closed? That will just require the next person who notices the issue to open a new one... Also, no activity on an issue can just mean that folks are waiting patiently for someone to get around to implementing it (or, more commonly, for some project dependency to release the patch that is necessary for fixing the issue ..).

I think they are basically an attempt at form of "issues/tracker bankruptcy" -- we have too many open things here, leaving them all open like we're going to get to them all eventually is a fantasy, and is overwhelming and makes it harder to find the ones we might actually address, so trying to algorithmically close the ones least likely to be actionable is just trying to make the situation more manageable.

I think it's a desperate measure -- if any maintainers are seeing it as reasonable management technique rather than desparate measure, I think they're making a mistake. It has a lot of downsides, some of which you outline, I agree with you. It also generally raises user frustration, leading to even more adversorial relationship between users and maintainers, which is what the OP is about and I think part of what's going on in this "issue bankruptcy" situations too.

Notably, Rails just turned off their auto-closer for Pull Requests (not sure about Issues), with this commit message from a maintainer:

> While the idea of cleaning up the the PRs list by nudging reviewers with the stale message and closing PRs that didn't got a review in time cloud work for the maintainers, in practice it discourages contributors to submit contributions.

> Keeping PRs open and not providing feedback also doesn't help with contributors motivation, so while I'm disabling this feature of the bot we still need to come up with a process that will help us to keep the number of PRs in check, but celebrate the work contributors already did instead of ignoring it, or dismissing in the form of a "stale" alerts, and automatically closing PRs.

https://github.com/rails/rails/commit/acf48169943011834c4c88...

Reading over the Rails committer message there… So Rails, decided that they did not want to discourage code PR contributors (despite getting some poor quality ones, I'm sure).

But other projects may actually want to discourage PR's, or especially Issues, so consider this a plus not a minus. Of course, you can just turn off Issues/PR's, or only allow maintainers to make them, if you really don't want them. But sometimes I'm guessing someone really don't want them but doesn't really want to say so...

Project with autoclose bots is not worth wasting any time by contributing to it, even by making an issue.

Edit: Nevermind, we're saying the same thing since you're talking about commenting with a +1 not reactions.

> Adding a +1 comment really does nothing - it's just one more useless notifications for everyone

I don't think reactions trigger notification emails.

It's bad either way. "Me too" should not be mixed with "I got a reliable reproduction, here's how".

Edit: I mean people probably want a notification on the second one but not the first.

They are talking about a literal comment saying something like "+1", which is very common. Not a thumbs up reaction.

Thanks, I must have missed that.

The thumbs up was added only a few years ago. +1 is quite common in older treads.

I agree with you, but old habits die hard. Reacts are a late addition to the GitHub interface, and in ye olde days adding a +1 comment was what you had to work with.

Just something to keep in mind in encouraging contributors to use the upvote and reacts.

Reply on news.ycombinator.com