> I have a feeling that I haven't explained properly that the
core of
> the proposal is a SOP change, and the web app workflow is just a
> bonus to make it prettier. Is it clearer now? Do you still have
> the same concerns?
To an extent, yeah. I guess I just feel like the 'manual' version of
this process is too complex to rely on, and would result in bugs that
should be nominated not getting nominated.
Hmm, I see. You might be right and that's why I always imagined it with the tooling
support.
So, what if we kept everything intact and just changed our internal QA process?
1. Any user proposes anything as a FE by tagging the bug
2. One of QA members adds a Bugzilla comment (we can keep a template somewhere) that
basically asks:
a) whether there is an available developer willing to work on it in the required
timeframe
b) the developer to provide some useful details, like the risks involved
3. On the blocker bug meeting, the organizer goes through the list in advance and
pre-selects for discussion those bugs which already have some developer feedback. Of
course we can also include in the discussion those bugs for which we know the developers
are available over IRC and can provide us with the information in real time. Typically
anaconda developers. The purpose is not to have bureaucratic hurdles, but just make sure
we receive some basic data to work with, and to know the developers want to fix it. It
doesn't matter which channel it goes through.
This is a fairly minimal change and all the burden is on us. It still keeps the idea of
avoiding useless discussions.