> Speaking for myself only here, my experience in the gfx team > is that there are so many bugs that I cannot see the forest > through the trees. > > A list with issues which are not blockers, but only barely so > and it would be really really good to have them fixed, > would certainly be a list I would look at and see if there is > anything on there I can pick up. > > So I like the idea, I do propose to simply re-use most of > the blocker bug process for this, rather then inventing yet > another process. I guess this could even be integrated and > the way to get bugs on the list would be to propose them > as blockers as normal and then during the blocker meeting > when the vote says "no this is not a blocker" a second vote > is done to see if it is a critical bug. As already mentioned, the CommonBugs page might actually fit most of the requirements here. We often place important "almost blocker" bugs in there, issues which are very inconvenient for many people, or critical issues for a specific narrow group of people. If we know it's being used even by developers, we might try harder to include important issues in there. It's not exactly the same idea that Matthew talked about, but I think the overlap is definitely there. As a bonus, there's a quick summary of the issue (which someone has to write, on the other hand, of course). _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
