On Tue, 2016-11-29 at 19:41 +0530, Kanika Murarka wrote: > Hey everyone, > I have some thoughts for the project:- > > 1. We can have a notification system, which gives a notifications like:- > * 'There is a test day coming for this compose in 2 days' > * 'A new compose has been added' > Something to motivate and keep reminding testers about test days and new > composes.
Yeah, this is certainly going to be needed if only simply to replace the Wikitcms event creation notification emails (these are sent by 'relvalconsumer', which is the fedmsg consumer bot that creates the events). > 2. Keep a record of no. of validation test done by a tester and highlight > it once he login. A badge is being prepared for no. of validation testing > done by a contributor[1]. Well, this information would kind of inevitably be collected at least in resultsdb and probably wind up in the transmitter component's DB too, depending on exactly how we set things up. For badge purposes, we're *certainly* going to have this system firing off fedmsgs in all directions, so the badges can be granted just based on the fedmsgs. 'User W reported a X for test Y on compose Z' (or similar) is a very obvious fedmsg to emit. > 3. Someway to show that testing for a particular compose is not required > now, so testers can move on to newer composes. We're talking about approximately this in the design ticket. My initial design idea would *only* show images for the 'current' validation event if you need to download an image for testing; I don't really see an awful lot of point in offering older images for download. I suggested offering events from the previous week or so for selection if you already have an image downloaded, to prevent people having to download new images all the time but also prevent us getting uselessly old reports. I'd see it as the validator/submitter component's job to keep track of information about events/composes (however we conceive it), like when they appeared, and the web UI's job to make decisions about which to actually show people. > 4. Also, we can add a 'sort by priority' option in the list of test images. Yes, something like that, at least. The current system actually does something more or less like this. The download tables on the wiki pages are not randomly ordered, but ordered using a weighting provided by fedfind which includes the importance of the image subvariant as a factor: https://pagure.io/fedora-qa/fedfind/blob/master/f/fedfind/helpers.py#_331 It currently penalizes ARM images quite heavily, which is not because ARM isn't important, but a craven surrender to the practical realities of wiki tables: they look a lot better if all the ARM disk images are grouped together than if they're interspersed throughout the table. We obviously have more freedom to avoid this issue in the design of the new system. Thanks for the thoughts! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ qa-devel mailing list -- qa-devel@lists.fedoraproject.org To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
