Thank you to everyone who responded to my call for feedback on the SIG process. A few people responded on-list. More people responded off-list. I’ve summarized common complaints, and in a few cases provided comments verbatim - especially when they already went to a public list.

Please see the centos-devel mailing list for further discussion of what happens next.

The following areas were identified by one or more people as pain points in the SIG process.

Purpose of SIGs

Several people said that we do a poor job of communicating what SIGs are for, what should be a SIG, whether something should be a SIG or part of EPEL, and, in general, what the value of a SIG is.

When SIGs were introduced, they were meant to provide an incubator for projects in the CentOS space and also to provide infra/space to give projects a chance to CI test within CentOS, i.e "how does your project work on CentOS?" Has that focus been dropped? If not, would it be a good idea to reinforce the message?

We need to make it clear that Red Hat still has an interest in CentOS. That message would also be valuable for [Red Hat employees]. CentOS is an important place to put Red Hat’s “upstream first” message into action, but this often gets ignored.

Proposal process

Almost everyone said that the proposal process was vague and opaque.

It is unclear what the board is looking for in a proposal. While there is a template - https://wiki.centos.org/SpecialInterestGroup/ProposalTemplate - examples of good proposals, and what kind of specific things the board will look for, would make this process easier.

Access to the wiki to post the initial proposal is a bit of a chicken-and-egg - that is, without a SIG, who has authority to edit a wiki page for the SIG?

The deliberation/discussion of the proposal should happen on-list, not hidden/secret in board meetings. This will also give other potential projects insight into what they should be thinking about in their proposals.

Onboarding

Several people said that onboarding was confusing and undocumented, and seemed to assume you already know what you’re supposed to do.

Note: Several people specifically called out Fabian Arrotin as being extremely helpful in this setup process, with the caveat that he may not scale if we start getting more SIGs onboarding.

The “what’s next” after a SIG has been approved is very unclear. Once approved, what is the process for getting resources set up?

In the past, the SIG onboarding was often gated on one person, and getting their attention was difficult. This should be better with the new Infra sig.

One of the biggest hurdles is the repo setup (deciding on the cbs/koji setup, naming, setting up repositories for mirrors, etc). If you have never touched koji before, this is going to be tough for you. We need much better onboarding documentation for beginners, along with recommended best practices.

If you’re not a Red Hat “insider,” there’s a good chance that your SIG proposal will be ignored, or at least not given priority. The onboarding for [several SIGs] too more than a year - not because it was controversial, but because nobody prioritized it.

Ongoing communication

A number of respondents commented from the contributor side, about the lack of information/communication from SIGs.

The SIG wiki page says that quarterly reporting is required, but the majority of SIGs do not report, and there is no consequence for failing to report.

It is very difficult to find out from the SIGs themselves what opportunities there are for involvement. One respondent replied “I'd like to be more deeply involved in the [name] SIG. It's always a surprise to me how much I push to be a part of the group and how little opportunity there is.”  SIGs need to be much more proactive in what volunteer opportunities there are.

Some SIGs have weekly meetings, some monthly, and some never meet. This is very frustrating to people who want to get involved in the SIGs, but don’t know where to start.

Having an easier, documented way to contact a SIG with questions or offers of help is needed. Right now, we have out-of-date wiki pages with inaccurate lists of SIG members, and no way to contact them even if it was accurate.

SIG wiki pages must be updated with current information. They should also have a standard format, so that basic required information is always available.

Developer Experience

Several developers complained that they were just expected to know what to do, and not provided much guidance or advice as to how to proceed.

Clearer documentation (or pointers to documentation elsewhere) about package building, and how to set up a CI environment.

It would help if every SIG had the same buildroot setup, so that you know what to expect, and moving from one SIG to another was easier. This will increase cross-SIG engagement.

Developer experience on git.centos.org and CBS. Notably:

- the lack of a working PR workflow: https://pagure.io/centos-infra/issue/228 and  https://pagure.io/pagure/issue/4533

- the way the lookaside works: https://pagure.io/centos-infra/issue/259

- hard to discover clone URLs: https://pagure.io/centos-infra/issue/245

- support for modularity in CBS: https://pagure.io/centos-infra/issue/294

The PR workflow in particular is problematic -- right now we rely on SIG members pushing directly to the repos, which makes code review difficult. It's also a blocker for external contributions (as, though one can technically put up a PR, there is no way to actually merge it).

I would love to have something closer to the workflow in Fedora. specifically:

- allow SIG members to review and merge PRs onto their branch

- kick off scratch builds on PRs to get signal

We need a way for  SIGs to publish structured documentation on docs.centos.org, akin to the "quick docs" model that Fedora uses.

Missing -devel subpackages (I know this has been discussed a lot and fix is in progress).

I'd like to build, tag and push release rpms (as centos-release-openstack). In CentOS7 we could build and tag by ourselves (although it needed infra action to push). In CentOS8 we need to rely on CentOS infra to build and publish them in extras repos.