Sassy Tone | enhancement

[Randall-Scharpf]

Description

One thing that a lot of our imperial unit mebers dislike is the sass the bot has, rather than simply translating the unit into metric. It kind of does it in an unpleasant way with a sassy tone. I understand the bot is made to tease imperials but is there a way to turn off the sassy tone and rather simply get the unit conversion?

quoted from CuriousGeorge on Discord

This issue is being created because there is no way to turn off the sassy tone, but there could be.

Proposed Fixes

• Add a role to the bot, to individual users, or to both that determines whether or not the bot will use the default, sassy tone or a polite tone. Details: Role precedence, role names.
  • Possible role precedence: user role takes precedence over bot role, any existing role takes precedence over any nonexistent role, and if no roles are found, default behavior is used.
  • Possible role names: bot role is named "polite" and user role is named "politeconversions" OR both roles are named the same of "polite" or "politeconversions" OR both roles have different names with similar essences.
  • Rationale: extremely simple for users and not overcomplicated for development, albeit with an expense of minor server cluttering, and provides relatively simple potential for future expansion
• Change a nickname to determine the tone. Details: how the nickname is changed, whose nickname is changed.
  • Possible nickname changes: add an instructional word like "polite" or "sassy" in its entirety to the niickname, add a symbol like | or * or ^ to the nickname
  • Whose nickname: the bot OR the user OR both.
  • Rationale: extremely simple for users and not overcomplicated for development, and eliminates the server clutter used to control the bot at the expense of having control strings appear in conversations
• Require channels to be present to control behavior. Details: channel nature and format.
  • Possible channel natures and formats: create a (possibly empty) category channel with a name that tells the bot if it should behave politely OR create a (possibly empty) text channel with a name that tells the bot if it should behave politely OR create a voice channel with a name that tells the bot if it should behave politely OR create a non-empty text channel containing all the control information for the bot from which the bot can read its instructed tone choice OR create a category channel containing empty text channels from which
  • Rationale: changes the type of server clutter, which allows some servers to better bury this additional clutter among their existing disorganization, and provides relatively simple potential for future expansion
• Store preferences sent to the bot via a message command. Details: storage format, storage location
  • Possible storage format: store an ordered list of setting strings, store a list of labelled settings strings (as in a hashmap), store a list of octets that choose settings from enumerations by each of their values
  • Possible storage location: online third-party database,
  • Rationale: creates no additional clutter and great potential for future expansion while being relatively user-friendly, but forces the bot to cease to be stateless, creating significant development complications Although it would further complicate development and maintenance, support for more than one of the possible fixes listed above, at the same time, would give users even greater control over how the bot behaves and looks in their servers.

Potential Related Issues

• Bot reply latency could be significantly increased by the need to read settings (especially in a stateless manner), and bot resource load could also suffer.
• Conflict with other bot-control structures in servers to which we deploy could occur with stateless settings.
• Legal issues are related to a bot with a non-stateless design (solvable issues, but issues nonetheless).

[Randall-Scharpf]

This seems to be a pretty highly desired change. I think, based on our discussions on the support server, that we're leaning towards a role-based approach, but I included the other discussions for completeness. I think that supporting multiple approaches through incremental updates to the bots is probably our best long-term plan of attack, but for now sticking to making sure at least just one fix is consistent is most important. Best!

[Randall-Scharpf]

Merge of the above-mentioned PR is requested due to the already cited "high desire" for this change relative to the other issues here.