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:
- 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
Ask Fedora if that becomes overwhelming. - 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.
-
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 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?
3 Likes
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
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?)
2 Likes
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. 
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