Hydrant - A Dashboard for Heat Detector

[Bhargav-Rao]

Hydrant - A dashboard for Heat Detector

After collecting some important points about the new dashboard, I'm compiling them here and formalizing the creation of a new dashboard.

Need

Heat Detector is quite famous networkwide for its ability to detect rude and abusive comments.
However the problem that we are facing at hand is that not many people are feeding back accurately
(The bot utilizes ML and feedback is very very important for it's improvement).
This issue can be easily solved by having a web dashboard.

Thoughts

Unlike CopyPastor, which had to be written from scratch, the dashboard for HD can be easily modeled based on Sentinel. The similarities between Natty and HD are:

• Both are related to flagging (comment vs answer)
• Both have various reasons for detections
• Both need feedback

Changes

Changes needed on the HeatDetector side:

• A proper/strict rule to differentiate between what should be a true positive and what should be a false positive.
• A way to provide feedback through a command, so that a userscript could be made use of.
• And of course, calling the dashboard in every report.

Challenges

• Framing the strong rules to differentiate between a heated argument and not is often subjective. Quantizing this in someway in order to improve the algorithm would be the first challenge. (This is not related to the dashboard development work, but the way we provide feedback).
• Few of the posts might be borderline, and we wouldn't want to feedback these. Hence a way to "not provide feedback" would be needed.
• We are also tracking a few keywords like "spam", "rude", etc which aren't noisy comments, but are meant to help us discover spam or r/a posts. We need a different feedback type for this.
• We need to find a way to anonymize the data which we display on the dashboard. Some kind of a login would be nice, but one other idea is to display minimal information (just the comment text and reasons, for example), and display all the details after logging in.
• Art is very very busy at the moment and certainly won't have much time to design the dash. Hence we'll need to either do it in one of the languages which we know or recruit someone who knows Ruby and RoR. Given that we still haven't put up an opensource ad this time, it might be a bit hard.

Hosting

We can host it on the sobotics webserver. That would not be an issue.

[Papershine]

For borderline comments, it would be good if there was a system similar to SE's "aged away", so after a comment that has no feedback will be marked as "Aged away" and disappear from the review queue.

[jdd-software]

I think on of the core issue with the dashboard is also to manage the feeds (bad/good) and also maybe the regex used.

Hence interface to view the good and bad feed, possibility to remove and add comments to feed (naturally only if user have admin privs, which means dashboard needs login system)

Note: I have never added comments tp comments automatically to feed (this would give duplicate comments and a final review before adding is almost always need). The tp/fp feedback I only use to filter out what is interesting to add to different feeds.

The current structure of HD is that it uses a mysql database (it already has user registration, comments table etc), the current feedback table needs to be restructured but it's not a major problem

[rjrudman]

I'm interested in creating a generic dashboard for bots, so that we won't have to invest much development time hooking up new bots.

I've created a repository here named Higgs. Ideally, we'll be able to come up with a bunch of criteria which encompasses the majority of bots' needs. Whether or not we create a forked front-end for each bot is up for debate. However, the backing behind it should be generic.

Planning to use the following technology

• Postgres database
• C# (WebAPI on dotnetcore)
• Angular
• OAuth
• Swagger

[Bhargav-Rao]

Would it possible to make Higgs similar to a service layer?

Higgs would expose APIs to store into the DB, and multiple dashboard frontends would write into it. Each new dashboard would get its own set of tables. The tables would be generic for every bot:

• posts (content, user, links) : Can be used for comments, answers, questions.
• feedback : Feedback types
• reasons : Reasons why that particular post was reported

It would help reduce redundancy, but then, it would also imply that we would need another API exchange, which might increase the latency.

[rjrudman]

From chat

@bhargavrao I'll sit down on Saturday and run through the current bots and their needs. I'm really hoping to avoid tables made specifically for bots. Though there will definitely be the concept of storing 'attributes' as blobs, similar to how the SOReports page works
That said, I'm open to having specific tables if it's really needed, but I'm hoping to avoid that. So that the only work we need to do to deploy a bot's dashboard is set it up with some credentials