MSC3755: Member pronouns

[Gnuxie]

Rendered

This is a draft for the moment and is intended to start a discussion.

[anoadragon453]

nice to see

[anoadragon453]

I'm curious how this list of potential variations was determined. Are there more that could be useful? Are all of them necessary?

Many platforms only specify a single text field for pronouns, are there use-cases for all of these fields?

(Note that I don't want to trend towards a list of allowed pronouns, so the flexibility is welcome. Though I wonder if we're going too far.)

[Gnuxie]

The list is inspired by https://pronoun.is/ and also searching up what they are to double check. I have made it so only subject and object pronouns are required.

only specify a single text field for pronouns

I believe the single text field is problematic, especially with neopronouns as it can be hard for someone who is new to a set of neopronouns to derive the others from just the subject & object pronouns, and I believe that can cause them to not be used at all. Specifying each like this means that clients and bots can also use the pronouns when referring to other users.

[deepbluev7]

Can you link pronouns.is and add that reasoning to the MSC?

[anoadragon453]

Sometimes people specify "any" pronouns. How would that fit into this scheme?

[Gnuxie]

Good question, I'm not sure yet, any ideas?

[ShadowJonathan]

This'd probably break some parsing methods, but what about swapping out the pronoun description object for an "any" string in this case?

Alternatively, i'd recommend having m.pronouns.{LANG}.any: true be able to be a thing.

[ru-ka]

it's any/all

[AndrewRyanChama]

Does this open the door to allowing other various profile bits? I want to see user bios happen

[ShadowJonathan]

Regarding language-specific pronouns, I have a few suggestions;

• Swap out m.pronouns.{LANG} for m.pronouns: {"LANG": ...}, for better extensibility
• Standardize on language codes, such as ISO 639-1

[uhoreg]

The first point, I'm neutral about, but I agree with the second point. The two-character ISO 639-1 codes are fairly well-known, and would avoid the confusion of whether we should be using, say, m.pronouns.french, or m.pronouns.français in the future.

[ShadowJonathan]

@Gnuxie i've seen you applied the second suggestion, but i think i'll retract my first suggestion on the basis that each language really has its own language structure, and so "data"-fying it via m.pronouns is not really helping, potentially.

If you agree with that, i'd consider this thread resolved ^^

[Gnuxie]

Yeah, that this totally makes sense for the current proposal in that other languages might want to have a different schema.

[ShadowJonathan]

I personally think that the data structures defined in this proposal can be additive, and could be "imported" to the profile room MSC when that progresses or passes.

[ShadowJonathan]

Please keep in mind that these are specific to english, and may not apply in other languages the same.

At the very least, make note of this that this data structure shouldn't be copied blindly to other languages.

[MTRNord]

Hm, this brings the interesting issue though that this would lead to localized data structures. Making it harder to parse as well. It would be good to have some of them as required to not end up in localized keys. Or, if not localized, weird mapping issues across languages.

I do see that issue as well, but having it language specific comes with making it way harder to parse as you can't know all keys upfront, or it might lead to conflicting key usage.

[deepbluev7]

I wonder, how should a client expose those to users? an arbitrary list of contents would seem to need a language specific implementation for all the pronouns and in theory a user could have reasonably like 3 different language pronouns in a room? An MSC shouldn't really specify how something should look like in a client, but I have a bit of difficulty imagining how it could look like.

[ShadowJonathan]

The alternative is that a pronoun structure would be defined for every language, but that would get bloated quickly.

I wonder if it could be offloaded somehow, but regardless, I think that while prioritising English is okay-ish, thinking that every language functions like English is not.

[Gnuxie]

So I had an idea about how you might be able to get some genericity from this, though I think this is a bit of a lost cause and I'll explain why.

{
  "m.pronouns":{
    "m.pronouns.en":[
      {
        "summary":"They/Them please.",
        "subject":{
          "pronoun":"they",
          "example":"They were eating."
        },
        "object":{
          "pronoun":"them",
          "example":"Why don't you talk to them?"
        },
        "possessive":{
          "pronoun":"theirs",
          "example":"The wok is theirs."
        },
        "possessive-determiner":{
          "pronoun":"their",
          "example":"Why don't you ask if you can try some their food?"
        },
        "reflexive":{
          "pronoun":"themselves",
          "example":"Just let them be themselves."
        },
        "singular":{
          "pronoun":"themself",
          "example":"They like to cook by themself."
        }
      }
    ]
  }
}

So if you require every key on the object m.pronouns to have a corresponding value that is an array of objects (that i guess are pronoun sets) that have to provide a summary. Every other key in the pronoun set has to describe a single pronoun with an object that requires pronoun and example. So you have some genericity and extensibility here (it is still likely a total pain for a client UX though). The issue comes when you have a language where pronouns change the declinations of adjectives and other nouns. These rules in other languages (such a Czech) can be extremely complicated and can take entire pages/tables to describe. It is something like a masters/PhD thesis on its own to work out some kind of language agnostic way to represent things like this and that probably goes without saying.

So I wonder if instead there should just be free text description "objects" in the m.pronouns.en array. Something that allows for a summary (like "she/her" or "any") and a description (with the added multiline context for how to use each individual pronoun in the set). It might be tempting to argue that this should be a feature of a bio, and maybe it could be. However, I would argue that users should not be forced to push pronoun information into a generic biography field where the pronouns would end up out of place and unable to be specifically highlighted by clients when appropriate.

[ShadowJonathan]

Hmmm, i think that trying to be correct here is kinda harming the usability of this MSC so far.

One suggestion I have is to look at how sites like pronouns.page is doing it, whom define a freeform pronouns field for now, though with some guidelines/hints;

https://en.pronouns.page/pronouns

---

In general, I think this MSC is edging close to scope creep, the biggest benefit for today's federation I see is having a field to write down pronouns, if this is just defined as a string field ("m.pronouns.en": "they/them") for now, it'll be much more flexible to individual needs.

One thing such an arrangement will highlight (more) is that it could become a potential vector for abuse, or for LGBTQ-general harassment with people putting "joke" values in there conforming to general X/Y structures.

[Gnuxie]

Spilled over into chat: https://matrix.to/#/!NasysSDfxKxZBzJJoE:matrix.org/$lFSXQEpMZbIQGh5pxXfsLVfr-gy6VUTyupxmWmc6ZGc?via=matrix.org&via=libera.chat&via=element.io

To summarise, it would be nice to try a simpler free text MSC and positioning the MSC as a thing to land while we figure out extensible profiles is probably best for speed purposes, though if it can wait a while longer then it could be worth blocking on extensible profiles.

[ShadowJonathan]

Neopronouns are something that's entirely novel to the LGBTQ+ community as of yet, a small note explaining what neopronouns are would probably help here.

[Gnuxie]

OK having my doubts now. Free text field is something that's going to be needed anyway. Breaking down pronouns in a smarter way is interesting but a bigger problem than what we can tackle here, though it's probably wise to at least keep the door open.

[Mikaela]

Are other languages an issue for another MSC or is there a plan to extend this? I can think of at least Swedish, Spanish, Russian, French, Esperanto as having gendered pronouns, some have accepted neutral ones, and many other languages likely exist too with multiple pronoun choices.

[Mikaela]

There is also weird case of Finnish where there is only singular "hän" pronoun, but in spoken language everyone is "se" (it) anyway and I wonder if that being fine should be separately communicable.

[Gnuxie]

This is a good point. I explain a little it about how we could make this more generic and extensible here #3755 (comment) but I think we're better off moving back to some simpler summary/description fields that can accommodate for other languages (and special cases) better. I'm going to check out some of the links others have posted since before I start that though.

[Mikaela]

and if multiple pronouns are fine (or if the person isn't sure what they are using at a given time), I guess this can be extended with

,
{...contenthere}

?

[dkasak]

While I welcome this effort, I'm strongly against fattening the m.room.member event further. I think even including the avatar URL and display name in something as security crucial as m.room.member was ultimately a mistake.

The fact that those are bundled together leads to frequent confusion and implementation mistakes, because you now need to handle things like repeated membership: "join" events just because the user is changing their display name.

Including more fields in it would just serve to increase this churn. And if we could do it for preferred pronouns, why not add even more stuff to it? There are already comments on the MSC expressing interest in adding other info there too.

I would much prefer we make extensible profiles sooner rather than muddying up the membership event waters further.

[Gnuxie]

I do agree, especially with

I would much prefer we make extensible profiles sooner rather than muddying up the membership event waters further.

unfortunately there doesn't seem to be much confidence about how this will happen. So as discussed in #3755 (comment) I am going to continue simplifying this MSC as a thing to land while extensible profiles are worked upon. I do not mind the proposal being blocked or opposed if extensible profiles does become unblocked.

[FSG-Cat]

As far as Cat is concerned its not that big of a concern to expand m.room.member with this proposal for pronouns. They are a feature that is very easy to understand why it has value to a wide range of groups and well once we get Extensible profiles we could in a future room version move to make the membership event be exclusively your membership state not your avatar and display name plus pronouns.

Clients that dont care about this MSC dont need to parse the data and should just carry on with their lives as if nothing changed as far as i am aware.

Due to that we already have this complexity i fail to see why we shouldnt utilise it. Another MSC is free to try to simplify matters by doing the proposed stripping down of the membership event that i propose earlier in this comment.

The bigger concern is putting in other things that are not as justifiable for inclusion that are more fitted to Extensible profiles. There is a whole laundry list of things i would love to see today but i know all of those are more suited for extensible profiles because trying to do them via m.room.member would not be the right choice. *

To end i would like to say that Extensible profiles making this MSC not needed is ofc the optimal solution but i envision this MSC as a bandaid fix and not as the end all be all fix because that is closer to what Extensible profiles will provide us.

[dkasak]

Putting this in m.room.member is an anti-pattern. Thinking more about it, why would this even need to be inside m.room.member? As I said, that's exactly the mistake that was done with avatars and display names.

Instead, let's just make this a separate m.profile.pronouns state event with a state_key pointing to the user. Forbid sending m.profile.* events with a state_key referring to users other than your own. This gives us per-room profiles.

Once profiles-as-rooms become a thing, we'll send exactly the same events into them, but there they will refer to a global public profile instead of a per-room one.

This also gives us a way to eventually deprecate avatar_url and displayname in m.room.member and move them to their own state events.

[0x1a8510f2]

Given the numerous potential issues and cleaner alternative solutions, I don't think this is viable. Users both in Matrix and many other platforms have started using nicknames to display this and other information which means that the need for this isn't too urgent to wait for a cleaner solution like the profiles MSC.

While one might argue that this information is necessary to correctly address a user, this argument could be made for languages (needed to communicate with the user in their preferred language), timezones (needed to communicate with the user at reasonable times), titles (also needed to correctly address the user) and probably many others. And, as usual, there's already an MSC for that; this being extensible profiles. There's no reason for this specific metadata to be given a special place.

There's also no avoiding the fact that this change has potential to cause controversy politically, which is probably something to avoid in a protocol's specification.

To clarify, I am strongly opposed to this MSC specifically and believe it should come under MSC1769.

[ShadowJonathan]

Users both in Matrix and many other platforms have started using nicknames to display this and other information which means that the need for this isn't too urgent to wait for a cleaner solution like the profiles MSC.

I'd argue that is a strong indicator that a clean solution should be needed, if everyone needs to dump that information into their nicknames, instead of a bio or the likes.

[MTRNord]

While one might argue that this information is necessary to correctly address a user, this argument could be made for languages (needed to communicate with the user in their preferred language), timezones (needed to communicate with the user at reasonable times), titles (also needed to correctly address the user) and probably many others.

Tbh I think that is a reason why people want extensible profiles all the time. This MSC is basically a subset from it in a way. However, while I still want ext profiles, I do think this change is necessary. Pronouns are part of every day life by now. And honestly it is a major social offense misusing it. While choosing a wrong timezone is bad, it is not an offense.

I strongly believe you can weigh pronouns and things like titles or timezones the same way as pronouns. They are not even close to being equal.

Also, additionally languages are a non issue as people tend to just use it when writing. It usually solves itself with normal social interaction. While pronouns can't do that because you need them before you can start interacting with a person.

[no-defun-allowed]

There's also no avoiding the fact that this change has potential to cause controversy politically, which is probably something to avoid in a protocol's specification.

How?

[0x1a8510f2]

@no-defun-allowed Please refer to all the minimised and deleted comments, variety in votes and the various arguments going on in threads.

[no-defun-allowed]

@no-defun-allowed Please refer to all the minimised and deleted comments, variety in votes and the various arguments going on in threads.

That doesn't explain anything.

Pretty obvious. No need to play the hatchling.

It's pretty not obvious, hence me asking.

[0x1a8510f2]

@no-defun-allowed

Please refer to: https://dictionary.cambridge.org/dictionary/english/controversial

[read in slightly sarcastic tone] You'll notice that what is currently occuring in relation to MSC appears to closely resemble the situation described in the dictionary above. The theme of the discussion is a political issue, hence "political controversy".

In any case, as I believe I've made my point and you are making no points of your own, I'll take any further replies to be trolling.

[no-defun-allowed]

The theme of the discussion is a political issue, hence "political controversy".

Sure, it's controversial, but I don't see the "political" part at all. And, honestly, I also don't see why I, or the Matrix developers, should take opinions of people whom call proponents of ideas they don't like "lunatics" or etc too seriously.

[0x1a8510f2]

Fine, I'll bite one last time, since you've made a point

Sure, it's controversial, but I don't see the "political" part at all.

If you were to take a guess where on the political compass the line separating those "for" and "against" this idea (not this MSC) is, you'd answer your own question. In any case, the important part of my point was "controversy" not "political".

And, honestly, I also don't see why I, or the Matrix developers, should take opinions of people [...]

Please refer to: https://spec.matrix.org/v1.2/proposals/

Specifically:

• "The proposal process involves some technical writing, having it reviewed by everyone"
• "Proposals must act to the greater benefit of the entire Matrix ecosystem, rather than benefiting or privileging any single player or subset of players"
• "Members of the Core Team pledge to act as a neutral custodian for Matrix on behalf of the whole ecosystem."

So I guess there's no reason other than integrity. They are free to ignore anyone who disagrees with spec changes they want to implement, but then they're undermining the credibility of Matrix. No other reason really.

[...] whom call proponents of ideas they don't like "lunatics" or etc too seriously.

Not my words so I see no relevance of this to your argument.

[fskaeh]

This is crazy and serves no purpose whatsoever. As others have mentioned above, you could very easily achieve this without needing such a constrained and specific solution, either with a freeform bio, or possibly adding freeform key/value pairs, this way you could easily do:

Pronouns: he/him
Religion: buddhist
Political leaning: Right
etc.

It's not like Matrix will do anything with that (meta)data anyway, it's only meant for other users to see, and nobody wants to spend an hour learning a complicated chart for each user's pronouns in every language and possible situation.

[dkasak]

I'd like to point out for the folks commenting that Matrix is inherently designed to be an extensible protocol. You don't need anyone's permission to come up with a new event type and you also cannot prevent others from sending arbitrary events.

Thus if someone wants to use a new event type, be it one for specifying pronouns or something else entirely, they'll be able to do it and there's no point in fighting it. This will especially be true once we have a true extensible profile mechanism. At that point, the only purpose of an MSC such as this one will be to inform others of the event shape they can expect if they want to support it in their client.

[FaustAlexander]

Thus if someone wants to use a new event type, be it one for specifying pronouns or something else entirely, they'll be able to do it and there's no point in fighting it.

But will it come by default? Because if so it'll be another thing to configure. I also think the bio idea is pretty good.

[RanceJustice]

Others who are more familiar with some of the concerns have already expounded on potential issues here, but I have to ask if adding (maintaining, updating, dealing with specificity of languages, avoiding adding security vulnerabilities etc) a whole new pronouns feature to the Matrix spec isn't the best path forward.

Rather, could we focus on updating other parts the Matrix spec and server implementation (Synapse, but especially Dendrite if I recall) to extend additional functionality? Allowing users to have per-server nicknames (a feature that will be highly in demand now that Discord has implemented it) and profiles/bios (and perhaps more granular permissions on lines within a profile if desired, - able to flag fields as either global or server specific, and if content is to be included in a Directory at all etc)?

This would give users the ability to customize their identities, nicknames, and profiles/bios as they wish in a way that could include all sorts of data - including their custom preference for pronouns - while also ensuring privacy, maintaining divisions between identities / community content visibility, and without negatively affecting the security of the protocol or server. If there's something here I am missing please let me know, but from my (admittedly limited) understanding of how Matrix is built this seems a better direction to go, will accomplish the same effective ends for those who desire them, confers additional benefits on the userbase as a whole (ie there are reasons besides pronouns that users may want per-server nicknames/profiles etc ) , and furthers Matrix development

[FSG-Cat]

Rather, could we focus on updating other parts the Matrix spec and server implementation (Synapse, but especially Dendrite if I recall) to extend additional functionality? Allowing users to have per-server nicknames (a feature that will be highly in demand now that Discord has implemented it) and profiles/bios (and perhaps more granular permissions on lines within a profile if desired, - able to flag fields as either global or server specific, and if content is to be included in a Directory at all etc)?

Per room nicknames and Avatars have been supported for a very long time and i am not even sure if it wasnt supported all the way back in room version 1 where avatar and nickname was added.

[MTRNord]

Rather, could we focus on updating other parts the Matrix spec and server implementation (Synapse, but especially Dendrite if I recall) to extend additional functionality? Allowing users to have per-server nicknames (a feature that will be highly in demand now that Discord has implemented it) and profiles/bios (and perhaps more granular permissions on lines within a profile if desired, - able to flag fields as either global or server specific, and if content is to be included in a Directory at all etc)?

Per room nicknames and Avatars have been supported for a very long time and i am not even sure if it wasnt supported all the way back in room version 1 where avatar and nickname was added.

It exists since at least late 2016 as far as I am aware. Clients correctly implementing it also displayed that since then. Setting it was only recently (last 2 or so years) getting more streamlined afaik.

[RanceJustice]

I'm aware of those differences between rooms, but not sync'd up alongside custom bios and able to act independently / be conveyed properly between servers? At least, last I checked more in depth (besides my own direct usage) this wasn't possible to have server independent bios and all these things in alignment as it were, depending on user specific flags.

[msglm]

While I understand that some people are being hostile due to the proposal of these changes, I do think that, on some level, there are good points from those against this for political reasons and that should be heard out.

Matrix shouldn't adopt this proposal as it would be implicitly approving of a certain social and cultural worldview that some people using Matrix or developing on Matrix may not share. There are those still apprehensive to these cultural changes, some for more sophisticated reasons than others, that would not appreciate a feature being added that's enabling the normalization of individual defined pronouns. While you may see this as barbaric, transphobic, or something similar, there are some who justify this through religious faiths they have grown up with all their lives, cultural norms they've always lived in, or some other intellectual belief and have yet to have been convinced to your side. Not everyone sees the same way, so other people will take a proposal like this with some level of hostility, especially given the volatility of contemporary Western politics.

If something like this was implemented into both the major clients and the server side functionality, I don't know if I could be respectful to other cultures while suggesting a Matrix-based system to others. I have Roman Catholic, South American friends who live in places where concepts like this are foreign and objectionable due to their cultures. I know a Syrian refugee who lives in America who yearns for his homeland due to disdain for cultural phenomenon like this. I know these people would not take kindly to a feature like this being implemented in a chatting application and they may be apprehensive to use it because of that. I rather not scare off otherwise good people from using Matrix due to Matrix implicitly supporting one side or the other on a hot-button cultural issue.

If a feature like this is deemed to be a necessary enhancement from a technical view point, a politically presumptuous proposal like this one is not the ideal solution. A form of bio allowing for any input or a key/value system for whatever the user wants would be more ideal, less politically charged, and of more utility to all Matrix users.

[nocturn9x]

While I understand that some people are being hostile due to the proposal of these changes, I do think that, on some level, there are good points from those against this for political reasons and that should be heard out.

Matrix shouldn't adopt this proposal as it would be implicitly approving of a certain social and cultural worldview that some people using Matrix or developing on Matrix may not share. There are those still apprehensive to these cultural changes, some for more sophisticated reasons than others, that would not appreciate a feature being added that's enabling the normalization of individual defined pronouns. While you may see this as barbaric, transphobic, or something similar, there are some who justify this through religious faiths they have grown up with all their lives, cultural norms they've always lived in, or some other intellectual belief and have yet to have been convinced to your side. Not everyone sees the same way, so other people will take a proposal like this with some level of hostility, especially given the volatility of contemporary Western politics.

If something like this was implemented into both the major clients and the server side functionality, I don't know if I could be respectful to other cultures while suggesting a Matrix-based system to others. I have Roman Catholic, South American friends who live in places where concepts like this are foreign and objectionable due to their cultures. I know a Syrian refugee who lives in America who yearns for his homeland due to disdain for cultural phenomenon like this. I know these people would not take kindly to a feature like this being implemented in a chatting application and they may be apprehensive to use it because of that. I rather not scare off otherwise good people from using Matrix due to Matrix implicitly supporting one side or the other on a hot-button cultural issue.

If a feature like this is deemed to be a necessary enhancement from a technical view point, a politically presumptuous proposal like this one is not the ideal solution. A form of bio allowing for any input or a key/value system for whatever the user wants would be more ideal, less politically charged, and of more utility to all Matrix users.

Couldn't have said it better myself (in fact I didn't, because I'm tired of the politicization of literally every aspect of my life). Plus, a hot take for anyone trying to convince someone else they're right: calling them names such as transphobic (especially given how malleable and overused they are) will not change their mind nor bring any good to your cause, especially if the matter is political. (For anyone trying to reply to this with "Well, you called us leftists!": I wasn't trying to convince anyone of anything, I just stated my defeated point of view about the topic)

[turt2live]

For absolute clarity: suggestions like my own are to find a neutral way of representing the information. We're not trying to pick political sides, we're trying to find a technical solution for how to represent this information.

Offtopic, abusive, or harassing comments will continue to be removed or minimized. Do not engage with them.

[austinhuang0131]

Suggested change

	and waiting indefintley for them, this solution relies
	and waiting indefinitely for them, this solution relies

[austinhuang0131]

Changing avatar and display name also overrides any values that does not match the default value. Does this proposal address that? One way would be to send the default values in a separate event (preferably among other profile stuff in MSC1769, in fact I would prefer pronouns to be addressed in a comprehensive proposal among other profile properties than making a new one) while using this event to override them...?

For example, my default pronouns are we/us but in a specific room I may need to change it to he/him. Because my default pronouns will be public anyway (given that it is, supposedly, linked to a user), I might as well send the default pronouns we/us as something like m.profile.pronouns when I join a room, while I can override it to a room-specific one he/him with something like m.room.pronouns, such that the client displays the room one first and then the profile one in the context of a room, but the profile one in the context of a DM

[rczajka]

Two issues with this proposal:

1. A user will often described in the UI in language they do not know, in statements like “X joined” or “X set their display name to
   Y”. In gendered languages, these are currently localized as unwieldy forms such as “X dołączył(-a)" or “X zmienił(-a) nazwę na Y”. Providing specific functionality for users to indicate their gender, but in a way which doesn't even allow for gendering them, seems like a broken functionality. And expecting users to set up gendering information in all languages independently is obviously unreasonable.

2. Pronouns are English-specific way of indicating sex, as it doesn't use grammatical gender. Other languages use articles (el/la) or inflection (poszedłem/poszłam). The construction of m.pronouns.{language} wrongly assumes that pronouns will be the common denominator between languages.

A better proposal would be to allow the user to (optionally) indicate their sex (m.profile.sex?), irrespective of gender rules of any specific language — and then (also optionally) to indicate special preferences relevant to specific languages, like pronouns (m.language-specific.en: {"pronouns": …}?).

This would then allow to use this information for gendering in various languages the way Mozilla's fluent does.

[anoadragon453]

Can I kindly ask that people open a new pull request comment on the doc (via the Files Changed tab) when they are starting a new thread. It allows for threads to be visually collapsed when that discussion concludes.

[ghost]

I'm sorry, but this is a horribly anglocentric PR. Just keep it as it is. The concept you're trying to implement doesn't even exist in most languages.
+1 to fskaeh: Nobody was asking for this. You know what you're doing.
+1 to rczajka: It's not feasible for non-English languages.
What I suggest to you is that you extend the protocol and the client for your private, presumably English speaking community.

[viasux]

This is nice and all, but will I be able to also add information about my fursona and every aspect of my life in profiles? Pleroma already lets me do this with profile metadata and I feel we need to go further to accommodate everyone.

Yeah,

[prounoun field]
[custom text:] [other custom text]
(add more custom text fields button)
[user description]

([] being text fields) just like on mastodon, pleroma, and misskey would be wonderful in matrix.

[ru-ka]

As a former member of the LGBT community, I find this limiting to only be able to specify pronouns without the option to include my sexual orientation, which is an important part of my identity. This becomes particularly relevant when using platforms like Matrix for dating purposes.

[turt2live]

This MSC has already received a ton of feedback, much of it going in circles or duplicated. We're locking this until the SCT can handle the MSC more completely.