Fedora-Council/tickets ticket #435: Research the available SIG documentation

@bookwar filed Fedora-Council/tickets ticket #435. Discuss here and record votes and decisions in the ticket.

Ticket text:

The CentOS SIG practices are not relevant for Fedora. Among other things, CentOS SIGs operate much more like Fedora Working Groups (which require Council permission to exist and have regular reporting requirements, etc.).

This ticket didn’t get much context during our meeting (since it was opened as a placeholder, really), but the intention in looking over there as part of this is to see what we can learn and benefit from, and where it might make sense to have greater conceptual overlap. Also, it seems like in practice (but maybe not in documentation?) that CentOS SIGs are operating in a more relaxed manner than originally prescribed, and so maybe there’s some back-and-forth to do.

Nah, the CentOS SIGs are just more dead overall than Fedora ones. The ones that are alive wind up having to make reports quarterly and such. There’s also a board member responsible for each SIG as a sponsor. Honestly, it’s way too much for SIGs in Fedora, but it pretty much mimics how Working Groups work.

I like our lightweight approach (no barriers!), but it has a problem where it’s really hard for newcomers to know if a SIG is alive or dead. Often, someone shows up with an idea and some motivation, posts on devel asking for interest, there’s enthusiasm, and so a wiki page is created, people are listed, a mailing list blooms, etc. … but then the spark fails to catch and just a few months later, there’s nothing going on behind those fronts. (Other times, of course, there’s a success — but those can become invisible even when active.) And, we don’t have a “mark as dormant” (or dead) process at all.

I hoped to solve that by centering SIGs around Taiga, but few teams took that hook, so we need a different approach.

I’m trying to understand the new workflow. Why was this topic closed? Should we go back to using Pagure for discussion?

I closed it because the ticket wasn’t meant to be a discussion starter, and lacked all proper context to have a useful discussion.

The thread was spawned because a ticket was created, because that’s how I had it set up previously. At the Council meeting, we decided that the tracker should be used for all sorts of Council tracking, as you have suggested. But many of these things are not intended to spawn discussion at all, and are just work items or reminders for team members.

We discussed having a way to skip creation of linked topics, but I like having them, because this way I get notifications in one place. Plus, if a topic is here and it turns out there should be discussion, it’s easy for us to move it — or, even if we don’t, for anyone to create a linked topic.

So, we decided to direct them here (a category which we separately decided to try instead of external hackmd, google docs, or a wiki for council work-in-progress).

I do need to update the bot’s automatic message, but I haven’t figured out the wording yet.

Where is this coming from?