Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Locking GitHub Conversations

github.com

Post reply on HN
Print view View original

11–20 of 22 posts

Re: Locking GitHub Conversations

#11

Post by holman »

RKoutnik wrote: post #10

EDIT: Looks like this has been fixed already. Speedy update by GitHub, nice work folks. This is very easy to bypass. I was able to 'chime in' on one of the massive threads this feature intends to stop by referencing it in an issue on one of my repositories: https://github.com/joyent/libuv/pull/1015#issuecomment-45544... Obviously this is a tad more complicated than before (and makes it much harder to go on multi-para…

Yeah; that's a pretty limited interaction (compared to comments) so it wasn't a huge focus yet. I'll have a fix patched up and deployed in the next hour or so, though.

(Edit: fix is deployed.)

Re: Locking GitHub Conversations

#12

Post by tjohns »

TimWolla wrote: post #4
jipiboily wrote: post #3

Finally, no more :+1:s when it's all that is being said by everyone, without much discussions...yay to less noise!

I must admit that I like those :+1:s, it shows which issues should be prioritized.

As a maintainer, the +1s get very annoying and can actually get in the way of useful work being done.

At best it makes the comment thread hard to follow. At worst, it causes some people to start filtering their bugmail to /dev/null.

This is why some issue trackers have a dedicated voting system. Even then, people will still ignore it and reply with "+1" or "me too". sigh

Re: Locking GitHub Conversations

#13

Post by gnoway »

sloanesturz wrote: post #9

Hopefully this feature will help to mitigate political PR's like this one so that project leaders can get back to writing code and won't have to deal with their repos being overloaded by non-contributor talking heads. 742 comments over a simple terminology change? Yeesh. https://news.ycombinator.com/item?id=7801646

I guess this was downvoted for the unnecessary sarcasm, but the linked thread was the first thing that came to mind when I saw this new github feature. A lot of unfortunate ignorance and anger-in-response could have been avoided (or at least diverted from github) had this feature been in place at the time.

Re: Locking GitHub Conversations

#15

Post by bhousel »

steveklabnik wrote: post #8
DigitalSea wrote: post #6

Finally. Now all we need is the ability to vote up an issue and we're set. Seems comments have been used as a voting mechanism on Github since its inception and this new feature could put a stop to that. I hope not.

This was there long ago, and was removed.

Any idea why? It seems like it would be such a useful feature.

Re: Locking GitHub Conversations

#16

Post by steveklabnik »

bhousel wrote: post #15
steveklabnik wrote: post #8

Earlier quoted context omitted.

This was there long ago, and was removed.

Any idea why? It seems like it would be such a useful feature.

As a maintainer, I never found it particularly useful. Open source projects aren't generally democracies, and clicking an 'upvote' button is so low-effort that it wasn't really a good signal anyway.

Re: Locking GitHub Conversations

#17

Post by plorkyeran »

steveklabnik wrote: post #16
bhousel wrote: post #15

Earlier quoted context omitted.

Any idea why? It seems like it would be such a useful feature.

As a maintainer, I never found it particularly useful. Open source projects aren't generally democracies, and clicking an 'upvote' button is so low-effort that it wasn't really a good signal anyway.

My experience with it on trac and uservoice is that it's an easy way to filter out things that exactly one person cares about, and not much more. The main benefit is that it reduces the number of spammy +1 comments you get.

Re: Locking GitHub Conversations

#18

Post by steveklabnik »

plorkyeran wrote: post #17
steveklabnik wrote: post #16

Earlier quoted context omitted.

As a maintainer, I never found it particularly useful. Open source projects aren't generally democracies, and clicking an 'upvote' button is so low-effort that it wasn't really a good signal anyway.

My experience with it on trac and uservoice is that it's an easy way to filter out things that exactly one person cares about, and not much more. The main benefit is that it reduces the number of spammy +1 comments you get.

I do wish it was easier to subscribe to a particular issue without having to leave a sole :+1: comment.

Re: Locking GitHub Conversations

#19

Post by holman »

plorkyeran wrote: post #17
steveklabnik wrote: post #16

Earlier quoted context omitted.

As a maintainer, I never found it particularly useful. Open source projects aren't generally democracies, and clicking an 'upvote' button is so low-effort that it wasn't really a good signal anyway.

My experience with it on trac and uservoice is that it's an easy way to filter out things that exactly one person cares about, and not much more. The main benefit is that it reduces the number of spammy +1 comments you get.

@steveklabnik (since hn won't let us nest further): why not just hit the subscribe button on the right?

Re: Locking GitHub Conversations

#20

Post by acdha »

TimWolla wrote: post #4
jipiboily wrote: post #3

Finally, no more :+1:s when it's all that is being said by everyone, without much discussions...yay to less noise!

I must admit that I like those :+1:s, it shows which issues should be prioritized.

https://github.com/elasticsearch/elasticsearch/issues/256 is exhibit A for why this is a waste of time. The maintainer says it's a priority, they're working on it, etc. and there's another couple hundred comments from people who aren't helping out but are willing to distract the maintainer with a +1.
Post reply on HN