1

Answer: Yes.


Who are you?

Hello everyone, I'm iBug, a computer science student who's about to reach his twenties, and also a passionate Stack Overflow and Android Enthusiasts user. I am also one of the primary developers of another community moderation project, SmokeDetector

Earlier I came up with the idea that I could help with moderation automation on Android Enthusiasts with my development skills, so I started this project, which is currently running on my personal cloud server.

What problem does this address?

As is defined by the scope of this site, questions about developing for Android aren't suitable here, and need to be closed. At peak periods, we get several questions of these a day, and we're still consistently attracting development questions, even during low activity periods. With properly built tools, we could keep our site clean by closing these questions in time.

What have you done?

Late November 2018, after discussing with our moderators, I started this project, aiming to detect development questions and bring them to mods' attention, in a fully automated way. At the beginning, the program generated mod flags from my account, and was pretty error-prone.

Before the flagging ceased in early January, it generated flags on 33 posts in total, among which 10 were false positives. In addition 3 posts were flagged a second time because they were edited, and I didn't store flagging results locally to avoid that.

After the "flagging era", the program kept running for a few weeks without visible behavior, before the following project started.

On January 28, I discovered that instead of increasing moderators' workload with flags, I could use my account to vote to close those questions. Thanks to the previous improvements, the results look better than the ones from the "flagging era".

During the period January 28 to March 17, 36 questions in total attracted a close vote from the program. Only 5 of them were false positives, and the rest were all development questions. That brought the total accuracy from less than 70% from the "flagging era" to a new level of 86% so far.

So far, all runtime statuses aren't visible to the public and are only available in the console log when I log into the server. The only publicly visible activity is its close cotes cast under my account.

Here's a preview of the console log:

log

Further plans

During the initial design of this project, I left space for further expansion, so its functionality would not be limited to detecting development questions, but other kinds of posts that could be moderated by the community, such as recommendation questions or Not-An-Answers. I'm planning to expand detection to new categories when the detection on development questions becomes stable.

I also had the idea of giving this project more public exposure, such as sending reports to chatrooms, so people can watch what post has been caught. A web dashboard is also on the blueprint, so that all caught posts are archived somewhere outside Stack Exchange, to serve as a public database of our posts that are caught by the bot.

However, due to the increasing workload from school assignments and tasks, I can't maintain a calendar for the plans.

Discussion, critiques and suggestions are welcome!

  • 1
    I really appreciate that you took this initiative on your own despite the workload you have from school and other projects. :) // About this report you mentioned though: would it be periodic, say weekly or monthly, or like how SmokeDetector detects and reports every single thing? – Firelord Mar 12 at 11:05
  • 1
    @Firelord Planning to implement as every single post, but absolutely possible to instead make it a periodic statistics report. – iBug Mar 12 at 12:23

You must log in to answer this question.

Browse other questions tagged .