In change #3321, offensive/potentially bad titles are now censored in all rooms except MetaSmoke. This is a regression in functionality as we now have to click through to the question to see what the title is. Prior to this, such reports were able to be handled/responded to potentially without ever clicking on the link. I also don't see any convincing reason to censor offensive titles in the first place. It's also a little odd that the post that inspired change #3321, #811, was declined... it seems like rather than turning offensive titles off for all rooms, it should have simply been turned on for the one room where Catija was concerned about offensive titles "being hurled at them".
Preferably, I'd like to see this reverted completely, as the reasoning given for excluding MetaSmoke room frankly applies to all rooms: if you are hanging around a room where SD is posting these reports, you've signed on for the occupational hazard of having some bad stuff put in front of your face every once in a while.
However as a secondary solution, I'd like the ability to have it turned off for additional rooms (in this case, namely SOCVR, as I'm a Room Owner/participant there).
I'm aware this is something that's been discussed and may be getting implemented as a Hacktober challenge, but I didn't see a dedicated issue yet. I am also aware of #3353, but it's unclear whether this is something that would be handled by that PR.
Preferably, I'd like to see this reverted completely, as the reasoning given for excluding MetaSmoke room frankly applies to all rooms: if you are hanging around a room where SD is posting these reports, you've signed on for the occupational hazard of having some bad stuff put in front of your face every once in a while.
Not necessarily. Tavern in particular comes to mind. As it's the general chat for Meta, it gets more first-time SE users and first-time chatters; the same is true of a number of sites' main rooms where Smokey posts. The _ability_ to turn off offensive titles without turning off the reports for them is a useful ability to have.
The author of #3353 may be working on this, since someone else got to the feature they were originally working on before them. We'll give them a bit of time to see if they've got work ongoing on this; undercutting them twice would be rather churlish. If not, then we can implement a new room role to allow rooms to opt out of no offensive titles; CHQ will have that turned on, other rooms can request it.
A comment I made on PR#3353 had an idea for an outline of how to implement this. Given that a new PR should be created to cover this, it's better to have the information here):
Well, given that room configurations are controlled by rooms.yml, what's probably needed is an additional configuration option in rooms.yml under
msg_types:which is something like:- dont-mask-offensive-titlesThat config would then be placed under all rooms in which offensive titles shouldn't be masked (i.e. Charcoal HQ).
Then
chatcommunicate.tell_roomswould need to be able to be called with appropriate arguments indicating 3 different cases:
- The message should be sent ignoring that config option (i.e. just obeying the criteria as they currently exist). In other words, basically what happens now (i.e. all current calls to
chatcommunicate.tell_roomsshould continue to work).- The message should be sent to rooms qualifying by the other indicated criteria, but also requiring having the
dont-mask-offensive-titlesconfig option.- The message should be sent to rooms qualifying by the other indicated criteria, but also requiring not having the
dont-mask-offensive-titlesconfig option.This could probably be handled by adding that config option to Charcoal HQ in rooms.yml and using it as a prop in the
hasandhasntarguments.There might be a better way to do it, but that's what I see off the top of my head. I've also only taken a relatively cursory look at the code in this area, so might be missing something.
Completed with 627fbc6e85d9f3aaa661af8bef0fac46566d1e1c. Actually quite glad I _didn't_ leave this one for HF; there was a bunch of refactoring that needed doing, and there was quite a bit of nuance around the chat communication that would have needed some length of experience with the project.
Most helpful comment
Completed with 627fbc6e85d9f3aaa661af8bef0fac46566d1e1c. Actually quite glad I _didn't_ leave this one for HF; there was a bunch of refactoring that needed doing, and there was quite a bit of nuance around the chat communication that would have needed some length of experience with the project.