Yes, the proposed dashboard could be a room (to feed the Dashboard) with the inverse of "Traffic" used to determine the waiting time, and if when we get (scrape) the page there's 10 views already then divide by two, before making an alert that we have one for say 10 minutes and need 5 more or two the same and divide the 10 by 2, etc. --- I don't know what logic you want, and since you are writing it ...
The basic idea is that very few views and unconfirmed can wait behind multiple confirmations and lots of views - very high score should probably percolate to the top of the list too.
@thesecretmaster ^
Mak, trip, and art probably have some thoughts on this.
@Rob I'm not sure I follow this idea? My understanding was that it would be nice to have a dashboard / api endpoint for posts older then some threshold that have tp feedback and have not been edited/deleted, potentially sorted by how many flags have been cast already.
@thesecretmaster The "older than some threshold" feature is described in this text: "delay: introduces a 5 minute delay for reports; reports won't be posted if the post has been marked as false positive or deleted within the 5 minute window." here: github.com/Charcoal-SE/SmokeDetector/wiki/Rooms-configuration). --- So create a room, give it the delay flag, whenever there's a post the Dashboard can refresh it's scrape of the room. In addition, people not installing the Script / Plugin on their
@thesecretmaster If so, then we will need some way to A) manually remove posts from that dashboard which don't actually need any additional handling (that will be needed regardless of any automatic checking), and (maybe) B) a way to re-add posts which have been removed from the dashboard, and (maybe) C) an additional way to inform MS that the post is deleted.
As far as I know, MS doesn't monitor the status of posts, or even check for posts being deleted. SD does that monitoring, but only for a limited time, and forwards to MS both when and that a post has been deleted. After the time which SD monitors for (until deleted or the first reboot after 2 hours), the monitoring stops and no update is ever made to or in MS that the post has been deleted. So far, the choice has been that the deletion data would only come from SD, not users.
Hmmm.... it looks like SD expends, potentially a bunch of, SE API requests checking on posts which are in the DeletionWatcher process each time there's a reboot. Those requests don't appear actually needed (fetching data we should already have, but just aren't saving).
You might modify the code to enhance the room, providing more features than simply "no FP, and 5 minutes" or you might put the brains in the monkey script / plugin (which some people can't install).
@Rob I'd rather not expend chat quota having SD post chat messages which are intended to communicate to MS when there's already multiple direct ways SD can communicate to MS.
Allowing users to inform MS that a post has been deleted is something I'd want to run by Art/Undo because I believe not adding that feature was intentional.
I've really been meaning to get back into working on MS but I'm experimenting with switching to vim as my main editor and every time I open up the project I end up going down a vim rabbit hole :P
@Rob At least both FIRE and AIM work perfectly well when just loaded into the page. They function just fine in mobile browsers and can be loaded by executing a bookmarklet. In other words, there's no need to actually install them as userscripts, so they are available to people in environments where userscripts are not available.
At some point in the future, loading one or both of FIRE and AIM not as a userscript may result in some reduced functionality, but the plan is to keep them useful, even in that mode.
@thesecretmaster I'm assuming Core only for adding/removal, with the dashboard available to anyone.
@thesecretmaster Something of concern when creating such a dashboard: Users should not have the ability to provide feedback and/or flag unless looking at the complete post, detection reasons, and why data on the page where the feedback/flagging options exist.
I already have JavaScript which allows feedback and flagging from MS post lists, but haven't released it, because MS post lists don't contain enough information to make complete decisions, except in limited circumstances. Enabling those options without all the data available could lead to people just blowing through posts without really putting much thought into each post.
Having such feedback/flagging options available directly from post lists, even if all of the above data is available, still concerns me, as having those makes it very easy to blow through feedback and/or flagging at very high rates (< 1s/post is possible). That's not something I'm really comfortable enabling.
@thesecretmaster, the conversation started here ten hours ago; that's before discussing a means to automatically remind people that a report needed more flags to complete the action, instead of replying to the SmokeDetector report (in multiple rooms) creating multiple comments on the MetaSmoke's page, and then the pinger(s) needing to go and delete their own messages, saving the Admins from having to cleanup
@thesecretmaster This could be something which is primarily an option in Search to show posts which aren't deleted, but have TP feedback.
Hmmm... This also wouldn't be that difficult to do as an overlay to the /posts page. I already have a considerable portion of the JavaScript that would be needed (live addition/removal of feedback markers, live addition/removal of comments, auto-hiding posts which are "complete" (would need to change a bit, as it's focused on which posts still need feedback from the current user, not which need flagging)).
Adding a live display of what posts are deleted wouldn't be that much work, as it's data that MS broadcasts in its WebSocket (although that data isn't, currently, in the data available in the post list).
I've gotten a bit absorbed into the idea of a dashboard.
Stepping back from this a bit, it's not clear to me that a dashboard on MS really resolves the underlying issue which was attempting to be addressed by people posting "Still alive" messages in chat. The goal of those messages is to draw people's attention to posts which someone feels are TP, but which haven't, yet, been deleted via flags.
Primarily, the people whose attention is attempted to be attracted are those who are not already watching SD reports or who have joined chat recently, after the SD report is no longer visible in the messages they are viewing. It's not clear to me that a dashboard on MS would communicate to those people (i.e. they would actually need to routinely go to MS and look, which they are already not doing; they are not even scrolling up in chat to see if there are unhandled SD reports).
If people are actively looking (which they would need to be in order to be using a dashboard on MS), then most of the data to accomplish finding such posts is largely available on MS' /posts page or in chat.
Creating a dashboard page on MS is providing an additional (or alternate) place for people to be watching for posts to handle. I'm not really sure how much that will help the root problem which was the impetus for thinking along these lines.
That makes a lot of sense actually. I think that an MS implementation wouldn't be too bad to write (I think it would make sense implemented as its own feature separate from search), but now that you point it out, it sounds like this is a feature that would really want to live on chat/a userscript rather than on MS.
@Makyen I agree, and that's what I was hinting at to @thesecretmaster in my last comment: 'Where did this start ...'. I don't mind expanding on the idea, or adding extra functionality, but let's not get featuritus (too far off track).
Instead of replying to SD, I don't know why people couldn't just use the chat functionality available:
@Rob Because, at least I, find that less useful (and much more annoying). If you had replied to the message, rather than quoting it, there would have been a button I could click that would scroll the current page to the post or automatically open a new page with it, if the original message had already been removed from the existing list in the chat room.
Yes, I could click the link in the relative time, but I don't want to open a new page/tab, unless I must do so, which I normally won't need to do so with a "Still alive" message.
Quoting the chat message takes up a lot more vertical room and requires 2 chat messages, rather than one.
If you were to start doing that in here as a way to post "Still alive" messages, I'd ask you not to do so.
[ SmokeDetector | MS ] Bad keyword in body, bad keyword in link text in body, bad keyword in title, potentially bad asn for hostname in body, potentially bad ns for domain in body (264): Is escort services legal in india? by Tania 4you on meta.SE (@Ollie)
[ SmokeDetector | MS ] Bad ip for hostname in answer, link at beginning of answer, potentially bad ns for domain in answer, potentially bad keyword in answer, username similar to website in answer, +1 more (270): DatePickerDialog Romanian months by guns Atlantic on stackoverflow.com
@Makyen It seems that comments many years old are infrequent, but kept if useful (2 examples: metasmoke.erwaysoftware.com/post/161851metasmoke.erwaysoftware.com/post/160609). Perhaps a simple solution is that if we don't want a comment to be automatically deleted from the [MS] page after 2 or 3 months we prefix it with "+ " - so, we reply to SmokeDetector with "needs more" and that's deleted automatically and we write "+ This spammer has this other account" and that comment
stays until it's manually deleted.
People who want their comments kept need to remember to use the "+ " command - it uses up very little additional space, especially in light of the space recovered.
@Rob Let's not. I don't see having a moderately small number of comments not deleted which might be deleted if reviewed by a human as a significant problem. I'm not interested in having an automatic process deleting them, other than, perhaps, specific things with which we have an issue (e.g. we could create something which specifically targeted "Still alive" comments, but even then it doesn't seem like all that big of a problem).
My concern is, primarily, not deleting things which might be useful in the future.
I just haven't seen enough spurious comments, and particularly not enough which couldn't or weren't handled either by the user who posted them or within a semi-reasonable time after an Admin flag was raised suggesting that the flag be deleted in order to justify development time and/or the risk of deleting potentially useful comments.
@Makyen I see them several times a month, at least, in The Tavern; frequently those people's comments don't show up (when I check immediately) presumably because either they didn't have permission or they lost permission by doing that.
@Rob My messages above might have come out a bit harsh (and then my internet connection dropped out). I'm sorry that they might have been a bit more acerbic than should have been the case. I'm willing to be convinced that something should be done, but I'd need to see indications that this is significantly more of a problem than I currently believe it to be.
[ SmokeDetector | MS ] Blacklisted username, potentially bad keyword in answer, potentially bad keyword in username, blacklisted user (163): Merging pdf attachments by FileZIPO on salesforce.SE
@tripleee That pattern looks like it's already caught by Potentially bad keyword in answer and Potentially bad keyword in body Append -force to the command if you really want to add this pattern.
Please don't play with me too much; I'm a serious bot meant for detecting spam, not for playing around with! I've got some fun features, but please be careful not to abuse them.
@tripleee Based on what @Makyen wrote around here, I'm a little less sure of how good an idea it would be to add to MS. I can definitely still take a stab at it, but I wanted to make sure you saw that first and still think a post list on MS is a good idea.
[ SmokeDetector | MS ] Link at beginning of body, potentially bad ns for domain in body, potentially bad keyword in body, potentially bad keyword in title (43): What is an uber clone? by dmmarketing on graphicdesign.SE
[ SmokeDetector | MS ] Bad ip for hostname in body, bad keyword in body, bad pattern in url body, blacklisted website in body, link at beginning of body, +4 more (522): What is Slim Tactics Reviews? by nihiamatila on superuser.com
@JeffSchaller That pattern looks like it's already caught by Potentially bad keyword in answer and Potentially bad keyword in body Append -force to the command if you really want to add this pattern.
