> > 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. -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
