Diversion: Punch in or out, with the Time Clock

  To help answer questions like "who's working helpdesk right now?" or "I need a tech over here", we used a handful of roles which were set with the "@mention" flag enabled.  That means that someone could be focused on any server channel and having a conversation, and post a message with that special @role syntax to flag any people currently on duty for that function to hop into the channel to see what was up.  To facilitate self-service for said on-duty-ness, I constructed a role-menu specifically for those "hailable" roles.  It wasn't so much a "clock" in the jobsite sense, although some of the logging actually would show when roles were assigned and deassigned to people; it was more like putting on a certain colored vest, which is what made me think of the iconography at the top.  The overall idea certainly made sense to streamline getting help to people.

For a while I wasn't sure which roles we needed to put in this, and a bit of conversation ensued around an initial set.  The first layout before actually menuing it was just to show the design crew where I was headed with the idea, and obviously it would change before being put into service.

menu-across The initial setup with item-per-line looked too squinched-together, so I tried double-spacing the entries.  That made the whole thing too tall, I thought, so in the development process I rearranged the message to spread the items across the page instead.

anna reports 'across' fails on mobile The "across" method turned out to be a bad idea as it came up totally confusing on narrow mobile devices; thanks to Anna for pointing this out.  Trying to put hard newlines in the text clearly didn't work so well either.  I didn't have a mobile set up to do Discord, so I had to rely on her view of it for feedback.

anna shows fix on mobile I went back to the "tall" arrangement and let the text flow itself more or less naturally, and that turned out to be okay.  On mobile, people are used to scrolling to see everything anyhow.

finalizing a rolemenu in-channel This is more of the sausage-making that has to happen in the channel where the menu is, and then one has to go back and manually delete all that stuff.  The long number is the target message ID, obtainable from the target message meatball menu when you have "Developer Mode" set for yourself.  The sync-up process is a little klunky, and gets even worse when you go to change any of the role icons or try to move stuff around.

Due to highly varying external demands on which roles should be in the "clock" or not and thus duty-switchable, I had to re-edit this whole thing at least three times.

icon replacement and more rolemenu finalization This type of menu was one more appropriate to graphic reaction-icons as opposed to purely numeric, but Gail didn't like some of my choices.  Another *two* edit cycles because the first try didn't sync up right.  Eventually we gave up on the separate "moderator" function anyway.

biggest state of timeclock menu, before the big cut-down It got messier once Safety and IRT got involved, and then it was pointed out that their roles were always pingable regardless and they didn't really need to switch anything on and off.  But they seemed to want some presence in this anyway.  Now I had a quandary: what to call extra items for them?  I wasn't about to *de-role* their base Safety and IRT "red shirtness", because those roles inherently carried some extra sway on the server.  As an interim hack I added a couple of "on-duty" role variants for them but none of that actually meant anything.  Again, it was all about optics.

  Then there was the battle over what power any group would hold to deal with other users, be they nickname changes or kicking out or whatever.  This went back and forth a bunch, and I kept pointing out that if any working status was to receive additional powers, it should NOT be switched through here since then any other staffer could attain those powers by simply clicking a role on the Clock.  Such things needed to be externally managed, and a decision made about who was going to handle that.

Note carefully, though: with suitable buy-in from all players, it would be possible to construct custom menus to bestow elevated power temporarily to *certain* users, or design a few bot-functions to channel and utilize parts of elevated privilege in a much more controlled way.  [See the "muting" rathole, in fact.]  In other words, with some effort you could write "sudo" in robot-ese.  Because of the complexity of Discord's role/permission model, let alone when bots get involved, the transitive paths that can inadvertently get set up when you're messing with this stuff can be subtle and escape notice.  Just like any other security problem.

clock items cutown, not menu update yet Eventually the directive came down, presumably boiled down to a final decision: Lose most of the switchable roles.  At first it almost sounded like "lose the clock", but folks like the tech crew had already decided that it was a good thing they wanted to actively use, so I defended its continued existence in some form.

So the final state was just this, before a final pass rebuilding the clicky-reactions, and I could finally leave the thing alone.  Four hailable roles left as a token gesture, and I think the only one that ever really got used was @Tech once in a while.

yag side reorder/fix This is what the final role-command group configuration looked like at the YAGPDB end.  The YAGPDB doc on role-menus lays out how to set this up fairly well, although it's a little sketchy on how the "edit" function is supposed to work.  That's one reason reworking a menu is a pain in the ass unless all you're doing is *adding* to it.

_H*   210129