The user interface improvements for the job page and recipe page [1]
have been in planning/discussion for quite a while now, but recently the
team has been making good progress on prototyping the new interfaces
with a view towards implementing them in Beaker 22.0.
One issue we ran up against while prototyping the job page was how to
handle the ack/nak/comment functionality for recipe sets. In the
original design document we essentially hand-waved past this but when it
came down to actually implementing something we realised the current UI
with a tri-state selector plus comment modal does not fit in with the
new design, and it offers a very subpar user experience as well.
After some discussion the Beaker development team came up with the
following plan for tackling the ack/nak/comment issues:
* The comment functionality will be separated out from ack/nak and
fully fleshed out, supporting multiple comments from different users
and recording the commenting user and timestamp. It will also be
expanded to support commenting on tasks and results, which was one of
the key requested items for Beaker 22.0.
* The original design proposal for the job page improvements mentioned
allowing ack/nak/comment on recipes, tasks, and results. However it's
not clear what the meaning or behaviour of a nak at one of these lower
levels should be, and also unclear if nack'ing individual results is
even useful or desirable, so we will defer this. For now, ack/nak will
only apply to recipe sets as it does now.
* The terms "ack" and "nak"/"nack" have no precedent in
other testing
systems and their meaning is unclear to new users. The "nak" setting
will be renamed to "waived" in line with its intended meaning. However
the existing response="nak" attribute in the job results XML will be
preserved for compatibility.
* The distinction between "needs review" and "ack" does not seem
useful
so it will be removed. All recipe sets will effectively by "acked" by
default. (Recipe sets with a Pass result are already acked by default
right now.)
In particular this means the operation of changing a failed recipe set
from "needs review" to "ack" will no longer be possible. The only
operation will be "waive" which is equivalent to nack'ing a recipe
set, or "un-waive" to reverse it.
If you see any issues with the above, or if you think it might break
your workflows, please hit reply.
[1]
https://beaker-project.org/dev/proposals/job-page-improvements.html
--
Dan Callaghan <dcallagh(a)redhat.com>
Senior Software Engineer, Products & Technologies Operations
Red Hat, Inc.