Yes.
I would consider having an “unknown” (or no-sig, or other) label in that group. This way we ensure that user has not just ignored the need for a label. But if they tried to find it, but failed, they still can start a conversation.
Or maybe it is too much. If a person didn’t find the right SIG to talk to, they should go to Generic/Everything category instead and post there.
Okay, so, here’s my next steps:
This sounds like a good way to build consensus. 
A poll is a good next step to move this from discussion to building consensus on what works best for the community.
I’m still hesitant on using broad categories with specific tags approach because it makes the site harder for me to use. Last month, I reconfigured my notifications around how we use categories so I could better follow the topics I care most about, which is why I have strong feelings about this.
Yeah, if we went with this, people who have done that would need to reorganize notification settings around tags instead of categories, which can be done in your preferences under Notifications / Tags. I don’t think it should be functionally much different — just a switch in perspective. But if we go this route, we should definitely document it, because I think it is less obvious for folks coming from either mailing lists or traditional web forums.
And probably tack on wider communications too like announce list emails, CommBlog posts, etc. This would be a disruptive change for current users. We would want to catch the attention of folks who may not log into the web interface all the time or are not subscribed to categories like Site Feedback to follow these kinds of conversations.
Here’s something to consider — if we go with @bookwar’s suggestion for making tag use for organization, new threads started by email won’t be tagged and we’ll need moderators to pay attention and tag them. (See upstream feature discussion.)
Note that this only applies to first posts. We haven’t be using that extensively I don’t think, but we do have some Fedocal reminders coming in that way, and it’d be kind of annoying to require manual intervention for each one.
The start-threads-by-mail feature is a little scary because it could be used for impersonation, too. Hasn’t been a problem so far but it’s a potential hole. It might be better off to ask people to come it the site to start threads… even though it’d be an adjustment.
And… for fedocal, we could ask Websites and Apps team to teach it to post directly via the API instead of relying on mail.
Worth noting that CentOS folks also just requested a category on the site too, which contributes to this discussion:
Maybe @t0xic0der could comment here, but I would suggest completing this work in Fedocal first as a prerequisite before switching to a tag-driven system. I am not clear on the capacity of the W&A team for delivering on this change in this release cycle. I do know there is already a heavy load on the plate already before we could be more agile in working on new requests for apps like Fedocal, since we have not spent much time or focus there yet. We’ve been working a lot on Møte and the static websites, like the new CI system that @darknao added recently.
I think we should avoid making hard blockers. In practice, there are just two weekly meetings using this functionality currently. At that level, we can either just tag those posts manually when they come in, or we could turn off the fedocal email and experiment with using the Discourse Calendar plugin.
Okay @bookwar, thinking about your idea for a tag-primary layout, and returning the serve with several possible suggestions:
Welcome
- Announcements
- Community Blog
- Introductions
- Site Feedback
Mindshare
* tags: join-sig, docs-team, marketing-team...
Engineering
* tags: cloud-sig, workstation-wg, spins-sig, coreos-wg, qa-team, infra-team,
devel, ...
Council
Workflows
- Fedora Magazine Article Proposals
Projects in Copr
Basic getting-started stuff goes in the top-level “Welcome” category.
Community Blog has to be a category/subcategory because while the WordPress plugin allows authors to add tags, it doesn’t have a way to force a given one. So in the interest of having these organized, a separate category makes sense.
We’d make a “tag group” for Mindshare and one for Engineering, and we could require each topic to have a corresponding tag.
Not sure where to put Council in this structure.
Project
- Announcements
- Community Blog
- Newbie Safe Zone
* tags (all in the top-level category): council,
various mindshare sigs
Development
* tags: cloud-sig, workstation-wg, spins-sig, coreos-wg, qa-team,
infra-team, epel-sig
- Site Feedback (or maybe this is a tag too!)
Workflows
- Fedora Magazine Article Proposals
Projects in Copr
Here, I’m not even sure if we’d need mandatory tagging, although I’m leaning towards “yes” just for the sanity of people trying to keep up with a specific area.
Workflows would be muted by default.
What’s Newbie Safe Zone? Idea I just made up when thinking about the concept of “categories are spaces with different needs”. It might be intimidating for new Fedorans to post in the “big” categories; this would give a place where they could. Posts in this category could be hidden from non-logged-in users and search engines, and we could even set them to auto-delete. That way, new folks could dip their toes in without being in the deep right away. (The name probably needs some workshopping!)
Announcements
- Community Blog
Discussion <- BASICALLY EVERYTHING
Site Feedback
Workflows
- Fedora Magazine Article Proposals
- Projects in Copr
With this model, we’d probably change the default view from Categories to Latest, emphasizing the content over the organization.
Same note as above on mandatory tags.
Again, Workflows would be muted by default. And maybe we move the Copr category under it?
FWIW, I like option C. But I use the “latest” view anyway. It might also make sense to put the magazine’s Discourse Calendar under Announcements if we do that (maybe make it a general area for calendars and schedules for all the projects and encourage the different teams to update them with what they are working on and planing).
This is my favorite proposal and would allow me to still follow the topics I care about, without having to do a lot of manual work to filter things that are more or less relevant for me.
I think as its own category alongside Mindshare and Engineering, as you put it, works fine. It fits into how the org chart works:
Wouldn’t it make more sense to sync this up with the Join SIG instead of spinning off with something new? I like the idea but I think it fits nicely into the work the Join SIG does. Maybe @ankursinha or @alciregi could weigh in with thoughts here.
Eep. This approach would push me off of discussion.fp.o. I feel like this approach sacrifices the benefits of Discourse in favor of a mailing list-style approach by default. Couldn’t someone turn on Discourse’s mailing list mode if this how they wanted to interact with the site? You could use email filters at the email account level with mailing list mode to customize this as one would see fit.
Okay, so… I think this is actually a case of “a tag-based approach on Discourse requires thinking slightly differently”. The tags are actually stronger structures than they might appear; it isn’t just like a twitter label. You can actually treat them like a subcategory … see for example
http://discussion.fedoraproject.org/tag/commblog
With this approach, the tag defines the “specific area” you might want to keep up with. Just like with a category, you can watch, track, or mute posts in a tag (which controls your email notifications if you have that set up). And teams can link directly to “their” tag.
Unlike categories, though, you can cross-post easily — tag something both #cloud and #server, for example. Or #development and #java.
In this model, categories are functional distictions rather than subject-matter ones. What does that mean? That really comes down to discourse features which can apply on a per-category basis, and those include:
Oh! And actually there’s another obvious one. We could have a category for meeting announcements and logs. Waving aside for a second how they get tagged properly (I have ideas), that category could allow incoming messages from Fedocal. If you want to review meeting minutes, like meetingminutes - Fedora Mailing-Lists, you could go there — but also, when you looked in the #council tag, you’d see both regular discussion and the meetings and any related announcements.
I think we’d want to do a significant revamp of existing tags, so we have a formal structure as e.g. used on Discourse Meta.
CPE has a test instance of Discourse installed for helping with the webhook integration and group SSO stuff. When they’re done, I might ask to take over that and make a demo site so you can see some of this in practice.
What @mattdm mentioned is do-able but not so in this release cycle and even probably the next one for that matter with the small count of active contributors that we have right now. I like to think that there’s a lot of foundational work that needs to be done on Fedocal on deciding the end goal, plausible changes and checkpoints before it comes down to the team to actually write some code to make it happen.
A quick run-through on our status, now that we’re at it. While the Mote rewrite is making its way to the final straight, we unplugged the fedmsg consumer part from it because it was not front-ported to Fedora Messaging. I would need some help from those who are experienced with Fedora Messaging to make it happen. @darknao’s a wizard so you can pretty much imagine the Fedora Websites are maintained nicely.
We held back on Easyfix for now after the progress we made here GitHub - t0xic0der/fedora-easyfix: A collection of self-contained and well-documented issues for newcomers to start contributing with. The discussions on Fedora Easyfix are still underway here Let's talk about Easyfix and I would like it to come to a decisive conclusion before we could move ahead with it. Maybe a council discussion would help prioritize the decision-making, I think.
@computerkid and @x3mboy — the tags idea would affect the Podcast category, which is the only place we’re using tags in a special way here. Right now, the Podcast category has #shows, #discussion, and #support (the last of which is unused). With the tags-first approach, you’d tag all of the posts #podcast, and put shows in the Announcements category and discussion in the Discussion category.
Okay, so, I don’t hear people knocking down the doors with alternative ideas. 
@bookwar, what do you think of my tag-focused suggestions? As I posted a few replies up, I’m growing stronger in my opinion that we should go for a tag-heavy approach, with some configuration and hand-holding to make it not feel just like one big undifferentiated list (@jflory7’s concern). Discourse has a lot of awesome flexibility that I’m pretty confident in here.
Taking into account my developing thoughts on this plus this request from my friends at CentOS, my current proposal is this:
There are a some future ideas I could fit into this as well. For example, team calendars could go under Workflows, and we could make announce-list (or even devel-announce and test-announce!) automatic mirrors under Announcements. (See an example of this kind of thing in action.) But I’d start with the framework above.
Exactly the same as above, but separate subcategories for Council, Mindshare, and Engineering under Discussion. I don’t, however, think this is as useful as it appears. I don’t think very many people will really want to subscribe to all Engineering-categories or all Mindshare-categorized posts. And it comes at a cost of needing to make more decisions to post or even browse. But I’ll keep it on the table.
Other ideas, anyone?
(@bookwar, yours is the only other concrete one so far; it’s most like Matthew Idea E but has a big Generic category and puts together site “meta” stuff plus announcements into Service Desk. Any further development of that layout?)
I feel a little hesitant about Matthew Idea D, but I think it’s mostly a “that’s new and I don’t want to deal with new things right now” reaction. The benefits are compelling, and if there’s a way to keep the tags from becoming a mess, I think it’ll work well. Matthew Idea E appeals to me personally, but I agree that there are maybe five people in Fedora who would want that.
I am in the same place as Ben here too.
