disable further commenting on an issue or pull request

[tjfontaine]

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.

[isaacs]

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]

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]

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?

[trodrigues]

@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]

Sent November 30th, 2013

Seriously, guys ... open source projects need a way to prevent further comments when things turn into flame wars and unproductive ad hominem attacks.

tracking issue:

#38

problem threads:

joyent/libuv#1015

joyent/libuv@804d40e

Sent December 1st, 2013

No really, please, can I get a response on this?

Received December 1st, 2013

Hi Timothy

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.

Let me know if you have any other questions.

Brian
GitHub Support

[AmyStephen]

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]

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]

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]

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.

[boutell]

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]

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]

Bounty offered: https://twitter.com/izs/status/407340738318311424

[jteneycke]

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]

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]

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:

haha I'm not sure about the spam-recognition aspect, but a bot would be a
genius workaround @jteneycke https://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
.

[tjfontaine]

... yet another external service to work around the fact that GitHub is more concerned with being a social network than a viable platform for successful open source projects. No, that's not a solution at all, and doesn't solve the spam of emails I already get.

GitHub needs to stop sitting on the sidelines and letting their platform be used as a dumpster for vitriol, hate, and other forms of trolling. If they want to be a successful social network, they will need to solve the commenting problems sooner than later.

GitHub, please be responsible and respond with a meaningful plan.

[patcon]

@tjfontaine re: email spam. We could solve that :)
http://developer.github.com/v3/activity/notifications/#set-a-thread-subscription

No, that's not a solution at all

I respectfully disagree -- This is a solution. And it's potentially an interesting model for engaging with the github platform and githubbers in general. We could implement something like @yeoman's insight tool, and make real usage data public on these things we're adding, contributing to the quality of the conversation and helping githubbers make even more informed decisions on where they would like to spend their time building the platform. Plus, this particular request would be solving a problem for high-profile projects, which would make it an excellent candidate for trying out the approach.

Yeah, ideal world, it would be great if github solved everything we deemed a priority, but we can take it in our own hands and inject some usage data and prototyping into the conversation, where otherwise we would just be spectators :)

[tjfontaine]

@patcon if it fits your needs, by all means write it.

I however have spent months designing and building external mechanisms to work around the deficiencies I have found with GitHub. Most of the time I can rationalize this as someone just disagreeing with my desired workflow.

OTOH commenting is an integral part of just about every website on the internet, at least on the social ones. It is embarrassing that GitHub continues to ignore even the basic needs of preventing further comments.

[patcon]

@tjfontaine 👍 Understood. Totally legitimate frustration on your part.

[captn3m0]

So I went ahead and made a bot for this. Its called @eteled and it deletes all future comments from an issue/PR once activated. Simple Usage Instructions:

1. Add @eteled to your repo collaborators (So it can delete comments)
2. Put a comment saying "@eteled START" (capitalization important) on the issue/PR.
3. @eteled will delete all future comments on that thread as they are created. (It also makes a comment notifying that all future comments will be deleted)

You can check a sample at captn3m0/github-image-post#1. It allows the issue/PR to be referenced from another issue, as @isaacs asked for. To re-enable comments on the issue, you can comment "@eteled STOP".

It runs using a webhook for inbound emails on its email address (using postmarkapp.com). Each email is sent via a webhook to the app running on Heroku. Depending on the notification, it decides individually to delete/skip the comment and watch/unwatch the thread.

Limitations

• It does not check whether the person STARTing/STOPing the watch is a repo collaborator or not.This should be fixed soon. Update: Now fixed.
• Its currently running on the postmark free tier, so it will stop working after it processes 10k emails.
• It cannot stop watchers from receiving notifications or replying to them via email. So, the comments may be visible for a small time (~2 minutes) before they are deleted.

File any issues/bugs/feature-requests here

[AmyStephen]

@captn3m0 You might just show something of value came out of this mess. Looking forward to seeing this used by the community. Thank you.

[Fishrock123]

👍

[mattapperson]

+1

[milani]

To force github, find a gendered pronoun on their repos and share it somewhere;)

[isaacs]

@captn3m0 That looks great! However,

It does not check whether the person STARTing/STOPing the watch is a repo collaborator or not.This should be fixed soon.

That's kind of a dealbreaker. Can you update this thread when that's fixed?

[captn3m0]

Yes, will do.

[patcon]

Again, you're an amazing specimen of a human being, @captn3m0

@isaacs, think we could add a tag for "external fixes" (a catch all for userscripts or bot solutions such as this) and close this issue?

[isaacs]

I'm not going to close this issue until GitHub actually makes it possible to prevent commenting on an issue. Eteled is great, but:

1. People can still send an email.
2. It's not obvious that your message will be deleted (yes, there's a comment at the end declaring as much, but the 'comment' button is still available.)

[patcon]

OK, I disagree with that approach as it makes this issue queue feel much less empowering as it could feel, but I respect your conclusion.

EDIT: On second thought, could I create an issue to discuss this? ie. is it open for discussion?

[robertrossmann]

tl;dr

A discussion may be closed as originally proposed by @isaacs and any future comments will require repo maintainer's approval to be included in the issue thread. Approving a comment would reopen the discussion for everyone.

This solves the problem with some threads being counter-productive or too divergent from the original topic and with the risk of prohibiting people from reporting newfound bugs introduced by that commit etc.

[cvrebert]

👍 This would be quite useful over at the Bootstrap repo.

[benatkin]

Just got mentioned by a well-known dev. Come on, GitHub.

[jacobian]

@holman says that they're is "working on it". Sweet.

[aredridel]

Yaaaaaay! &kermitarms;

[vierbergenlars]

Hurray! https://github.com/blog/1847-locking-conversations

[benatkin]

does this solve it?

[captn3m0]

I think it does.

[benatkin]

@captn3m0 no such luck. People can mention an issue in another part of GitHub and it will show up. joyent/libuv#1015 (comment)

[captn3m0]

It also doesn't work on commits.

[patrickkettner]

@benatkin - seems like it blocks those as well now

[benatkin]

@patrickkettner sweeeeet!

[Fishrock123]

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]

FYI:

Starting today, you can lock the conversation on an issue or a pull request.

• Locking Conversations

[MylesBorins]

Should this issue be closed as locking threads is now a feature?

[patcon]

For sure. But OP or repo owner need to do it

cc: @tjfontaine @isaacs

[dvidsilva]

ironic +1

[margaritis]

👍

[embray]

I think it's still not possible to lock discussions on commits though?

[Fishrock123]

@embray correct.

[Nate-Wilkins]

@tjfontaine could you close this issue?
I think the only thing missing is the ability to close commits. Maybe a new issue?
Thanks!

[stuartpb]

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]

Please lock this. Thanks.

[cirosantilli]

Closing as done for issues. For other types of comments like commit comments, please open separate specific issues.