Many spammers use GitLab.com to create spam. Starting with 8.11, GitLab has better integration with Akismet to check for spam whenever a user creates an issue. This filter needs to be trained properly, however. With some effort our spam detection should improve. If an issue is created on GitLab.com by a spammer, before deleting the account, flag the user's issues as spam:
Where multiple issues are created or commented on,
GitLab team members can also report spam in the #abuse Slack channel by tagging the @trust-and-safety team.
Once the issues are flagged and the user is verified to be a spammer, go to the spammer's user profile and click on the "Report Abuse" button:
Both the Akismet filter and Spamcheck may also flag false positives and prevent a user from creating issues. The contents of the flagged issue get stored in the spam logs, which is only accessible to admin users. If you're unsure whether Akismet or Spamcheck is disrupting the creation of artifacts(issues, snippets, etc) you may diagnose the problem as described in the Security runbook entry for falsely labelled spam.
From time to time, we may need to submit the flagged issue as "ham" (e.g. when a user lodges a complaint on the Support Tracker about not being able to create issues). Currently, there are no notifications whenever an entry is flagged, so this needs to be monitored periodically. To flag an issue as ham:
At times GitLab.com can appear overrun by specific types of spam. Spammers often target public snippets, projects, issues, and merge requests for advertising their wares. Details on more advanced spam fighting techniques can be found in the internal GitLab-only Spam Fighting Google Doc.