If this idea of mine gets accepted, we'll need to break the following list down to separate issues (for some steps there may already exist previously filed ones):

We all hate "subscribe" and "+1" comments - some of us even as much as we hate spam comments. Personally, I think they should be considered spam too. We now have fixed #34496: [meta] Add Flag module to allow users to subscribe/unsubscribe without posting a comment that deals with "subscribe" comments and once we get #42232: Help Maintainers Manage Issue Priority by Encouraging Voting fixed, we'll then have a way to deal with "+1" comments too. There was also some discussion about cleaning previously posted "subscribe"/"+1" comments: #1303644: comment validation to prevent '+1 subscribe' comments, but that was wontfixed. Even I agreed on that, but now I've changed my mind. So, here is a list of steps I think we should take in order to automate the procedure of cleaning up the queues:

1. Add a "report spam/abuse" link next to the "edit" & "reply" links in comments (perhaps issue summaries too - do we get that kind of spam now that they can be edited?) so that we stop filing separate issues for each abusive/spam comment in the webmasters queue. I guess we can still allow reporting spam to the webmasters the old way too, but only if the automatic procedure fails somehow. (#226678: Add a "Report spam/abuse" link to forum/issue comments (next to the "edit" & "reply" links).)
2. Add a "Report spam/abuse" page that will be shown to the users when they click the "report spam/abuse" link from #1.
The page will have 4 ckeckboxes:

  • [ ] This comment is spam
  • [ ] This comment is abusive and/or uses profanity
  • [ ] This is a "subscribe" comment
  • [ ] This is a "+1" comment

Matto suggests here that having this be a multi-step/full-fledged report procedure might put users off from actually helping with reporting comments (because they might perceive this as a potentially tedious procedure). So, alternatively we can have it be an "AJAX-magic" thing -same as the follow/unfollow button- or even place the checkboxes in a tiny popup -like the one from the "Insert/edit link" button in the BUEditor toolbar-.

3. We decide whether all registered users may report abuse/spam comments or if this permission is automatically given to users only after say... they are members for a certain period of time? (or whatever other criteria).
4. Only spam comments get deleted, others are simply unpublished as an extra measure to avoid false positives #482312: Proposal: unpublish rather than delete content.
5. Previously unpublished comments that were never "reclaimed" as false positives after a certain period (say for 1 year?) are auto-deleted in order to avoid db clutter. This db clean up procedure is triggered regularly (say every month/trimester?).
6. Each comment has separate spam/abusive/subscribe/+1 counters that increase with each respective report.
7. We define limits for each category/counter after which actions are triggered:

  • Spam is deleted. No email sent to the owner of the comment (no point).
  • Abusive comments are unpublished. Warning email is sent to the owner of the comment to let them know that their comment was unpublished and that they need to either edit it to make it "polite", or leave it unpublished. Also warn them that after x reports of abusive comments, their account might get suspended (we'll need a counter for that too).
  • "Subscribe" comments are unpublished. Warning email is sent to the owner of the comment to let them know that their comment was unpublished and inform them of the existence of the "follow/unfollow" button (link to announcement/documentation/screenshots as well).
  • "+1" comments are unpublished. Warning email is sent to the owner of the comment to let them know of the ability to vote for issues instead of posting such comments.

8. Perhaps comments flagged by "admins" should have some extra "weight" thus causing instant categorization of comments (also see previous similar suggestion by Dave Reid).

Some of the benefits I see in the way I propose to do this and that I believe are worth mentioning are that:

  • we avoid false positives (by having people "flag" comments instead of relying on a query)
  • we avoid "biased" decisions (since each comment must be reported by several people before it actually gets "flagged")

Some might argue that this is too much manual work. I say we are a community of quite a lot of members and if every one of us spent a few minutes to report 10 such comments, it would help clean the place up.

What do you people generally think about this? I know it is a lot of work and that there may be extra steps required (besides the already too many) that I may have not thought of, but I believe that in the long run it will:

  • save us a lot of manual labor
  • keep the issues clean for when people go through their comments (in order to write/update summaries for example)
  • keep the db clean and thus search queries will require less resources

Comments

klonos’s picture

Talking about providing helpful links in comments in order to stop "noise" in the queues: #1308382: Add a "how to apply this patch" link next to uploaded patches.

...and if we allow user voting (as in users voting for other users), we would stop "thank you" comments too. I myself write tons of them ;)

naught101’s picture

Considering sun's comments on related issues, I reckon this won't be implemented due to performance problems with using flag on comments (d.o already has 5 million+ comments..).

I've already noticed a substantial decrease in subscription comments, and have started issuing slapdowns for +1 comments, eg. https://drupal.org/node/502500#comment-5116572

Spam is another matter entirely, and I think it's probably best to keep them separate.

klonos’s picture

Risking to get a "Put your code where your mouth is" here...

klonos’s picture

...this won't be implemented due to performance problems... d.o already has 5 million+ comments..

Yeah, I know. Most related issues were wontfixed in the past due to performance concerns. But do consider how many of these 5 mil comments are actually helpful/meaningful and how many are "subscribe"/"+1"/"thank you"/"hooray!"/"how to apply this patch"/whatever. If we don't do something to clean up the db soon (plus ensure a way to maintain it as clean as possible), it will continue to grow needlessly and that is guaranteed to only make matters worse performance-wise.

Currently, we are focused on cleaning up mainly only spam comments, but -as I've probably already made clear- I consider all non-helping comments as such. For all that we currently do to clean up comments, we depend on only a handful of people to do it for the rest of us. This proposal (which is nothing more than structuring ideas that others already had in the past) is based on this simple, basic fact:

We (ab)use comments in order to post things that belong elsewhere or to achieve things that should be done differently.

We've been ignoring/postponing this for years now and we should at the very least concur that we need to act. So, we should simply agree to try to do two things:


a) stop this bad habit.
b) clean up after the mess we've created over the past years.

The proposal has these fundamental goals in order to accomplish that:

  • Convert "subscribe" comments to actual subscriptions and once done, delete them.
  • Convert "+1" comments to proposal/issue votes and then delete them.
  • Convert "thank you" comments to user votes/credits and then... -you guessed it- delete them.
  • Simply delete dated "how do I?" comments/answers that are unrelated to the issues and that are already documented elsewhere.

This is the half that cleans things up. The other half that will eventually stop people from the bad ways of the past is:

  • Provide people with the means to "subscribe" without comments. (done)
  • Provide people with the means to "+1" without comments. (we need voting for that)
  • Provide people with the means to "thank" others without comments. (again... voting)
  • Provide people with links to answers near things that are prone to common questions. (#1308382: Add a "how to apply this patch" link next to uploaded patches.)

Along the way, we will...

Reduce db size -> Increase queries execution time.
Clean up comments -> Reduce time it takes to scan through and finally grasp issues.
Automate most of the procedure we currently rely on (as much as possible) -> People can focus their energy on creative tasks rather than routine.
Take the tedious task off of the hands of a few and place it in the power of the many we are in this community -> clean up faster and keep it clean with relative ease in the future.

I guess what I'm trying to say is that I realize it'll be hard to do and that it will surely take a long time (adding the follow/unfollow button took 6 years), but the benefits will be worth the effort. This issue is to be broken in many separate and each one of these will solve long-standing problems. So, -the way I see it- we'll benefit both in the long run as well as in the meantime.

klonos’s picture

And this idea will hopefully help reduce "Are we there yet?"/"What is the status?" noise: #1311586: Allow issues to be marked as tasks remaining to be done for a certain version of each project.

klonos’s picture

This is a nice example of an issue where "subscribe" comments should be deleted/unpublished:

#834252: [meta] Port Project to Drupal 7

...out of the 44 comments (at the time of writing this) 25 are "subscribe" - that's more than half of the total.

Michelle’s picture

Is everyone automatically subscribed to things they commented on before the "follow" went live? I'm wondering if we delete those manually if they will still be following the issue? Granted, manual deletion isn't the answer for the entire mess but there are cases like the issue in #6 where some maintainer might be willing to take the time to clean the issue up.

Michelle

dww’s picture

Yes. Everyone who ever posted a comment on an issue had their follow flag set during the migration. Deleting the comment will retain the follow flag. So yes, technically it's possible to do these kinds of cleanups if people want to. However, that's a policy decision that I can't unilaterally make on my own.

However, a year from now, practically no one is going to care since few of the issues people will be working on will be polluted with subscribes. So I'm not convinced it's worth the effort.

Dane Powell’s picture

@dww Agreed- I think the only reason to go to the trouble of removing old sub comments is if they are taking a serious toll on DB performance (possible, but doesn't seem likely).

killes@www.drop.org’s picture

I think we can pretty much ignore the influence on the database.

Michelle’s picture

As long as it won't mess up their follow status, I don't think we need any sort of policy since removing the comments won't hurt anything. If the subscribe comments on an issue are bothering someone with access, they can just delete them. :)

Michelle

silverwing’s picture

I have no problem removing "subscribe" comments.

My problem with removing "+1" comments is that we don't know the intent of the author. For example, a module maintainer might have asked if their users wanted a particular functionality and users would "+1" that letting the maintainer know.

And in the Webmaster queue, we use +1 to approve different things on the site. These need to be transparent so it's easy to know how approved it.

killes@www.drop.org’s picture

I suggest to follow the easiest way: leave them alone.

The issues that have these comments will hopefully be resolved soonish and only googlebot will look at them and their +1s.
There are IMO more pressing issues on drupal.org.

drumm’s picture

Status: Active » Closed (won't fix)
klonos’s picture

Status: Closed (won't fix) » Active

Battle plan for stopping spam/"subscribe"/"+1" comments

...the main goal of this issue was to implement a (semi)automatic way of dealing with non-helpful comments (mainly spam, but other kind too)

  1. without having to file new issues in the webmasters issue queue.
  2. by making the report procedure a single-click thing (via some AJAX magic à la the "follow" button).
  3. take the burden off of people having to *manually* act upon spam/abuse reports by use of a "report threshold".

Now, as for the db clean up of old comments...

(and cleaning up old ones from the db too)

...that would merely be a byproduct of solving the main issue the way I propose in the issue summary:

  • People going through old issues would simply click on the abuse link/button of such comments as they happen to come across them...
  • this would eventually cause their threshold to be reached...
  • That in turn would trigger unpublishing of such comments (plus whatever other actions we might decide).

Once again, this second thing is not the main motivation of the issue. That's why that part of the issue title is enclosed in brackets.

klonos’s picture

...despite the fact that we now have the glorious "follow" button, we still see quite a few "subscribe" comments. I am not arguing that the number of these comments will slowly diminish, but our instinctive reaction to each of such non-helpful comment is to post yet another comment in order to ask the poster to Stop subscribing, start following. Though we mean well, the end result is two comments that are of no actual use to the course of the issue being solved.

I am pretty sure that once we have figured a way to handle "+1" comments too (#42232: Help Maintainers Manage Issue Priority by Encouraging Voting), we will still continue to get some of them. Yet again people will be posting comments to ask people to "Stop +1, start voting".

A third example of non-helpful comments that is usually followed by more comments that simply add "noise" is the kind I propose dealing with in #1308382: Add a "how to apply this patch" link next to uploaded patches..

As I say in the issue summary, I see all these series of comments as spam too and it really "hurts my eyes" when I try to put together a summary of an issue. I realize that dealing with them is way too much trouble, but I don't propose to do it manually by focusing on a dedicated spam issue hunting. If we implemented this "abuse threshold" I evangelize, then I am sure that all of us would be greatly tempted to click on the "spam"/"abuse" AJAX button of such comments as we happen to come across them. Now, if each one of us flagged a couple of dozen of them over a period of say ...a year, then most of them would be gone.

klonos’s picture

@silverwing, #12:

I have no problem removing "subscribe" comments. My problem with removing "+1" comments is that we don't know the intent of the author...

I hear you David. Consider this far-fetched imaginary scenario:

  • an issue starts with the title: "Lets make drupal.org more awesome!"
  • voting is allowed and people start voting/+1 and the issue gets a considerable amount of votes
  • someone changes the title of the issue to: "Lets shut drupal.org down"

Concern of such possible attempts of "rigging" voting results has been expressed before over at #42232: Help Maintainers Manage Issue Priority by Encouraging Voting. I am confident that we will eventually figure it out.

klonos’s picture

Title: Battle plan for stopping spam/"subscribe"/"+1" comments (and cleaning up old ones from the db too). » [meta] Battle plan for stopping spam/"subscribe"/"+1"/"thank you" comments (and cleaning up old ones from the db too).

...concerning my last comment, the issue that's supposed to take care of this is: #682254: Allow multi-dimensional rating of issue comments

I'd like to mention another type of comment I constantly find myself posting that is also not helpful to the process of solving an issue. "Thank you" comments simply add noise to those that try to read through lengthy issues. I agree that this a polite form of noise and it helps to boost morale, but it still is noise. Other forums/communities allow users to click a link in order to thank a user for their comment/solution/advice. After that, there's some logic that updates a "Thanked x number of times by x users" counter next to each user's being thanked name or their profile block.

I guess we have a chance of implementing something similar in our support.drupal.org by using Flag/Voting API/Answers/whatever. Some kind of "was this answer helpful? yes/no/somewhat" radio box would do fine -though not quite the same as a "thank you"- plus a "x number of people found this answer useful" counter to go along with that. This way we can avoid the noise but at the same time provide a means to users to acknowledge the user providing the help.

dougsap’s picture

If a "Report spam/abuse" page is added, please also consider including:
[ ] This profile is spam.

I have identified over 100 profiles that I have identified with no posts, very suspect interests, links to the same (or related) non-Drupal platform urls, and zero posts (please see this if you think profile spam is not a problem: http://drupal.org/user/1578064 ). I know this is just the tip of the iceberg.

I don't like to create individual tasks for the webmaster issue queue because of the noise it would create in my posting history (and there seem to be economies of scale of batching them up in the current process).

klonos’s picture

Yeah, the latest discussions (comment #39 and after) in #226678: Add a "Report spam/abuse" link to forum/issue comments (next to the "edit" & "reply" links). seem to be shifting towards allowing people to report users as spammers rather then reporting their posts. If a user is reported and after found to actually be a spammer, all their posts will be deleted/unpublished.

cweagans’s picture

Have we thought about installing something like this on Drupal.org? http://drupal.org/project/spam

Michelle’s picture

@cweagans: there's an issue around somewhere, possibly webmasters, that's about spam fighting... Actually, I think there's more than one issue. I've lost track but I know I've seen at least one.

klonos’s picture

Michelle’s picture

Issue tags: +antispam measures

Tagging

killes@www.drop.org’s picture

Status: Active » Closed (fixed)

don't think we'll ever get around to delete the old +1s

klonos’s picture

Status: Closed (fixed) » Active

...actually no. This issue is not (only) about deleting old +1 comments.

klonos’s picture

Issue summary: View changes

added reference to #226678: Add a "Report spam" link (http://drupal.org/node/226678)

mgifford’s picture

Coming from https://drupal.org/node/1080550

Adding related issue.

Would be great to have the summary updated by someone more familiar with this issue.

mgifford’s picture

gisle’s picture

I notice that this issue is from October 2013, but still active, so I'd like to add my two cents worth.

I think spam is a major issue, and it needs to be treated separate from the other things mentioned: (subscribe"/"+1"/"thank you" comments).

The "subscribe" comments problem seems to be fixed, with the "Follow" flag. Users just need to adapt to it. I regard the two others as minor (but YMMV), and should be dealt with by moderator guidance, rather than by altering infrastructure.

Spam, on the other hand, is worse than ever. Some of it seems to be reported, but never dealt with. For instance, here is a link to a report about spam that was posted on April 8. At the time of writing (May 27), this spam is still not deleted. Leaving spam in place is bad. It results in the spam being indexed by Google and allows the spammer to siphon link juice of Drupal.org. This reflects badly on the governance of Drupal.org, and also rewards the spammer, providing an obvious incentive to spam us.

A "Report spam" link has been added to comments posted on the main domain (Drupal.org) but not to sub-domains such as (Localize.Drupal.org). However, from the UX point of view, the "Report spam" link is not a good solution.

The procedure, as I understand it, is as follws: When you spot a spam message, you should first check whether is already is in the Webmaster's queue to avoid reporting a duplicate. If it is not a duplicate, you then press the "Report spam" link, which actually submits a new ticket to the Webmaster's queue and automatically subscribes the reporter (i..e me) to this ticket (which I have absolutely no interest in following, since I can't do anything more with it). That ticket now takes up a slot in my "Your posts" panel in my dashboard, shadowing issues I am actually interested in monitoring. To get rid of it, I must visit the ticket and "Unfollow" it. Then, when somebody finds the time to delete it, I again get notified that it has been updated in my "Your posts" panel in my dashboard. That means I need to visit it again and "Follow" and then "Unfollow" it again (this looks like a bug) to stop it taking up a slot in my "Your posts" panel. When the two weeks after it being "Fixed" is up, there is the "Fixed (Closed)" message - and again it shows up in my "Your posts" panel in my dashboard, I need to visit it again and "Follow" and then "Unfollow" again (this definitely looks like a bug) to stop it taking up a slot in my "Your posts" panel.

The above procedure is so awkward and so time-consuming that I've tend to ignore spam when I stumble across it (i.e. I don't report it).

By contrast, the well-know StackExchange site uses a flagging system, with a "flag" link below each entity, where spam gets unpublished after eight spam flags. I've never seen spam survive for more than a few hours on that site. False positives does not seems to be a problem.

Having a flagging system for spam has already been proposed (e.g. unpublish spam at the third [or eigth, etc.] spam flag) and also discussed, but never implemented, allegedly due to performance problems with using flag on comments.

I am not sure I understand why this is a problem. While there certainly is a lot (millions) of comments about, adding a spam flag field to hold a spam count to each comment should not produce much extra overhead? As for business logic: when somebody presses the "flag spam" link below a count, increment the value of this by one, and check the total. When the total hits 8, unpublish the comment, and file an issue in the webmaster's queue for QA and post-mortem examination. Since no database searches seems to be involved, why shall this create a performance problem?

Mixologic’s picture

Project: Drupal.org infrastructure » Drupal.org customizations
Version: » 7.x-3.x-dev
Component: Other » Code

Im going to move this to the customizations queue, as it'll be a code fix, and not an infrastructure fix, to ultimately eliminate and eradicate spam.

drumm’s picture

Status: Active » Closed (fixed)

We have a new system for helping find spam comments, #2386751: Replace 'report spam' links with Flag functionality