You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 18, 2021. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 18, 2021. It is now read-only.
disable further commenting on an issue or pull request #38
Sometimes issue comments can devolve into a mess of trolls complaining after a repository maintainer has decided against an issue, it would be helpful if a repository could disable new comments on an issue.
The reopen case can be handled by cross linking in a new issue.
This would also be especially useful when there are issues that are definitely no longer relevant. Sometimes people comment on a bug report because it has a single similar word in the error message, but they're using node 0.10 and the original post is from node 0.2, for example, and all the code has been rewritten.
It would be great to really totally close an issue, so that new problems have to create a new issue.
It just sounds good, but would probably be difficult to do the right way.
When would you decide that given issue is permanently closed? Usually right after you fix it, isn't it? ..and doing that at this point, you're introducing other issue. You're taking away a possibility to report that given fix is not complete, or it breaks something else.
I'm pretty sure many maintainers will overuse that feature, and make discussion on issues even more problematic.
You're taking away a possibility to report that given fix is not complete, or it breaks something else.
Not really. A user can still post a new issue, and reference the old one. The reference will show up in the other issue, but they won't be able to post comments that live only in the old issue.
If the project maintainer decides that ay new comments belong on a new issue, isn't that almost always the right thing to do?
@isaacs I'm wondering if, as the main page of the repo said, @github has been made aware of this request. I think the events of the past few days make it relevant more than ever.
We've received a couple of emails regarding that particular Pull Request discussion, and it's something that a number of us have been following out of interest. It's unfortunate that the tone took a turn for the ugly. We've had requests for that Issue-closing feature in the past, and our team is aware that some of our users are asking for it. I can't make any promises regarding possible future changes, though.
For future reference, project owners do have some tools at their disposal for handling situations like these. You can delete Issue comments that you deem inappropriate. Additionally, you can ask us to block specific users from the organization. This will prevent the blocked user from opening or commenting on Issues and Pull Requests.
IMO, if a maintainer wants to close discussion, it should be possible. It would be useful to providing clarity that an issue is resolved and it would help others reading discover exactly how that resolution took place. When the discussion continues, it can be difficult to find that information.
Deleting issue comments and banning users is not a real solution. I have other things to do besides sitting on a page deleting comments as they come in by the hundreds.
Yeah. A pleasant solution for the 'bug fixed, go away' case is to close after X time of inactivity. For the community moderation case, just give the power to the repo owner.
It just sounds good, but would probably be difficult to do the right way.It should not be too hard
Just give the project admins an option to always reopen?
For future reference, project owners do have some tools at their disposal for handling situations like these. You can delete Issue comments that you deem inappropriate.
Selectively deleting comments opens up the accusation of censorship so maintainers are typically very reluctant of doing that. It also doesn't stop emails from being sent.
Additionally, you can ask us to block specific users from the organization. This will prevent the blocked user from opening or commenting on Issues and Pull Requests.
Doesn't help if people are flocking by the 100s, not to mention the troll accounts that are being created.
Hacker news solves these issues to a certain extent by using a reputation system. Unless you want to go down that path, permanent closure seems to be the obvious solution.
I do think this feature should be tried out, but there is a possibility that in a high profile PR disaster situation it would just lead to people opening zillions of new issues, which would be harder to deal with than a single thread.
Ability to close commenting on a closed issue really seems like the only and best way to solve this. @AmyStephen is right that the long threads of continuing discussion and arguing really drowns out the real resolution. If you have a question about the closed issue, open a new one and reference the old. What are we missing?
Bayesian comment moderator bot as a service? If you can delete comments, then you can combo that with the Issues API and fall well under the 5,000 requests / hour the rate limiting to keep steady track of when new issues are created, and then run spam filters on them, or just delete them if you want the thread effectively dead.
I personally would like to set it to delete comments by throw away accounts automatically. In joyent/libuv#1015 there were at least two accounts less than 1 day old trolling the issue. New Stack Overflow users have restrictions and it helps cut down on spam.
Courtney Stanton did a great presentation on analysing the hateful comments she received on a particular post. Maybe troll filter is the new spam filter?
haha I'm not sure about the spam-recognition aspect, but a bot would be a genius workaround @jteneycke! The maintainer auth's it, and marks issues as "closed", then it posts an explanatory comment, and automatically removes any subsequent comments :)
Would that work for the bounty @isaacs? A userscript could make it seamless for maintainers (See #128)
Thanks @patcon, I've been coming up with a lot of bot ideas since listening
to your talk last week! You're right that spam filtering is another issue.
The implementation that you just mentioned is exactly what's been rolling
around in my head all morning. 👍
haha I'm not sure about the spam-recognition aspect, but a bot would be a
genius workaround @jteneyckehttps://github.com/jteneycke! The
maintainer auth's it, and marks issues as "closed", then it posts an
explanatory comment, and automatically removes any subsequent comments :)
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/38#issuecomment-29639686
.
The reason it took so long was because they were (and still are) also trying to get it to work for commit threads, which are apparently more involved to add the feature to. See: https://twitter.com/holman/status/476133921319440384
Closing comments on commits is _the_ thing this issue is about, though. This issue was almost exclusively raised due to a very specific controversial commit in Node. It's not ready to be closed until that feature lands.
Activity
isaacs commentedon Jun 17, 2013
This would also be especially useful when there are issues that are definitely no longer relevant. Sometimes people comment on a bug report because it has a single similar word in the error message, but they're using node 0.10 and the original post is from node 0.2, for example, and all the code has been rewritten.
It would be great to really totally close an issue, so that new problems have to create a new issue.
medikoo commentedon Jun 17, 2013
It just sounds good, but would probably be difficult to do the right way.
When would you decide that given issue is permanently closed? Usually right after you fix it, isn't it? ..and doing that at this point, you're introducing other issue. You're taking away a possibility to report that given fix is not complete, or it breaks something else.
I'm pretty sure many maintainers will overuse that feature, and make discussion on issues even more problematic.
isaacs commentedon Jun 17, 2013
Not really. A user can still post a new issue, and reference the old one. The reference will show up in the other issue, but they won't be able to post comments that live only in the old issue.
If the project maintainer decides that ay new comments belong on a new issue, isn't that almost always the right thing to do?
trodrigues commentedon Dec 1, 2013
@isaacs I'm wondering if, as the main page of the repo said, @github has been made aware of this request. I think the events of the past few days make it relevant more than ever.
tjfontaine commentedon Dec 2, 2013
Sent November 30th, 2013
Sent December 1st, 2013
Received December 1st, 2013
AmyStephen commentedon Dec 2, 2013
IMO, if a maintainer wants to close discussion, it should be possible. It would be useful to providing clarity that an issue is resolved and it would help others reading discover exactly how that resolution took place. When the discussion continues, it can be difficult to find that information.
isaacs commentedon Dec 2, 2013
Deleting issue comments and banning users is not a real solution. I have other things to do besides sitting on a page deleting comments as they come in by the hundreds.
aredridel commentedon Dec 2, 2013
Yeah. A pleasant solution for the 'bug fixed, go away' case is to close after X time of inactivity. For the community moderation case, just give the power to the repo owner.
piscisaureus commentedon Dec 2, 2013
Just give the project admins an option to always reopen?
Selectively deleting comments opens up the accusation of censorship so maintainers are typically very reluctant of doing that. It also doesn't stop emails from being sent.
Doesn't help if people are flocking by the 100s, not to mention the troll accounts that are being created.
Hacker news solves these issues to a certain extent by using a reputation system. Unless you want to go down that path, permanent closure seems to be the obvious solution.
boutell commentedon Dec 2, 2013
I do think this feature should be tried out, but there is a possibility that in a high profile PR disaster situation it would just lead to people opening zillions of new issues, which would be harder to deal with than a single thread.
jasonrhodes commentedon Dec 2, 2013
Ability to close commenting on a closed issue really seems like the only and best way to solve this. @AmyStephen is right that the long threads of continuing discussion and arguing really drowns out the real resolution. If you have a question about the closed issue, open a new one and reference the old. What are we missing?
isaacs commentedon Dec 2, 2013
Bounty offered: https://twitter.com/izs/status/407340738318311424
jteneycke commentedon Dec 2, 2013
Bayesian comment moderator bot as a service? If you can delete comments, then you can combo that with the Issues API and fall well under the 5,000 requests / hour the rate limiting to keep steady track of when new issues are created, and then run spam filters on them, or just delete them if you want the thread effectively dead.
I personally would like to set it to delete comments by throw away accounts automatically. In joyent/libuv#1015 there were at least two accounts less than 1 day old trolling the issue. New Stack Overflow users have restrictions and it helps cut down on spam.
Courtney Stanton did a great presentation on analysing the hateful comments she received on a particular post. Maybe troll filter is the new spam filter?
patcon commentedon Dec 2, 2013
haha I'm not sure about the spam-recognition aspect, but a bot would be a genius workaround @jteneycke! The maintainer auth's it, and marks issues as "closed", then it posts an explanatory comment, and automatically removes any subsequent comments :)
Would that work for the bounty @isaacs? A userscript could make it seamless for maintainers (See #128)
jteneycke commentedon Dec 2, 2013
Thanks @patcon, I've been coming up with a lot of bot ideas since listening
to your talk last week! You're right that spam filtering is another issue.
The implementation that you just mentioned is exactly what's been rolling
around in my head all morning. 👍
On Mon, Dec 2, 2013 at 12:42 PM, Patrick Connolly
notifications@github.comwrote:
41 remaining items
Fishrock123 commentedon Jun 9, 2014
The reason it took so long was because they were (and still are) also trying to get it to work for commit threads, which are apparently more involved to add the feature to. See: https://twitter.com/holman/status/476133921319440384
mhulse commentedon Jun 10, 2014
FYI:
MylesBorins commentedon Nov 16, 2014
Should this issue be closed as locking threads is now a feature?
patcon commentedon Nov 18, 2014
For sure. But OP or repo owner need to do it
cc: @tjfontaine @isaacs
dvidsilva commentedon Dec 4, 2014
ironic +1
margaritis commentedon Dec 5, 2014
👍
embray commentedon Dec 8, 2014
I think it's still not possible to lock discussions on commits though?
Fishrock123 commentedon Dec 9, 2014
@embray correct.
Nate-Wilkins commentedon Feb 11, 2015
@tjfontaine could you close this issue?
I think the only thing missing is the ability to close commits. Maybe a new issue?
Thanks!
stuartpb commentedon Feb 12, 2015
Closing comments on commits is _the_ thing this issue is about, though. This issue was almost exclusively raised due to a very specific controversial commit in Node. It's not ready to be closed until that feature lands.
stevemao commentedon Jun 30, 2015
Please lock this. Thanks.
cirosantilli commentedon May 3, 2016
Closing as done for issues. For other types of comments like commit comments, please open separate specific issues.