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.
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...
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.
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.
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.
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.
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:
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.
21 comments
[ 2.6 ms ] story [ 61.3 ms ] threadIf 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.
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
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.
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.
https://news.ycombinator.com/item?id=7801646
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.
(Edit: fix is deployed.)
See: https://twitter.com/Fishrock123/status/476133688506609664