Include and mandatory-include behaviour in test plans

[Zygmunt Krynicki]

Sounds good to me. Ping me if somethnig is missing in textland to support this.

On Thu, Jun 18, 2015 at 12:26 PM, Maciej Kisielewski
<maciej.kisielewski at canonical.com> wrote:
>> Is it possible to have a "greyed-out" look in checkbox-cli?
>
>
> Not yet :-)
>
>> Just a comment about "greyed out" for jobs that are not user selectable
>> (if I read that right, this means jobs that appear and must run and the user
>> can not disable them).  Typically in UIs, greyed out means something is not
>> a valid option, or does not apply to this scenario.
>>
>> For example, you may be in a UI that provides for certain tools, but those
>> options are greyed out if you're not in a certain mode, or certain data
>> hasn't been entered or whatever.
>>
>> So at least from my perspective, greyed out means it's not applicable, not
>> "fixed or immutable".
>>
>> But that's a minor quibble, the act of sorting all these things out is
>> more onerous.
>
>
> Yeah, grey-ed out things usually imply that the widget is disabled (i.e.
> doesn't respond).
>  I was thinking about something like this (color as rendered in terminals):
>
>  [X]   Mandatory job
>  [X]   Normal job
>
> I hope this makes more sense.
>
> On Thu, Jun 18, 2015 at 5:43 AM, Jeffrey Lane <jeffrey.lane at canonical.com>
> wrote:
>>
>> Just a comment about "greyed out" for jobs that are not user selectable
>> (if I read that right, this means jobs that appear and must run and the user
>> can not disable them).  Typically in UIs, greyed out means something is not
>> a valid option, or does not apply to this scenario.
>>
>> For example, you may be in a UI that provides for certain tools, but those
>> options are greyed out if you're not in a certain mode, or certain data
>> hasn't been entered or whatever.
>>
>> So at least from my perspective, greyed out means it's not applicable, not
>> "fixed or immutable".
>>
>> But that's a minor quibble, the act of sorting all these things out is
>> more onerous.
>>
>> Good luck!
>>
>> On Wed, Jun 17, 2015 at 11:00 PM Pierre Equoy <pierre.equoy at canonical.com>
>> wrote:
>>>
>>> On Wed, Jun 17, 2015 at 8:09 PM, Maciej Kisielewski
>>> <maciej.kisielewski at canonical.com> wrote:
>>>>
>>>> With the advent of a field specifying mandatory jobs for test plan units
>>>> (which I will call 'mandatory-include' from now on), there are a few design
>>>> decisions we have to make.
>>>>
>>>> If you have better alternatives for my approach below, please, do share
>>>> :-)
>>>>
>>>> As the job may be present in the 'include' and/or 'mandatory-include'
>>>> fields, we have 4 scenarios. This is my proposed behaviour for them:
>>>>
>>>> 1) not included, not mandatory-included
>>>>
>>>> Job shouldn't be available on job-selection screen. Job should never
>>>> run. Note that if the job is required by other job it may become visible
>>>> and, when selected, might be run.
>>>>
>>>> 2) included, not mandatory-included
>>>>
>>>> Job should be available on job-selection screen, user should be able to
>>>> select and deselect it. It should be run only when selected or required by
>>>> other jobs.
>>>>
>>>> 3) not included, mandatory-included
>>>>
>>>> Job should not be listed in job-selection screen and it should ALWAYS
>>>> run.
>>>>
>>>> 4) included and mandatory-included
>>>>
>>>> Job should be listed in job-selection screen, but user should not be
>>>> able to deselect it. It should always run.
>>>> Jobs that are not deselectable should be rendered differently to cue the
>>>> user (e.g. greyed-out)
>>>
>>>
>>>
>>> Is it possible to have a "greyed-out" look in checkbox-cli?
>>>
>>>
>>>>
>>>>
>>>> As an alternative, 3) could behave like 4) with advice from validators,
>>>> that when placed in 'mandatory-include' the job doesn't have to be specified
>>>> in the  'include'.
>>>>
>>>> What do you think?
>>>
>>>
>>> I think it's better if the tester is always aware of what's being run, so
>>> 3 and 4 should behave the same (i.e. be showed during job selection process,
>>> even if tester cannot interact with it).
>>>
>>>
>>> Thanks!
>>>
>>>>
>>>>
>>>> --
>>>> Have a good one,
>>>> Maciek
>>>>
>>>> --
>>>> Checkbox-devel mailing list
>>>> Checkbox-devel at lists.ubuntu.com
>>>> Modify settings or unsubscribe at:
>>>> https://lists.ubuntu.com/mailman/listinfo/checkbox-devel
>>>>
>>>
>>>
>>>
>>> --
>>> Pierre Equoy
>>> QA Engineer | Canonical
>>> www.canonical.com | www.ubuntu.com
>>> --
>>> Checkbox-devel mailing list
>>> Checkbox-devel at lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/checkbox-devel
>>
>> --
>> Sent via a phone. Please forgive brevity and typos.
>
>
>
>
> --
> Have a good one,
> Maciek
>
> --
> Checkbox-devel mailing list
> Checkbox-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/checkbox-devel
>