Hello folks,

wanted to thank you all for supporting the FCOS Test Day which turned out to be a very successful event! As we looked back, we thought there might be room for more community participation in FCOS QA. On those lines, we were wondering if there are good ways for other Fedora teams and for the community in large to get a good picture of how quality validation and decisions are done for the FCOS stable stream, and how people who are interested can participate in this process.

In particular, I tried to find some documentation on:
* The pool of bugs which are currently reported against the testing and next stream
* The subset of aforementioned bugs which were decided to be "blockers" and must be fixed before the stream can be promoted to stable
* Where this blocker decision-making takes place and how people can get involved
* What are the procedures and rules for this blocker decision-making process

Unfortunately, I was not able to find any. I might be looking at a wrong location. Can you please point me to the correct place, if such documentation exists?

Since FCOS might soon be an official Fedora edition, it would be great to have insight into the FCOS community release process. But this is far from just a QA team thing. This process transparency is important for recruiting new passionate community members who can help you run and improve things. Another use case might be a party affected by a bug who might feel motivated to visit such a blocker discussion and argue their case about why they think such a bug should not hit the stable stream.

We can put together all the relevant documents in one place that is accessible to the public so that the community is aware of important decisions made during the release process and feel included. I imagine that there could be a "Participate!" section in the FCOS docs page [1] which would point people to areas where they can help FCOS, and one of those areas could be quality control. What do you think?

As an example, the current quality validation workflow in Fedora includes a regular "blocker review" meeting in a dedicated IRC channel, where bugs proposed as "blockers" get discussed [2][3]. Anyone can propose a bug as a blocker and we regularly receive bug nominations from the community. The blocker review meeting is open to anybody and we try to base our votes on "release criteria" [4] after assessing that particular case and its circumstances. Release criteria help us bring a bit more consistency into this blocker decision-making and it saves us some time from looking up historical evidence ("how did we vote last time on a similar bug?"). All currently proposed and accepted blockers are visible from our custom page [5]. This whole process is a collaborative effort between Release Engineering, Quality Assurance, Development, and Project Management. Please note that while I'm describing our current process as an example, I'm not implying you need to do it in the same way. I'm just showing how we do it in general. Also, our documentation is quite complex and lengthy, but essentially it can be just a couple of paragraphs with links, to steer people into the right direction.

Looking forward to hearing your thoughts. Thanks!

Kamil
Fedora QA

[1] https://docs.fedoraproject.org/en-US/fedora-coreos/
[2] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
[3] https://fedoraproject.org/wiki/Blocker_Bug_FAQ
[4] https://fedoraproject.org/wiki/Fedora_Release_Criteria
[5] https://qa.fedoraproject.org/blockerbugs/milestone/33/beta/buglist