SO-ChatBot
SO-ChatBot copied to clipboard
Zirak
ability to move messages
Let me start by saying this is a powerful command and we should think it out fully before implementing it. With that said:
I am proposing three commands: !!move !!bin and !!trash (yes the bin and trash are just handy aliases)
!!move (search condition or inputs) (room id)
Example:
!!move from: 123 to: 456 room: 17
this would move all of the messages in the current room in the range provided (inclusive).
Other search condition and input formats:
!!move from: 1234 to: 1245 room: 0
(bins all messages from this room in the range [inclusive])
!!move 123 room: 0
(bins said message id from this room)
!!move 123,456,789 room: 0
(bins all messages in the list)
!!move allfrom: userid room: 0
(bins all visible messages from said user in this room)
The two aliases would function the same except that when calling them from their alias you would not need to pass in a room ID.
Restrictions: I think it only makes sense for OWNERS to have the ability to do this, however like other commands non-owners should be able to stack up votes and have this happen (This is where the real "handy" side of it comes in. If there are no owners present and we need to bin some content... the bot can clean up for us!)
We should also restrict the rooms content can be moved into as well ( I can see some of the rooms, like C++, not liking it if some novice users started dumping stuff into their room.
What permissions would the bot itself need to be able to do this? Site moderator?
This goes too far. It will make it MORE complicated to move a message using the bot than manually.
On Jan 10, 2014, at 1:56 PM, Robert Lemon [email protected] wrote:
Let me start by saying this is a powerful command and we should think it out fully before implementing it. With that said:
I am proposing three commands: !!move !!bin and !!trash (yes the bin and trash are just handy aliases)
!!move (search condition or inputs) (room id)
Example:
!!move from: 123 to: 456 room: 17
this would move all of the messages in the current room in the range provided (inclusive).
Other search condition and input formats:
!!move from: 1234 to: 1245 room: 0 (bins all messages from this room in the range [inclusive]) !!move 123 room: 0 (bins said message id from this room) !!move 123,456,789 room: 0 (bins all messages in the list) !!move allfrom: userid room: 0 (bins all visible messages from said user in this room) The two aliases would function the same except that when calling them from their alias you would not need to pass in a room ID.
— Reply to this email directly or view it on GitHub.
As far as the bulk commands work, they're too powerful to be used as a glitch or error could cause a massive accident.
My vote: She's a companion/funnyBot, not a moderator, unless that's the direction you intend to step in?
Just my opinion though.
On Jan 10, 2014, at 1:56 PM, Robert Lemon [email protected] wrote:
Let me start by saying this is a powerful command and we should think it out fully before implementing it. With that said:
I am proposing three commands: !!move !!bin and !!trash (yes the bin and trash are just handy aliases)
!!move (search condition or inputs) (room id)
Example:
!!move from: 123 to: 456 room: 17
this would move all of the messages in the current room in the range provided (inclusive).
Other search condition and input formats:
!!move from: 1234 to: 1245 room: 0 (bins all messages from this room in the range [inclusive]) !!move 123 room: 0 (bins said message id from this room) !!move 123,456,789 room: 0 (bins all messages in the list) !!move allfrom: userid room: 0 (bins all visible messages from said user in this room) The two aliases would function the same except that when calling them from their alias you would not need to pass in a room ID.
— Reply to this email directly or view it on GitHub.
Just playing devil's advocate (I'm not bringing this up to indicate that I might actually feel this way), but do you think SE would have any problem with the bot acting in some moderator-ish fashion? Do you think they'd ask us to remove this feature much like the auto-greeter?
I personally like the feature idea, but I worry that our overlords might view it as an attempt to encroach on "their" territory or something like that, by making the bot too useful. Do we get permission first, or just do it and then ask for forgiveness and beg for unsuspension of the bot account(s) later?
Since these features are involving significant moderator-esque functionality, I think we need to at least tread carefully, and test this code a bit more thoroughly than we otherwise would (in a sandbox room) before pushing it, but other than that, I don't agree that we should shy away from it just because a glitch could cause a major problem. We test until we're sure there isn't a glitch. Secure the bot account and secure the server it runs on. Done.
Definitely can't be done if the bot needs diamond moderator status to do this, though. It's a waste of a diamond to give it to a bot, even if it managed to win an election by having someone(s) push it through via eminent community participation and lots of advertising and compelling rhetoric.
Moving messages only requires room-owner status on the subject room (moving from 17 to 11 means you must be an owner of 17), nothing too fancy. It'd be good to receive moderator feedback before implementing, like we did with /mute.
One more comment: When you design this feature, please keep in mind that (1) not all bots are on chat.stackoverflow.com (there's chat.SE too); and (2) bots which are not room owners in any capacity should be able to run without crashing or throwing a nasty error with this command "enabled" (enabled in this case means that the code implementing the command is not deleted from the source tree). Something like returning a message saying "This bot is not a room owner; unable to perform requested operation" would be fine.
I'm assuming that whoever implements this is probably already aware of these constraints, but I'm just throwing them out there to make sure that the solution ends up being robust and doesn't just fall down whenever the bot's environment doesn't exactly match that of the specific bot "Caprica Six" in chat.so/js.
@Jhawins re: more complicated - that is debatable. if you think the command wouldn't be useful for you then don't use it :) - re: more powerful - well that is sort of the idea. The bot is a room owner who will action on user input. If room owners are around (which they more often are) then they should be cleaning up the transcript accordingly. However for the off chance they are not this is a way for them to move messages without pinging an owner or mod. Just a consideration.
I would love to get some moderator feedback on this, however as it has been discussed with the welcome command so long as their is actual user input to trigger the bot this type of stuff is okay.
Glitches can be avoided, code smart.
@allquixotic I think honestly at this step of merging from fun toy to moderation tool it's important to recognize that the bot is sometimes a nuisance. Should a non-room-owner be able to run the bot at all? Maybe we should force the bot to request permission from a room owner before actually functioning, this would be doable as the list of owners can be easily fetched. A message can then be expected to say something like "yes" or "go ahead" which the bot would take as permission to enter, and obviously post content into the room it is in.
I think instead of making sure that elevated privileges aren't required for running the bot, we should make sure they either do exist, or that the bot seeks permission from a user with such privileges before disturbing the room at all. Thoughts?
I don't think simply adding this command is the right move, there have been too many small additions and the bot is becoming somewhat cluttered with addons conforming to the way the bot runs. She needs a real update before she becomes a real tool.
@Jhawins It is completely nonsensical to attempt to restrict what someone can do with a bot they are running on their own system. The bot is open source (unless Zirak was planning to take this repo private on Github...). If someone downloads the bot and finds that it restricts a desired behavior using code, it is almost trivial even for someone who does not understand JavaScript to remove the offending restriction and recompile.
This is why no open source software with DRM exists, or indeed, can ever exist (unless permission by the copyright authors is granted to compile and distribute a modified version of the open source software with a DRM component added, and leave that component out of the open source version while not adding certain features to the open source version that the closed source version has).
On the other hand, making sure that the bot behaves gracefully in the case where the bot does not have room owner status, is just a matter of covering all your bases when writing robust software. To omit that case would be to leave the bot open to arbitrary behavior in the event that your program's assumptions about its external environment are invalid. Even if we took your advice to heart and made darn sure that the bot is only "allowed" (by its own open source code, which is almost contradictory to even think about) to interact with the room upon being given "permission" to do so, it would still be a software engineering fallacy to assume that the bot has room owner status without even checking for the possibility that it isn't.