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!)
Idea C: All-in on tags over categories
Announcements - Community Blog Discussion <- BASICALLY EVERYTHING Site Feedback Workflows - Fedora Magazine Article Proposals - Projects in Copr
Same note as above on mandatory tags.
Again, Workflows would be muted by default. And maybe we move the Copr category under it?
- I propose we kill “off-topic”. They’re not heavily used, and we could have a “just-for-fun” tag or whatever.
- If we decide that starting threads by email is important, we could direct those all to a muted-by-default “staging category”,
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
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.
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:
- different permissions (announcements come to mind, or the “protected” newbie/join zone)
- areas where we want topics to be wikis by default
- commblog comments
- the copr integration
- specific workflow like the Fedora Magazine proposals
- specific tag requirements (for example in a support area) or even tag sets (podcast category as it is now)
- new topics should start with a specific template (see idea for Common Issues over on Ask)
- whether “solved” and/or voting plugin are enabled
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:
- Community Blog
#council, #commops, #iot, #cloud, #workstation, #spins, #coreos, #qa, #infra, #epel, #risc-v, #rust, #websites-and-apps, #magazine, #site-feedback, …
Workflows [muted by default]
- Fedora Magazine Article Proposals
- Projects in Copr
- Automated Meeting Invites
[tags as determined by CentOS, in a separate tag group]
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?)
2 posts were split to a new topic: Calendars which auto-update based on incoming mail?
Hello @mattdm ,
Idea D looks okay to me.
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.
Related — new helpful feature for making tags more prominent:
New features in 2.8.0.beta9
Staff can now add descriptions to tags, just like categories. Descriptions are displayed when hovering over a tag in the topic list.
To add/edit a tag description, as staff, navigate to the tag page, click the wrench, and then the edit pencil.
Never mind that they’ve used another distro in the image for their example.
Sorry for delayed reply.
Looks like we are going in the same direction, but there are some nuances which I want to discuss.
I am fine with removing Mindshare/Engineering subcategories. They indeed do not add much and also I generally prefer engineering folks to be more aware of what’s going on in Mindshare and the inverse as well.
But the other difference between proposals is the meaning of the tags themselves.
I think that we don’t want a forum for generic discussions about Fedora, rather we need a place to do the real work. Thus I want tags to represent not the generic topics but rather org units of Fedora which highlights that these groups actualy use the forum for regular business.
Thus in my proposal I had a more formal tag naming. I prefer #cloud-sig label over #cloud as it is not just everything which is related to the cloud topic but something which is specifically targeting the organizational structure which is Cloud SIG.
We can have additionally tags for topics, but i think we should have have dedicated tags for groups:
*-team tags should be reserved and kept in sync with Working Groups, SIGs and Teams as org units.
And in the same spirit, it was the reason why I had a separate Service Desk/Generic or whatever category. Because in my vision the Discussion is not just Discussion it is a coworking space. And all meta, social, off-topic tech and non-tech things while important they should happen outside in the kitchen area
I think that if we are to make forum a true replacement for mailing lists we need to treat the discussion topics a bit more seriously and therefore moderate with more strict rules.
I would also have a SiteFeedback or Help category somewhere on top. Because for newcomers the tagging structure might be confusing and it would be nice to have a clear path for getting help.
So for me it would be somewhat like:
* News #announce #commblog #podcast * Site feedback and Help * Work area/ Working Groups / Really Serious Business #cloud-sig, #qa-team, #ci-sig, #eln-sig, #join-sig, #council... * Specific Workflows [muted by default] Fedora Magazine Article Proposals Projects in Copr Automated Meeting Invites * Water-cooler (Tech and non-Tech fun) Includes #magazine (every published magazine article) * CentOS [tags as determined by CentOS, in a separate tag group]
The main thing I’d want to see from any reorganisation is a prominent workstation category. I’d also like to see us prioritise our main editions rather than having them mixed in with other spins, initiatives, activities, etc. Otherwise there’s a danger of our main offerings getting lost.
Aside from that, the thing I really wonder about is the split between the discussion and ask Discourse instances. Personally this always seemed a bit surprising and seems to create a fair amount of awkwardness.
To me it seems like a losing battle to have two discussion sites trying to perform different functions. If you’re constantly having to direct people to one site or another, with banners everywhere saying “don’t ask questions here!” then that’s a red flag - it tells you that you’re fighting against the flow.
Despite all the “don’t ask questions here!” banners, we still end up with plenty of people asking questions on discussion.fedoraproject.org, which results in having to check and use two sites rather than one (say if you want to provide support or look for information).
(I’d also be really wary of designing the “discussion” site with only contributors in mind. Users often want to have discussions, and it’s important that we provide them with a platform to do that.)
The other issue with the “ask”/“discussion” split is that we have the oddity that ask.fedoraproject.org is a discussion site masquerading as an “ask” site. It looks a bit odd, and leaves the “ask” experience being somewhat non-optimal.
On the flip side, there could be positive impacts to combining the two sites - people who are active on the discussion side could easily help out with answering questions in a a help section, and so on.
I’m not sure I understand - why don’t we want a place for people to have discussions about Fedora?
Personally one of my main interests is how we can encourage and support a passionate user community. A platform for discussion seems like an important thing to have from that perspective.
I think we’re in general agreement here. My idea is to use a “tag group” which restricts tags to a pre-defined set which we curate intentionally — a “Fedora team tags” group, in fact. So, the
-wg would be implicit. This is because:
- Many people find the -team, -working-group, -sig, -subproject, -etc. labels confusing, which is why we decided to officially de-emphasize the distinction in our 2018 Council face-to-face. (I had gone into that meeting with a proposal to make the name distinctions clear and formal and important, and pretty much everyone else convinced me otherwise.)
- As a consequence, the names are kind of fluid, and for example Cloud WG and Cloud SiG have kind of merged back and forth into each other, and teams might decided to change the designation, and I don’t want to be renaming tags all the time to match.
- They add to a jargony, confusing feel and I want to make this feel seamless because it’s going to be a big change.
- … I think they’re kind of ugly that way?
What you’re saying about site help makes sense to me, and I like the “water cooler”. We can add magazine pretty easily in that way by using the same plug-in we do for the Community Blog. (And on a technical note, that works best with a sub-category, so in News the commblog would stay that way. We could also add read-only mirrors of the announcement mailing lists to News, again using subcategories.
So, okay, yeah, I’ll put together a… Proposal F, I guess.
(Hold on, Allan — replying to your part next )