How to request a new team Tag (or a Team Workflows subcategory)

Creating New Tags

As explained in Navigating Fedora Discussion — Tags, Categories, and Concepts, tags in :category_project: Project Discussion correspond to Fedora Teams. And, teams in Fedora range all the way from highly formal and structured committees to loosely-affiliated special interest groups — which can effectively be created by simply finding interested people and putting their names on a list somewhere.

The first rule is: tags should fit the structure for the category they’re in. For Project Discussions, that means Fedora Teams.[1] For Announcements, it means a broad category of topics that it might make sense for users to subscribe to or mute separately. For The Watercooler… something enough different from the existing tags to really make sense.

Tags are easy to create and low-overhead, and unlike a mailing list don’t imply infrastructure that needs to remain forever. And, unlike a mailing list, they don’t necessarily split off conversation into a place people need to actively seek out (while still allowing people who aren’t interested to ignore or mute the tag). So, as a second rule, if there’s interest, we should create new team tags here

On the other hand, we do want to have active tags, not just theoretical ones. So, as the final (balancing) rule, we shouldn’t create tags where there’s not at least a couple people definitely interested in real, ongoing conversations on Fedora Discussion. That means both that there needs to be overall Fedora Project interest in the topic, and that the team is interested enough in having conversations here rather than on a mailing list, in :category_chat: Fedora Chat, or some other venue.

In practice: if you want a tag for your team, post about it here, and if there is sufficient interest, we’ll make it. This topic is set to auto-delete replies after a month so it doesn’t get full of administrative clutter; if a particular discussion about tag creation should be preserved, we’ll split it out into its own Site Help topic.

click for the Standard Operating Procedure for Creating Tags for site admins
Note that because some of these steps require administrative access, this needs to be done by a site admin.
  1. Determine that there’s enough interest.
  2. Get a brief description of the tag, and someone to take ownership that description (see below)
  3. Find the tag group that this tag should belong to
  4. Add the tag to the “tags in this group” selector (this will let you create a new, unused tag)
  5. Back in the tag list, click on the new tag and the the :wrench: icon on the tag page
    description
  6. Create a new “about this tag” topic with a short description for the sidebar.
  7. Tag it with the new tag!
  8. Make that topic closed and unlisted, and set it to delete all replies in a week for good measure
  9. Re-assign the ownership of that post to someone from the team (probably the person who requested the tag — follow Call for team Tag owners!
  10. Note the ID of the post; go to the Tag Sidebar Theme Component configuration and add the tag name and post id.
  11. Validate that it all looks right.
  12. Report back in this thread that it’s done.

Creating new Team Workflows subcategories

Discourse categories can be configured with different permissions and defaults. For example, they can require membership to post, they can have their own moderation team, or they can have a specific template for new posts, or they can even be configured as a kanban board. There are lots of possibilities!

The :category_workflows: Team Workflows category is where we realize these possibilities.

The guidelines for creating Team Workflows subcategories are roughly the same those for creating tags: the first rule is that there needs to be a functional reason. The second rule is that we want to allow people to explore, so if there’s interesting ideas, let’s try them. However, again, a final balancing rule: setting up categories does take some work, so please make sure your idea is at least half-baked before proposing we try it.

You probably should start a new thread for something like this, rather than just replying below.

click for the Standard Operating Procedure for Team Workflows Subcategories for site admins
Note that because some of these steps require administrative access, this needs to be done by a site admin.
  1. Determine that there’s enough interest.
  2. Get a description and a header image from the person proposing the idea.
  3. Create the new category as a subcategory of Team Workflows
  4. Set permissions and stuff as appropriate
  5. Add to default categories muted, set for all people retroactively.
  6. Add the header image
  7. Add the description to the description post and set ownership of that post
  8. Define any new tags for the category, if requested.
  9. Pick an (open content) font awesome icon assign in the Category Icons theme component
  10. Any other custom things for the custom category (kind of wide open, by definition!)
  11. Validate that it all looks right.
  12. Report back that it’s done.

Creating new News & Announcements subcategories

We should be careful about this — remember, it’s functional differences that make a category worthwhile, not, actually, categorization. (I didn’t name these things; sorry!) If you have an idea for a new News subcategory that won’t work as a tag, though, we can certainly consider it.

One thing I am looking at is mirroring Fedora announce lists — at least the main announce list, but maybe also devel-announce, test-announce, and epel-announce. I’d prefer to not create a category for each, though, so adding more than one is pending this upstream.

Creating other categories and subcategories

Again, anything is possible, but overall, let’s wait at least a while with this setup to see if we’re really missing anything big. I think it’s generally a case of “less is more”.

If you want to help curate or update an existing tag

See Call for team Tag owners!


  1. And correspondingly, there should be an actual team of people who will use the tag, even if it’s an informal group. Something like #hardware wouldn’t make sense, because there isn’t “Fedora Hardware Team” (and probably won’t be — too broad). ↩︎

1 Like

I would love for there to be a mobile or mobility tag (of some name relating to mobile devices like phones and tablets). I’ll link this room to the mobile sig matrix room and see what they think :slight_smile:

@torbuntu sounds good! I moved your post from the tag owners thread to here, as that’s getting a little bit ahead of things. :classic_smiley:

1 Like

Whoops! Thank you :smiley:

Yeah I should definitely have come here first. I may be overestimating how many folks would actually discuss mobility related projects :thinking:

I think it basically comes down to: is there an active team with a need for async communication, separate from the ARM mailing list (as listed here)?

Some of it is a chicken-and-egg thing, where active conversation about the team will help bring in more people… but you need the people with something to talk about first. :classic_smiley:

Please add a marketing tag under :category_project: Project Discussion . I would own it, and please remember to shutdown the ML and we will point people here.

@x3mboy I discovered that I am the owner of the marketing mail list (I have no idea how I ended up with that role), so I went ahead and attempted to disable it in the same way that the magazine mail list has already been disabled. (Ironically, I’m not the owner of the magazine list, so I cannot update the link there.)

Excellent, thanks so much!

Done!

Thanks!

I would like to request #mentored-project under project discussion.
This tag will be for Outreachy, GSoC and any other mentored project updates / announcements.
Program timelines, project discussions, project proposals, intern updates etc, all will be discussed in this tag :slight_smile:

I think that makes sense; Mentored Projects effectively acts as a team. There’s a docs section and an official selected Mindshare Committee Seat. Creating that now.

1 Like

Hello, I would like to request the creation of a #kubernetes tag under project discussion.

This tag will be used for all posts that are related to the Fedora KubedDev SIG, such as meeting URLs , technical discussions and so on.

@lrossett Sorry for being slow in getting to this. What do you think about #kube-sig as the tag, to help distinguish it from being a place to get general kubernetes-on-Fedora questions?