Adding `-team` to (almost) all of the tags in Project Discussion

Yes, @joseph — exactly what you describe.

Yeah, I agree. We had this problem on Ask alone with people guessing “Common Issues” when they didn’t have a default. So I added this plug-in, which allows a default to be set. Right now, the default is Ask in English on that site and Project Discussions here.

I agree that Ask should probably be the overall default in a merged site, but it’d be nice to make that customizable per-user. But even as is the default only gets loaded when there wouldn’t be one otherwise, like starting from the front page. If you press “new topic” inside a category, that category is the default. So that’s not so bad.

1 Like

Okay, so — seems like everyone is in general agreement. I’m going to go ahead with this when I get a chance. Each team tag should have an owner, so I’ll contact all of those folks individually.

I’m going to do this sometime in the next two weeks.

Could we consider a prefix instead of a suffix? I like this better because it is easier to discover teams and groups when adding a tag to a post. Essentially, it would easier to filter by SIG or WG by starting the tag with a prefix.

So, all of the email filters are included in this. We should maybe make a new topic about this part specifically? I find this a very disruptive change for the user experience. If we could roll it into the Ask Fedora merge, it would be better to have a massive change at once instead of multiple tiers of changes. If this makes sense?

We can consider anything. :classic_smiley:

But… unless I’m missing something, I think a prefix has several disadvantages:

  1. More typing. You actually can start in the middle, so if the tag were #badges-team, typing b a d still makes it show up, but it’s more natural to start at the beginning, which means a lot of t e a m - to find the right tag.
  2. Kind of confusing because we don’t usually[1] invert like that… “Fedora Design Team”, not “Fedora Team Design”.
  3. Puts Team vs. SIG. vs WG in a primary, emphasized position — when we generally want to de-emphasize that.
  4. And if you are starting at the beginning, you need to remember whether it is #sig-cloud or #team-cloud or #wg-cloud.
  5. And (a new one I just made up): phrasing it as “Team Cloud” seems more like “I’m a fan of cloud computing paradigms!” than “discussion for the team working on Cloud stuff”.

We could do that — we have a staging site as part of the Enterprise plan, so we could copy Discussion to there, then rename the tags, then merge in Ask, then copy everything back to here.

But there is a catch. The reason for this change is because tags on Ask overlap with the tags here — for example, both currently have #server. If we do the above, someone filtering on #server for this site who does not adjust would suddenly[2] get the Ask category posts in the folder they were expecting to be for the team posts, and the #server-wg team posts unfiltered. I’m thinking it would make more sense to let people adjust this first. Does that make sense?

Let me throw another wrinkle in here: Discourse just merged a feature request of mine, FIX: Improve tags in email subjects and add filter headers (#19760) · discourse/discourse@c4ea158 · GitHub — which means that there will now be X-Discourse-Tags: to filter on, and people using procmail or mail clients with sensible filtering options should change to use that whenever it becomes available — probably at the next site update. So we definitely should wait for that at least.

Unfortunately, gmail filtering doesn’t work well with this anyway no matter what we do (see Headers for email notifications so that Gmail users can filter on tags? - feature - Discourse Meta). But that’s kind of a whole 'nuther thing.

  1. with the notable exception of “Team Silverblue” ↩︎

  2. well, depending on their notification settings! ↩︎

  1. Granted, it is a few more characters. However, many times I approach a new topic as my intention to find the right audience for my topic. My desire for a prefix is because this is the typing I am already doing when I come to post something. For example, a Mindshare topic might be relevant to mind-co but I might also want to flag it to a specific team or sub-group too. If I can use a prefix as a filter to find other teams that I might not know about yet, that helps me get my content in front of the right group of people.
  2. A prefix is not the same as the team title. Think of it like hostnames, a “pretty” hostname and a “static” hostname. The pretty hostname (or team name) is how it would be written in a document or spoken aloud. The static hostname is easier for sorting, organizing, and finding similar content. My pitch for a prefix is only about the “static” name, not changing how we refer or write a team name across the project.
  3. Could we only use team- as a prefix then, and not adopt sig- or wg-? I think this is simpler. Maybe this is also in line with what you originally pitched.
  4. So, let’s just have team- as a prefix then. Problem solved? :slightly_smiling_face:
  5. Then best to leave it to the tag homepage and Discourse magic-config post describe what the tag is all about?

This is useful context that I didn’t have. But if I am a newcomer to the community posting about something Fedora Server-related, and I am only typing in the tag field without digging in too much, I would be confused by what -wg or -sig means. (I often find myself having to explain SIG vs WG already to Fedora newcomers.) The difference between server and server-wg is not intuitive as a newcomer.

Additionally, I like the team- prefix better because as an author of a new topic, if I am trying to reach a team/SIG/WG, I must be intentional about it by starting the tag with team-. I think it is more intuitive and it would also avoid people posting general knowledge questions and topics in the wrong place. I feel that if a tag is prefixed by team-, it is more intuitive that this is a group of people doing work.

Sure, I think it is fine to wait for this to work its way into a mainline Discourse release. But as you noted, for Gmail users (as well as other email web clients, even some desktop client filters like Thunderbird), this won’t have an impact.

I’m perplexed by the “filter” concern. There are only a few tags allowed in the Project Discussion category that are not teams. (That is: high-level-bucket tags mindshare, engineering; objectives, which is kind of a odd one honestly; and the handful of support/help tags like idea). What’s the use of having the whole rest of the list of tags prefixed with the same thing?

My understanding is that not every tag would be suffixed with -team either; what is different with a prefix?

Well, the things I said above. It looks weird, doesn’t match how we talk or use the terms, and I don’t understand what benefit it’d have.

I really don’t get that either. To me, #design-team means… the Design Team, very clearly. But #team-design means “the concept of designing things as a team”, or in a more slangy way, “I’m in favor of things being designed rather than just happening”.

That said, the upstream change has landed, and now email notifications have headers like this:

X-Discourse-Tags: engineering mindshare badges-team
X-Discourse-Category: Project Discussion

which can be filtered on,[1]… which means that if you get your notifications that way, you could sort them into different folders. This doesn’t help with distinguishing between notifications on the site, though, and I do think something like workstation could get overwhelming.

On the other hand, @dustymabe said he’d prefer not to have a distinction, and have coreos on both sides.

I don’t want to re-quote too much of the thread, but look up to the top few responses — I felt that what Ben and Joseph said about signal-to-noise ratio was pretty compelling. But, on the other hand (particularly for the Editions and Spins teams!) there’s kind of a neat symmetry to having the same tag used in both places. So, I’m going to put this on hold for a little bit and do two things:

  1. Ask Discourse if we can configure the site so that category mute overrides tag watching. That way, one could subscribe to a tag but mute :category_ask: Ask Fedora if that becomes overwhelming.
  2. Go ahead and rename a few specific tags where I think it makes particular sense. mind-co to #mindshare-committee, join to #join-sig, and design to #design-team, at least.

Then, we can what actually happens with “signal vs. noise”, and split tags if it becomes really necessary.

  1. Except if you’re using Gmail. But we can’t do much to fix Gmail’s filtering! ↩︎

Another advantage of keeping the tags the same across categories is that mis-categorized topics are easier to move — they don’t have to be re-tagged.

One of the observations I have made on Discourse is that these tags are never referred to in plain fonts and without the “#” prefix. Granted that people would still refer to them by reading them out loud, so #team-websites would still be said as “Team Rocket”[1] “Team Websites” - we need to understand that these tags are like uniquely identifiable slugs for a group. They need not particularly have a 1:1 relation with the actual name of the team, SIG or subproject but as long they make it easy for the users to distinguish between the units and discover these groups, we should be fine.

Now that’s out of the way,

Agreed. That’s how most people look up stuff and if a tag is not compact yet representative enough, then it most likely is not a good tag for looking things up.

Yep. As I mentioned, the tags do not need to have a 1:1 matching with the actual name so the prefixes are mostly for representational and indexing purposes only[2]

Please, no. There’s a valid reason why teams, SIGs and workgroups are called so and for the sake of resolving confusion about where the identifier should be placed, let us please not de-emphasize the importance of these names in the first place. Falling in line with what I mentioned before, they definitely need not be a 1:1 match but adding team- prefix would only end up causing confusion to folks when they mention of these tags by speaking them out loud.

AC: "Come find our discussions under the tag of Team Join"
AS: "Wait what? Aren't you called the Fedora Join SIG?"
AC: "Don't worry, we are still called the Fedora Join SIG. It's just the tag for our discussions."
AS: "Yeah, I guess"

I have a suggestion. I do not know if it is possible or if it would end up creating more problems but can we not have a redundant set of tags pointing to the same resource?[3] Say, for instance, we have both #websites (like we did before) and #team-websites-and-apps as well as #websites-and-apps-team for the most recent changes. Now, why are both of the latter ones for the recent changes? The tag with the prefix #team- helps a lot with indexing and grouping groups[4] that are contributor-specific and the one with the suffix -team helps with the manual lookup.

  1. Apologies for the totally ill-placed Pokemon reference ↩︎

  2. It, of course, is a different story to make people believe that ↩︎

  3. Drawing parallels with redirects here ↩︎

  4. Yeah, you read it correctly ↩︎

1 Like

Correct. At least for how we (the Fedora CoreOS group) have been using the forum is for a mix of user support and some discussion about doing things a better way. Though, for dedicated discussion on topics about future direction of the project we’ve been using GitHub issues for that. So at least for us the distinction between #coreos and #coreos-wg would probably be more confusing than useful.

I speak only from my perspective. Other teams might prefer the other structure. Can we have a mixed approach?


Can we? Yes!

Should we? I’m not sure! Might be confusing.

This brings up an interesting question. If a Fedora team does not use Discourse to discuss projects, should they still have a -team tag on Discourse?

On one end, it would be there ready to go if the team changes their mind or if someone specifically wants to discuss contributing in that area and not discuss the output of the team.

On the other hand, if the tag exists but no one is using it or getting alerts on it, is it possible that those posts get missed by the team?

One example that I kind of ran into was with EPEL, where I tagged the epel tag but realized later that it wasn’t used. Let’s say there are lots of folks who use the epel tag in Ask Fedora but I still want to reach the team. In the future I might use #epel-sig alone, without including epel because I don’t want to bother those folks, but then I am also missed by the team I want to talk to even though the existence of the tag could imply that people use it.

Would we be leading folks down dead ends by having team tags that won’t be used by the respective teams?

But I understood that there are owners of tags. See this guide.

That is why there isn’t a ‘l10n’ or ‘localization’ tag, for example. Teams that haven’t reached a consensus (or even discussed at all) about using discussion.fpo for their work/organization don’t have a tag. And I hope it will remain the same in the future.

There are few tags like that that are kind of lonely, some because they existed as categories in the previous site organization. I’m not terribly worried, because I’m optimistic about getting more people here for all of the ones we have so far.

1 Like

For Silverblue and Kinoite we use different issue trackers as well for development discussions so we don’t really need two different tags as everything here is considered as “questions”. CC @tpopela

I agree with what @siosm wrote.

1 Like