Verify fix for #36

[tripleee]

Create a test room and check that the PR for #36 really works over time. Reopen the ticket if not.

[tripleee]

Created a new room https://chat.stackoverflow.com/rooms/250328/test-room-for-sloshy-pr-36 and added it to Sloshy: https://github.com/tripleee/sloshy/commit/9a41e987def3978dbce0fcb2d5ddac74bc7eb40b

[tripleee]

Failed (Nightly #560)! Reopening #36

[tripleee]

Retrying with lower threshold and new test room https://github.com/tripleee/sloshy/commit/581ff15f934c5a3fdea3e64ff3d8bd4c4143891c

[tripleee]

Actually, the implementation is also buggy in that the aggressive threshold is applied to rooms where it should not be applied (recently, Matter Modeling: ASE Software, MOLPRO, Sloshy, and Duck Overflow)

[tripleee]

Also created https://chat.stackexchange.com/rooms/141407/another-sloshy-test-room to test the effect of feeds. I'm guessing the 15 messages include system messages ...?

[ndattani]

"I'm guessing the 15 messages include system messages ...?"

That's correct. They don't count for the required 15 minutes.

I wonder if we can switch to a 14-day cycle across all rooms? For rooms that don't yet have a total of 15 non-system messages (which statistically will be a small minority of the overall population of rooms), it's probably easier to manually post 14 messages and have a second user post the 15th message (since the 15 messages need to be from at least 2 separate users).

Originally I was already feeling that the 12-day interval was shorter than necessary. Before Sloshy when I was manually keeping rooms unfrozen, I put a lot of effort into posting as infrequently as possible in order to minimize the number of "content-poor" messages. Here you can see that I was posting such messages "14 days later" than the previous ones:

Sometimes I even managed to get it to say "15 days later":

but that can be difficult because it requires posting between 14 days, and the next midnight (the window of time available for this would only be about 2 minutes long if the previous message 14 days earlier was at around 11:58pm).

Sloshy seemed to write a little bit more frequently, usually "12 days later" than the previous message:

I always felt that being early by 2 days each time, was unnecessary, but small enough that it could continue until I could make a pull request that optimizes it, but now we are alternating between "5 days later" and "6 days" later, which is more than double the frequency that we had before:

My recommendation (or "feature request") would be to switch to a 14-day cycle for all rooms, and I can try to optimize it better to get it closer to 15 days when I have more time. What do you think?

[tripleee]

The cycle is tighter than necessary by design, to give me room to react when the nightly job fails for whatever reason. Changing it to 14 days would be a simple configuration change, but require me to jump in on short notice if Stack Exchange was down when the nightly ran, or whatever.

Unless you are volunteering to commit to religiously monitoring each nightly run and taking manual action when required for at least a year or two...?

[ndattani]

I'm okay with the 12-day cycle that we had before, which was still more than 2x longer than the current cycle of about 5 to 6 days.

Regarding #36, maybe it could be made a requirement that all rooms must have at least 15 messages by at least 2 people, in order to install Sloshy in them. This is the criteria that SE has set for deciding which rooms are "important" enough to freeze on a 14-day cycle rather than being deleted on a 7-day cycle. If a room is deemed by SE as not being important enough to stay open for more than 7-days, I guess it wouldn't be considered important enough for a Bot either.

I'm happy with whatever you decide, and was just bringing this up because the 5 to 6 day cycles may be seen as a bit to frequent by some people. Extending from 12 to 14-days is much less important :)

[tripleee]

Test room #3: https://chat.stackoverflow.com/rooms/251502/test-room-for-pr-36-take-3

[tripleee]

Discussion about the underlying feature continues here: https://chat.stackoverflow.com/transcript/message/55901645#55901645

[ndattani]

Sloshy seems to think that the ORCA room on MMSE is a room that needs messages every 7 days, when in reality it only needs messages every 14 days (you can see that at the beginning it said "13 days later", which means that the room won't close for about 14 days):

[tripleee]

@ndattani Thanks for the report; indeed, there seems to be a problem with the logic still.

[tripleee]

For the record, the activity in the ORCA room is now correct. I don't think I directly changed anything, so there is probably still something weird about how exactly it tries to find 15 messages from 2 or more distinct users.

[ndattani]

@tripleee I think it was not counting all of the messages. Looking for 2 distinct users is easy, but determining what counts as a "message" and what doesn't, is a bit more of a grey area.

In any case, if we make it a requirement that all rooms need to already have at least 15 messages from 2 or more distinct users, then we don't need to include the logic that counts messages.

The only time I see there being a need for Sloshy in a room that doesn't yet have 15 messages from 2 or more distinct users, would be for for rooms that are being used for testing things, and in those cases the owner can just write 14 messages themselves and have sloshy write the 15th message, then the "15 messages from 2 distinct users" requirement is met.

[tripleee]

What counts as a message is pretty straightforward actually. The chat transcript clearly demarcates each chat message inside an HTML structure with attributes which identify its author, contents, timestamp, etc. If the author's ID is negative, it is a system-generated message, which does not count towards the total.

There could be some glitch in the logic still (as per comments above) but on the whole, the current implementation seems to do what I originally intended.

I'll probably close this ticket and defer to a new ticket if a reproducible problem can still be identified.