Hey Community Blog team — can we move "review and publish" to a Workflows category?

I would like to avoid having the Project Discussion area full of functional posts that aren’t really discussion. For those, we have the Team Workflows category — or more exactly, subcategories within that for each separate workflow. See the Fedora Magazine workflow category for a comparable example.

In fact, one possibility (if both teams agree) could be to use the existing category (possibly under a slightly different name), with #magazine and #community-blog tags to distinguish. (Folks who only care for or the other could mute the one they don’t need to see.) But it would also be easy for me to make a separate new category.

In addition to keeping Project Discussion for human thoughts rather than process, this would also let us lower search priority (both for the internal site search and via hints to external search engines). This site has high search engine rankings generally, so without this there’s a risk of people finding meta-process posts-about-posts before the actual final article.

What do you think?

I haven’t been able to help @bcotton enough lately to comment on workflow change… but as long as there is an a way to receive notifications on change request, should work fine :slight_smile:

I’m fine with it, but I object to combining it with Magazine. That’s a separate team with separate standards, etc. Combining them will only lead to confusion.

I will go ahead and create the category.

I am all for pulling out the CommBlog editorial into a workflow category. It should probably shift ownership outside of CommOps anyways.

I agree with Ben that I don’t want that either.

I would also like the new category to be less tied to a specific team, or at least to free CommOps from the implicit connection of “owning” the CommBlog.

But is it basically the same workflow and similar permissions? Because we could put, like, fifteen such things in the same category.

Hmmmmmm. If CommOps doesn’t own it, who does?

Maybe, but the stakeholders involved with each workflow are different. Is there a particularly good reason not to have multiple tags for different teams? I’m trying to understand the incentive for fifteen different things in one category.

The PgM Team seems better aligned since @bcotton / FPgM owns it as editor-in-chief.

  1. What PgM Team? :slight_smile:
  2. I don’t own it as FPgM, I own it as “this is a thing I’m interested in doing.”

As for the ownership, it exists in a liminal SPOF space at the moment. It’s mostly me with occasional support from Vipul, but there’s not an organized team behind it at the moment.

Take a look at Navigating Fedora Discussion — Tags, Categories, and Concepts - Fedora Discussion, which covers the information architecture for the site. The incentive isn’t to have fifteen different tags in a category, but rather to avoid fifteen different categories which are functionally similar, just covering different topics or targets.

It’s not a big deal for two (and especially, subcategories under Team Workflows are the most lightweight), but it might be for three or four. So I wanted to consider up front.

I’ve created Community Blog Review. Right now, there is a magazine-editors group which additionally has moderation access to Fedora Magazine[1]. What is the equivalent for this group? (This permissions difference is a reasonable-enough one to have a separate category under the explanation in my last reply — if it matters.)

  1. which probably should be renamed to #magazine-review or something, but that’s a different topic! ↩︎


I’m fine with creating a commblog-editors category if that makes life easier.

By the end of Christmas break, I hope to have syncing from FAS groups operational. So a commblog-editors group there would be ideal — is there one already?

Survey says “yes”.

Well then. I’ll create it manually now, and then in the future, magic sync will start happening.

As you may have noticed, this is now live at Community Blog Review - Fedora Discussion, and existing messages have been moved there.