On Fri, 2015-08-07 at 11:57 -0400, Paul W. Frields wrote: > I think it would make sense for the Design team to be aware of this > proposal too. I think the criterion has been used as a forcing > function in the past, so if it's not going to trigger a notification > they expect, we don't want designers to be surprised by this change > in > the future. This is exactly what I *don't* want to happen, and what rather annoys me about this whole business. The blocker process is not a tool for the rest of the project to use as a reminder system. It doesn't work very well for that. The expectation the blocker process is built around is that people should be working towards its requirements *all the time*, ideally well in advance, and the blocker process is there to catch the relatively *few* cases where things break unexpectedly. It's absolutely not supposed to work like this: * QA tests Thing and finds no-one ever even started working on it * QA files bug and marks it blocker * Team Thing starts working on Thing I realize that's an exaggerated example, but it's just to make the point clear. That's not a sane development process. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
