About the "don't mention/PM team members" étiquette

As a user, I find it incredibly valuable to see many team members active on the public forum and also writing topics about feature requests, bugs… It makes them seem like regular users too, which is nice. :hugs:
It also incites users to nudge or directly talk to these team members, which makes the users unintentionally overlook a particular “étiquette”.

This has been bugging me for 6 years now. :grimacing:
The étiquette that says we shouldn’t PM or mention a team member.
A mention is often edited and someone will post “please don’t mention team members,” which sometimes feels rude, and I don’t know how users are supposed to know that. Especially when other users (usually TL3+) can mention the team without being called out.

Instead of applying this out-of-the-blue rule, I think if team members want to restrict who can contact or mention them, they should set up a personal profile setting to only allow certain groups or users to contact them (PM & mentions). For example, trust level 3 minimum + theme and plugin authors + @arkshine, etc…
This would create a more welcoming environment, especially for newcomers.

There’s an official plugin that does a bit of this but lacks granularity, and my topic focuses on the mentioned etiquette on meta. :technologist:

8 Likes

This may not be directly related to the topic, but I want to acknowledge this aspect.

I truly appreciate the team’s activity on the public forum. Their presence, knowledge, and expertise, beyond what Canapin mentioned, make you feel welcomed and supported in your Discourse experience, and you learn a lot as well.

I understand that allowing users to help each other is important, and the team’s active involvement creates a fantastic dynamic. It’s very enjoyable! Thanks to the team for taking the time. :pray:

12 Likes

Like Arkshine and Canapin, I have the same sentiments. I like that the Team are involved with the community as it makes you feel valued.

On other forums I’m on, there is also a ‘rule’ about tagging staff members. But the wording is ‘avoid’ doing to making it seem like in some cases you can? I like it when its black and white with rules/etiquette.

As for Meta, I can’t remember when I last mentioned a team member? I don’t always know who does what role wise, so etiquette aside, I wouldn’t feel confident mentioning team members let alone the right ones.

But my view, I don’t think mentioning staff for attention unless it’s important is good as there are lots of other people here who can provide an answer.

I found a relevant-ish post by Hawk on a similar matter asking about mentions.

3 Likes

Thanks for raising this – I do understand the sentiment, it is just a bit more nuanced than it may appear.

I don’t mind being tagged per se, but only under the circumstances that I mentioned in that post because notification fatigue is a real thing for us. I enjoy spending time on Meta but only when I have time to do it intentionally, so I rely on my notifications for urgent or important things, rather than general support questions which often require me to read back through a long topic to understand the context.

You’ll remember @Canapin that we also use Meta for supporting customers privately, although that isn’t obvious to most Meta users. Turning off the ability to notify me means that I would miss important requests. It’s not feasible to add a new group each time we add a new customer. If there are other workarounds you can think of, I’m willing to give them a go.

11 Likes

This might be a little off-topic, but we also use Discourse to support private customers and we do add a new group for each of them. So now as you’re saying that, is there a better way?

Otherwise I fully understand all the reasons and for me it’s magic that a CEO and other team members are active here like that. On this position you have so many notifications… And this is not an official support, “just” a community. And this community is so fast and Discourse is a profitable open-source. For me it’s a constant inspiration on how an open source project can work.

9 Likes

Sorry, I may have miscommunicated. We also add a group for each customer, but I don’t want to have to keep checking and adding new groups to my “can contact” list.

5 Likes

This is where maybe having a group made for community liaisons is a good idea that could be composed of team members and partners who might be interested in helping out.

I do appreciate that by volume why yous would not want everyone pinging team for everything under the sun. Also understandable in I presume special private categories for paying customers to have priority and even then by volume can be taxing.

Like others have said though either way do really appreciate the team’s interaction even under the current umbrella :beach_umbrella:. As the interaction experience is imho 99.7% highly positive.

Now with Jam’s departure in the roll. Is it or was it okay to @mebtuon the community liaison as long as it is not being done needlessly? Is it still High? Perhaps a post with examples of when it is okay to poke the community liaisons? With example of inappropriate mentions.

I have been in the all in one position with 6000 family active members during a kislxkstarter for a company as a volunteer. So I do appreciate the burnout factor. As the company did have members on the mod team but were not moderator minded. So extremely rare for them to do any moderation if the forum. I was also a community liaison as they recognize the value of having a non company community member being a voice to represent and also guide the community.

Though they do once in awhile send me some products as appreciate. And even bumped me to admin to look after upgrading and such.

2 Likes

Thanks Dan, a community liaison group is a good idea. I’ll raise it with the team.

We are sharing the responsibility for managing Meta across our whole team, with Tobias/the Product team spearheading. We only began in the last couple of weeks so we’re finding our feet.

4 Likes

You’re quite welcome. All things take time. The trick on our end is to have the understanding and patience. Rome may not have been built in a day. But construction has started.

:beers::sunglasses::+1::sparkles:

2 Likes

While I kinda instinctively avoid ‘mentioning’ team members in posts, I’ve done it at least a couple of times in a fit of urgency.

I’d like to take this opportunity to thank the team members I’ve mentioned in the past who’ve kindly responded without a tsk-tsk – but I won’t mention them here. :wink:

5 Likes

After the first nagging about mention a team member I haven’t mention anyone. It was the safest road, and I will keep that strategy.

But… I don’t even need mentions. I write in topics and sometimes I get answers, sometimes I don’t. Mention someone doesn’t change that. I might quote someone instead, because it does same thing. And I don’t even know who I would mention :joy:

My opinion still stays — a house full of coders could tie ability to mentions of team member to higher TL, because they know how not use is. And give a small informative message to (new) members who are trying to do such trick.

Because even I kind of understand these topics, it sounds a bit rude when (new) users are using tools that they have and they are used to use. No-mention is not common policy out there.

3 Likes

This could be automated if Discourse supported “second-order groups” (groups containing groups).

This touches on my deep interest in Discourse as a communication platform and digital garden for formal communities, such as a public school.

Discourse is very well optimized for public and informal communities. However, supporting formal communities requires the ability to implement detailed and granular permissions.

Determining which group is allowed to send PMs to members of another group is one such requirement.

In nearly all areas where global permissions (administrator, moderator, TLs) can be configured, there is a need for local permissions (members of a group).

Currently, supporting formal communities often depends on external tools for proper configuration. Introducing group arithmetic and second-order groups as the foundation of the permission system in Discourse would enable the implementation of these features directly within the platform.

5 Likes