Locking GitHub Conversations | Hacker News Reader

Locking GitHub Conversations

github.com

54 pointsjodal21 comments

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-paragraph rants) but the trolls can still troll.

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

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.

Yeah, but it's symptomatic of needing voting for issue priority. Comments aren't the place for indicating you'd like something to be fixed.

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

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.

Two things here: - the +1s show some level of interest, but enough to dive in the code, so it's half interesting, and half useless - also, once you've reached a certain number of +1s....well, it's just noise and annoying. 50 +1...500+1...

I wonder how much this is going to be abused. There are a lot of angry BDFLs out there and I can see this being used to silence people.

I don't think locking a thread is going to do harm.

If I don't want you to participate in my issue tracking, I can choose to ignore you, or now I can choose to lock the issue. You either continue to request attention from me, or won't come back to my software.

This can happen before locking is brought to us by Github, but this feature can help reduce noises. There are people who follow the repo and actually get spams from following repos they like to keep an eye on.

You have your choice to write about someone's angry ignorance on your blog or hackernews and people just won't care. They can even hide the repo or delete the repo once and for all.

Is this a good way to deal with people publicly? Yes to some, no to many. It's a choice. You either opt-in or opt-out.

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.

This also needs to be available for commit threads, I think.

See: https://twitter.com/Fishrock123/status/476133688506609664

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.

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.

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

> (since hn won't let us nest further)

ProTip(tm): HN does this when you try to reply too fast. You can click 'link' to get around it, though. :)

I never saw that! Thanks. Somehow that just escaped my vision.

Reply on news.ycombinator.com