original github issue
Zulip is new to me, and my first experience included having to parse the 't-' prefix in the stream names. . This is the first time coming across 't-', and it left me with a minor sense of 'I'm an outsider here', which I believe is considered an undesirable outcome by the rust community . The biggest contributor to this, in my experience was this:
ctrl-f t-to find explanations is problematic due to 't-$name' clashing with 'rust-$foo'
thus, when searching for the answer to "what is this t- prefix?" in the rust-forge book, results were polluted, obfuscating the section that explains it.
My take on why it caused a "sense of outsider":
Proposed solution: change the 't-' prefix to 'tm-', ideally such that there is little friction when reverting back to 't-' if desired.
It might be worth considering adding a note to the zulip documentation the reasoning for 'tm-' over 't-'.
I've started discussion here as recommended in your reply to the github issue.
I can't say anything to the historical reasons specifically to this issue.
If Zulip jargon is a common thing, then I could see a jargon page not being out of place. Important to note, this would mitigate the effect, as opposed to addressing the root cause directly. I'm of the view that 'tm-' would eliminate the root cause, which is almost always preferable to outcome mitigation.
Weighing up the value of historic preservation, and the value of mitigation/elimination on this issue, I cannot say. Also, don't forget the 'leave it' option. It might turn out that it's an insignificant issue, and doesn't justify action in any case. Don't forget the 'minor' quantifier I included, and there are other experiences which have more impact on how newcomers feel included in general. This issue could serve as a prompt to revisit this question with more generality.
To be clear I was thinking of a general “rust-lang” jargon page, not a Zulip specific one.
hmmm. 't-$label' and 'wg-$label' would be listed under something like 'community jargon'?
If we choose to rename this, why don't we go all the way to "team-" for clarity?
Only twe I can think of not to: 1. the 4-char overhead vs 2-char 'tm', means that the final channel name get truncated an extra 2 chars. 2. subjective aesthetic preferences for one over the other.
on 2. for the sake of preventing bike-shedding and leaving zero ambiguity, I'd suggest just going for 'team' if we go for the rename. If it looks like its worth saving 2 chars, makes for better aesthetics, or (perhaps most significantly), the 0-ambiguity isn't a big deal, we can try 'tm'
on 1. Doesn't look like there would be significant difference based on my current sidebar (using firefox)
I don't feel like character amount makes a huge difference since Zulip has fuzzy search for mentions e.g. Typing
#compiler will bring up
#t-compiler. So clarity would be preferable to being short, since if we want to be short we already have it at one character.
I would personally be mostly fine dropping the prefixes entirely, I don't know that they necessarily buy us much.
However, having said that, I'm not sure if it's worth the change at this point (I think it's going to be rather painful, as it'll mean a divergence in history and links will break etc I expect); in particular because if you don't know what t- stands for it doesn't matter too much.
@simulacrum I would be against removing the prefixes because for certain teams it makes the room ambiguous and more prone to "spam" or offtopic discussion. E.g.
#community is not obvious that it's for the community team and not the community. We've been adding prefixes to some channels in the discord to address this exact issue.
I agree I think it doesn't matter too much. I think if the onboarding for Zulip was a bit better for newcomers it would resolve most of the problem.
Maybe we can have a custom welcome message.
If making changes risks breakages, this could could do. It would probably be worth making a note to look back iinto it sometime down the track (asking some newcomers explicitly, or whatever) to see that it resolves things.
note that "t-lang" etc is consistent with GitHub labels (well, almost, it's T-lang there). this is why I personally immediately understood the prefix. so if we decide this is too jargon-y and change it here, we should consistently change it there as well.
probably this is less of an issue on the GH label side as labels come with a description. so maybe the missing bit here is just streams having descriptions? if t-lang would be described as "channel for the language team" or so, would that help?
streams do have descriptions, but they aren't very discoverable I think in the UI which might lead to this
Oh wow, I didn't even realize there were descriptions. You'd think they'd appear in a tooltip or something...
zulip/zulip#5198: "Expose stream descriptions beyond subscriptions popup"
@RalfJ Personality, I'd love to change them on GitHub as well. :)
Meta-Comment: I started this topic as someone completely uninvolved in the rust project. It's very reassuring seeing the nature of the response. Even knowing how fantastic the Rust community is, I was still prepared to be met with at least a small element of condescension given the nature of this issue. I haven't felt any sense of it. It's amazing. Anyone that has impact on the community culture deserves credit: This sort of experience doesn't come from nowhere. It comes from a long history of many people nudging things in the right direction.
@Ben Thank you as well! And yeah, that's one of the many things I love about the Rust community: there's no vitriol brought forth by questioning current practices, and instead there's a willingness to examine them if they're causing issues, or explain them if they're mysterious but explicable.