On Tue, 2016-11-29 at 19:41 +0530, Kanika Murarka wrote:
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
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
2. Keep a record of no. of validation test done by a tester and
it once he login. A badge is being prepared for no. of validation testing
done by a contributor.
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
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
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
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
Thanks for the thoughts!
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net