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

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

For the records, at least while composing a new topic, if I start writing “ba”, both “badges-team” and “team-badges” would be displayed.
Like now, if you write “or”, " coreos" and “mentored-projects” are displayed.
So, I suppose that at least from this point of view, it doesn’t matter if “team” is a suffix or a prefix.

@siosm, @dustymabe, @tpopela — this may be a different (and larger) conversation, but… I’d really like us to move away from using trackers for discussion. I think, in large part, that’s been a way to work around the difficulty of mailing lists, but I’d like to hear other reasons you prefer it.

I don’t want to dictate tools to teams, but I feel like discussion in trackers really increases our project fragmentation — especially when people are using Pagure, Gitlab, Github, and whatever else.

I think it makes perfect sense to talk about specific implementation details in a tracker, and of course to use one for tracking things. But when bigger and more general project development conversation ends up in tickets:

  • It’s nearly invisible to the rest of the project.
  • The rest of project communications may be out of regular visibility to the team.
  • Newcomers have to discover each team’s communication platform separately.
  • People trying to work across teams must learn various different tools.
  • It’s more difficult to have cross-team conversations.
  • It’s harder for us to consistently count contributors.
  • Easy to lose crucial project history when it’s scattered across various sites and tools.

Does that make sense? What would it take to encourage your teams to move to team discussion here? We have quite a lot of flexibility.

I think now that we have the site merged, despite holding off on make the change, it’s quickly becoming clear to me at least that having split tags is going to be the best approach. (See A way to only subscribe to messages from Discusison, not Ask?)


Yeah… I’d be willing to have a chat with you about it.

1 Like

Cool — let’s plan on that discussion. I think we should move ahead on this. Let me know if you really really think we should have that conversation first. :classic_smiley:

It has occurred to me that there was a really good practical reason to do this before the merge — renaming them in place is now going to hit both categories. So, I intend to do the renames and then retag the posts on Ask Fedora. In order to do this, I will temporarily turn off the notifications generated when a post is retagged. People who are subscribed to these tags in Ask Fedora will need to resubscribe. I’ll post something about that to News & Announcements once I’m done.

1 Like

FYI I am also removing the go-lang and haskell tags. I’d love for conversation from those SIGs to happen here, and will re-create if there is interest.

As y’all may have noticed, I am about halfway done with this project. Gonna script something up to make retagging easier for some tags like kinoite and silverblue which are popular in both categories.

This is now complete. Please let me know if I’ve made any mistakes!

(Also: the choice between “SIG” and “Team” is pretty fluid. Please let me know if your group prefers a different label!)

1 Like

From my perspective (Silverblue, Kinoite, CoreOS), this forum is a great place for users to ask questions and help each others. It works much better than the IRC/Matrix discussion channels for complex topics and questions are not lost to time as they might be in the IRC/Matrix channels. In the CoreOS channel, we usually asks users that have complex questions to post here instead of flooding the channel, and then to paste the link in the channel to give it more visibility.

Most development discussions don’t happen here. Each project has its own issue tracker and feature requests and bug reports are tracked in those. It’s mostly not possible to track development / bugs / requests discussions here as there are no tools to do so and it’s not meant for that in general.

Fedora’s “general” development discussions also don’t happen here but in a mailing list (!), which is even more hard to track and interact with that a Git forge issue tracker.

The priority from my perspective is to move away from tracking Fedora changes and development discussions in mailing lists because those are the most hard to track medium, not the issue trackers.


We now have the following tags:


Only the second set has a description / pinned post with the topic on the right with the links to the tracker, etc. so that users can find where to report bugs.

Like we said in Adding `-team` to (almost) all of the tags in Project Discussion - #21 by dustymabe, this approach does not work well for us (CoreOS, Silverblue, Kinoite) as we don’t split development/users discussions (and I expanded on development discussions above). We now have two tags to follow and there is no meaningful distinction between those.

The naming is also inconsistent which is not great.

I would prefer we merge all the teams tags into the regular ones.

1 Like

Like I said to Dusty, let’s talk. But just landed in Spain after the overnight from Boston, so… later :slight_smile:

Indeed. Maybe our CoreOS weekly community meeting would be a good space to discuss this further? I sent you a calendar invite for next Wednesday.

Enjoy your time AFK @mattdm!


I would prefer “sig” (Special Interest Group) prefix or suffix rather than “team”. The team is more intuitive for me. But the “team” makes me imagine as a strongly connected group. I don’t think this is a reality. I would prefer a relaxed group where people can join and leave casually. And as we are using the terminology “sig” heavily in the project, it is consistent.