Changes to the Goat Place Discord

[philpax]

Not sure if this needs a DIP, considering it could be actioned in a few minutes, but good for community feedback:

• a #meta channel to discuss changes to the Goat Place Discord
• a role for Dalamud developers (possibly roles for each subteam in Final Comment: Formal subteams #18)?

[reiichi001]

Not sure if a DIP is the best place, but I'd been working on drafting up some changes to propose. Some language in it may need to be sanitized.

Discord Server Modifications Proposal.

This was previously going to to to an admin section, then to mods, but I feel like getting input from moderators and other core devs would also be beneficial. (Or support users, if we've made it that far by the time this is discussed and/or implemented)

This post servers as a basis to begin re-organization of channels, roles, and permisisons to better suit the growing needs of Goatplace in such a way that members can find which channels/access they want while also providing additional access to devs and support members appropriately.

Categories/Channels:

• I think we're mostly good on this front, but there are a few changes I'd make based on recent feedback and interactions with users.
• First, create a Dalamud category.
  = The goal of this category would be to direct users here when they experience Dalamud crashes.
  = Currently, users basically pick XIVLauncher-Help or Plugin-Help, but neither of these really are a good fit.
  = XIVLauncher-Help should stick to purely XIVLauncher (maybe XLCore later) related troubleshooting topics
  = Plugin-Help should ideally be used for questions related to using plugins or issues encountered when using plugins that aren't a result of the plugin just crashing Dalamud.
  = Ideally, any user who says they're crashing once the game is opened will directed here if they have Dalamud enabled. It's easy to check the XIVLauncher log to verify this, and issues with the launcher failing to open FFXIV are generally pretty rare.
  + We can ask support staff to help guide users here when they determine it's a Dalamud crashing issue, even if the solution is "please remove all of your plugins" at first.
• Second, move #known-issues-faq up to the General category.
  = Our known-issues-faq channel could probably use some cleanup, especially in regards to pruning old information and rewriting the more persistent FAQs to be more readable. (Perhaps they should be cross-checked with the FAQ site and relinked accordingly? )
  = During maintenances and other incidents, we should be more proactive in providing updates or listing out the current status of affairs. They could go into this channel or we could bring back the temporary updates- channel to use.
  = This also means that when the time comes to hide channels for XIVLauncher, Dalamud, and Plugins during maintenances, we can use Category permissions and channel permission syncing to take care of this (outside of release channels, but I honestly think those are fine being visible since users cannot interact with them). We could either make a dedicated /lockdown command for Franzbot dedicated to locking by category, or just do all the things we want and then we manually clean them up later. (I'm for more automation and consistency. It's admittedly a nightmare to sort out who did what and what else needs to be fixed up after a FFXIV patch. Let's make it easier for ourselves)
• Third, rename the *-suggestions channels to *-feature-requests.
  = Users appear to -really- struggle with separating their requests and suggestions from "how do I use " questions, and "suggestions" gives the implication that they can/should ask their usability questions there.
  = Give the suggestion channels a persistent cooldown to dissuade discussions. Make it 5+ minutes. If this works appropriately, we can phase out Franzbot kindly recommending people to stop talking in these channels. Or better yet, we can make these suggestion tracker channels and create a Franzbot slash command for goatplace and/or a website that users can use to submit their suggestions if they lack a github account.
• Fourth, reconsider how #Franzbot-uploads works.
  = This is a tricky one because the permissions on this channel are strange (will cover in roles later).
  = There are times when non-core devs or non-mods may want/need to access logs that users relay here.
  = Additional thoughts needed on how to better handle this channel/relayed logs so that we don't end up in situations where a user DMs Franzbot to upload a log and the dev who needs to see the log cannot.
• Up for debate/more disccussion: Move special-access dev channels to a separate category
  = Tossing this in just in case we want to consider doing this.
  = Would include, #feedback, #after-hours, and #franzbot-uploads.
  = Maybe more administrative DIPs would go here?
• Up for debate/more discussion: Move moderator/admin/etc channels to a separate category
  = Similar to prior. We really only have 3-ish admin channels, #moderators, #admins, and #log, but maybe #franzbot-uploads goes here?

Roles and Permissions:

• This is going to be the more complex thing to handle.
• Frankly, our non-user permissions are in a bad place and are in need of consistency and probably even lockdown.
  = Split/assign demogoat into like, the actual admin-ish, core-dev, and goat-friend roles separately. All names subject to change
  + admin-ish things should be absorbed by the existing moderators and maybe a support role. There's no reason demogoats should be getting special permissions or special access when the role itself is assigned a bit arbritrarily and is a common pain point for plugin-devs who see some of the other plugin-devs getting the role, which grants them additional access and makes them immune to some timeouts. That last bit is an issue.
  + core-dev should be assigned to the users who might need better-than-plugin-dev access. This should be reserved for major contributors be it commits or research. If we're planning to keep franzbot-uploads locked down, these users should be allowed to see it. Think: Adamin, Aers, Dae, Perch, Meli (if they return), Kal, Kizer, etc. Anna and Cara probably fit in here too. Perhaps Kara as well? Usagi might also fit into this role as they contribute a lot of XLCore and wine research. This shouldn't grant "manage messaes" permissions, but maybe these people should be allowed to post into #announcements and #known-issues-faq as it should be reserved for users we trust, both in terms of commits and in terms of behavior. Basically, people we'd trust to make a Dalamud commit that could be merged without too much review.
  + Goat-friend role would then be used to give users access to the private dev channels even if they don't have an actual code commit history to justify that in terms of commits to XIVLauncher, Dalamud, and/or Plugins. This is probably what Ay, Demo, Nono, and Phil would get, although Phil's efforts for organization would likely qualify him for core-dev. This could be more or less granted at your whim, but it wouldn't be granted any admin-ish features either. Just access to things like #feedback, #after-hours, and voice. If a user here misbehaves, the moderators should be able to time them out. Or revoke their role if they're r-slur spamming. This role should otherwise just be user+ in terms of access. No "manage messages" permissions. Yes, this will decrease pinned shitposts. That's a net positive IMO.
  • Better distinguish what the difference between moderator and moderatōr are supposed to be and ensure they are being used consistently.
    = Why do we have standalone moderatōr users, when afaik, they're supposed to be moderator+?
    = Perhaps moderatōr needs a more unique name. It's not quite server admin, but it should be more clear that these are the people moderators should be escalating to, if they're supposed to be moderating.
    = If these users are supposed to be more like server admin stand-ins, they should be given a different role name to designate that, especially if they're not supposed to be handling basic moderation of text/voice channels.
  • We should de-meme some of our role names
    = while it's funny to see "gay" as the role to enable access to dev channels, it's not particularly well-suited to describing what access it grants.
  • All non-mod roles should have "manage messages" revoked.
    = yes, this includes plugin-devs.
    = If a channel has a slowmode set, it's likely there for a reason. Plus, confirmed devs can just migrate to private channels for general chat or more private questions if/when we need to restrict other common channels.
    = We should discourage filling serious-chat channels full of completely useless shitpost/meme pins. While funny, there have been multiple occurances where I've wanted/needed to pin something actually relevant for devs (ex: API 6 notice) and had to first remove shitposts because the given channel was already 50/50 pins.
    = For less-serious channels, we can use something like https://github.com/reiichi001/Pinnacle with some fixups to let people pin things without giving them explicit permission via "Manage Messages". Pinnacle was a ORM experiment for me and could use some adjustments and role locks, but should otherwise be serviceable without needed any major adjustments. (Maybe a migration to slash commands for management, but that should be easy)
    = this should also involve cleaning up dev channel pins at a minimum.
  • we desperately need a separate/dedicated "support staff" style role that isn't moderator.
    = Franz has brought this up quite a bit.
    = Moderators should be focused on moderating text/voice channels as needed. Support should be the go-to users for troubleshooting. Overlap is fine, but the roles and expectations for those roles should be separate.
    = If/when implementing changes, please set FRanz to the support role and remove moderator roles. (I don't mind retaining access to those channels via admin-ish roles, but the expectation to babysit text channels is too much and I am severely burnt out on it. ...and a lot of the time, I'm not even around when the worst of it happens, which only makes this a bigger issue when comments like "how come none of the moderators stopped this when it started to get bad" are used.)
    = Support role does not necessarily need to be given a special color or distinguisher. TBD if anyone can sign up for it or if we want to make this something that only well-known users can obtain.
    + Like any other role, if support misbehaves, they should be actionable by mods. Repeated offenses should result in role removal.

[philpax]

That's fantastic and addresses a lot of the same concerns I had. Do we want to transform this into a DIP, or just have a round of feedback here and action it?

Having a DIP might be useful as a concrete plan of what to do, but your comment's not too far away from that once we lock down some of the more speculative aspects.

[karashiiro]

Proposal: DIP about DIPworthiness

[karashiiro]

Just got around to actually reading this, it looks great, but I'm not sure about this bit:

core-dev ... shouldn't grant "manage messaes" permissions, but maybe these people should be allowed to post into #announcements and #known-issues-faq as it should be reserved for users we trust, both in terms of commits and in terms of behavior. Basically, people we'd trust to make a Dalamud commit that could be merged without too much review.

While the rationale is fine, I don't think there's any reason why core-dev members should be able to post in #announcements. #known-issues-faq might be fine, if we have some example of a case in which that level of access would be useful, but I honestly can't think of anything that can't be run by one of our (very active) moderators, first.

[philpax]

Given that there's quite a few changes described here, I'm going to suggest that Franz turns this into a DIP so that we can finalise the details and officially approve/merge it in. Not super picky on the timeframe but it would be nice to synchronise the role management stuff with #18.