Considering a general reorganization of this site!

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).

2 Likes

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.

2 Likes

In which I elaborate on the virtues of the tag-based approach

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:

  • 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. :classic_smiley:

@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:

Matthew Idea D

  • Announcements
    • Community Blog
    • Podcast
  • Discussion
    #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
  • CentOS
    [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.

Matthew Idea E

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. :classic_smiley:


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.

1 Like

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

Tag descriptions

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. :slight_smile:

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:
I’d say *-sig, *-wg and *-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 :slight_smile:

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]
2 Likes

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 -sig or -wg would be implicit. This is because:

  1. 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.)
  2. 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. :classic_smiley:
  3. They add to a jargony, confusing feel and I want to make this feel seamless because it’s going to be a big change.
  4. … 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 :classic_smiley: )

Is really dificult answer this question, because:

IMHO

  1. Combine all site in one will be very distraction for and $USER who only want’s and anwers and go and this is the general aproach of ASK, they don’t want to know about discussion TEAM and something like that and navigate the wole system and all categories to get the proper place to post their QUESTION, for example: I’ve got a question humm I think the workstation is the best place I will post my question there, and this was the orignal idea when ASK was launched.
  2. Discussion has a lot’s of Categories, if we have the problem with language categories now in ASK imagine with all this stuff.
  3. You will get to have a warning flags also if you would like to get an answer click here… or there…
  4. In a point of viewe of HUMAN taskforce, the point number 1 will be relevant to redirect wrong TOPIC to the respective category if there are any and I suppose will be MANY.
  5. Educate the $USER.

Regards.,

I can be convinced to bring the two together. I started this discussion in the “Lounge” on Ask a few months ago and people weren’t adamantly opposed (in fact, I think on the balance in favor) but there were some worries.

In short, the main concerns were — well, wait, @hhlp just enumerated them in a new reply while I was writing this one. So see that post.

My particular worry for a merge is that we’ll have a hard time convincing, e.g, the Workstation team members, to actively participate, because people are (justifiably) protective of their time and don’t necessarily want to make doing direct user support the main part of their participation, and therefore may stay away from the whole site. @aday, convince me otherwise?

I think Aleksandra’s proposal leaves pretty easy room for: “Ask Fedora / User Discussion” / “Work Area / Project Conversations” both as separate categories at the top level. (WIth actual names to be worked out.) So I think we can separate that topic out, and with some completely self-aware irony, I think we should continue the “merge?” part of this discussion on Ask Fedora site — I’ve opened a general thread in Site Feedback on that site: Considering a merge into discussion.fedoraproject.org - Ask Fedora

But also: on prioritizing the Editions, yes, I agree — that’s the entire point of that idea. Not just to “sell” them, but to make easy, prominent defaults for people who want to get going in the related area without having to make a bunch of up-front choices, and for those of us helping users to be able to make the same sort of assumptions unless given specific guidance otherwise. So, yes, I think we’ll keep that. But I don’t think they should have “categories” in the technical Discourse sense of Categories, because of… all the things Aleksandra and I have been saying.

1 Like

Ok, I see your points. I agree that suffix feels redundant when it is used repeatedly. I guess the problem for me in the combination of Category name and the tag.

If you call category “Discussion” you need to call tags -sig or -wg otherwise the newcomer will misunderstand the purpose of the tag.

Basically:

  • “Discussion” + #cloud = bad, as neither tag nor category differentiates it from generic conversations on a random user board.
  • “Discussion” + #cloud-sig = fine as tag name has the info that it is a working group conversation not a casual lazy flame about cloud hype.
  • “Working groups/Teams/SIGs” + #cloud = should be fine too, as though tag name is generic, the category explains that it is the place for the working groups, where expectations are a bit different.

There of course can be various other variants like “Work area” + #cloud and so on. I just use this name as an illustration for the idea.

Personally I enjoy participating in threads like “how I stopped using clouds and reduced amount of YAML in my life and things became awesome”, but I don’t want them to accidentally happen in Cloud SIG space :slight_smile:

Agree; can’t be just Discussion if we have a merged site.

I’m not sure I know enough about this to try and convince you one way or another! But I’m fairly confident that we don’t want members of our core teams to be providing support - the goal should be to foster a user/enthusiast community that provides the support itself.

Does the site reorganisation have that kind of community in mind? Will there be a place for the user/enthusiast community to call its own, where it can talk amongst itself?

1 Like