Package-specific test case project: news, and a mockup

So I'm still working on my current big QA project, package-specific test cases - this started out as 'critical path package test cases', but it became clear as I was working on laying out a model for this that that wasn't the best way of looking at it; not all test cases relating to a critical path package are related to critical path functionality, so we needed to define the concept of package-specific test cases, and also provide a way of marking particular test cases (whether package-specific or not) as being related to critical path functionality. I recently posted a draft of my proposal for a standard categorization method for package-specific test cases (and critical path test cases) to the devel and test mailing lists, and it's been getting some good feedback and I've been refining it. However, the whole thing may be a bit hard to get a hold of a corner on unless you're thinking about it as much as I am, so I thought a super-lame mockup might help! Voila: Of course any final implementation of this would not look like ass (I hope...) but this should get the point across. The idea is that having a standardized categorization scheme for package-specific test cases will allow Bodhi (and other tools, like fedora-easy-karma) to reliably discover what test cases relate to a particular package, and then display the relevant test cases for any update on the page for that update. They would be links, of course. So you can look at the page for an update and immediately discover what test cases you can run to test it. Having a category for critical path test cases allows Bodhi to do a trivial operation ('what test cases are in *both* the category for this package *and* the critical path test cases category?') to prioritize any test cases relating to the package which also relate to critical path functionality. The optional 'advanced' categorization in my proposal, if used, allows Bodhi to display test cases for core functionality and test cases for extended functionality separately. Note that there's no 'special sauce' needed for what's in this mockup: the way it looks is how it would look if Bodhi simply derived all the text strings from category names. It should be simple for Bodhi to find the category 'Category:Package_xorg-x11-drv-ati_core_test_cases', and extract the string 'Core' to display as the name for that group of test cases (as the rest of the category name is standardized). Possibly we'd need to hard code the relative priority of certain standard group names, so Core gets displayed above Extended, or we could figure out a way to extend the proposal to denote this. But mostly it's all there. (The test case names would have to be standardized to allow Bodhi to display only the relevant bit of the test name, I suppose - I haven't put this in the proposal yet, but I could). So, this is the sort of thing the proposal is meant to make possible - I hope this makes it clear why it's cool! The advanced version of this would be that, with Bodhi 2.0 featuring non-numeric karma, the listing for each test case would have a drop-down box or radio buttons or something to mark 'pass' or 'fail'. fedora-easy-karma could similarly display the available test cases, and provide a method for you to input a result for each.