[almighty] Clarification around Types

Konrad Kleine kkleine at redhat.com
Mon Jan 23 12:39:44 UTC 2017


We currently have the a little icon next to the left most field once you've
clicked the quick add button. I suggest to make this a toggle just like we
used to have it for the work item symbol in the top left corner of the
details page:
https://cloud.githubusercontent.com/assets/193408/21686784/d717829e-d366-11e6-9641-b61cece54c99.png.
Currently this is just a symbol and no longer a menu.

On Mon, Jan 23, 2017 at 1:26 PM, Aslak Knutsen <aslak at redhat.com> wrote:

> Then what happens to QuickAdd when there are multiple types shown in a
> list?
>
> On Mon, Jan 23, 2017 at 1:21 PM, Konrad Kleine <kkleine at redhat.com> wrote:
>
>> Hey Aslak,
>>
>> > The QuickAdd feature is currently hard coded to add items of type
>> 'UserStory'. With no fixed types and no option to change the type this
>> looks wrong.
>> > Should the Process Definition have some option to define a 'default'
>> Type that should be used here?
>> > Should the Quick Add have an option to select which type it should
>> quick add? Optionally, should the Quick Add remember the users previously
>> used type? Or
>> > possible types based on some form of role, e.g. PM's would most likely
>> create Experiences, SM UserStories and Devs Tasks?
>>
>> As far as I understood UI and UX, they want to make the quick add bar
>> context sensitive. So when you're viewing a list of user stories, the quick
>> add will just add user stories. But if you're viewing a list of epics, the
>> quick add shall add epics. I have no clue about the technical realization
>> yet but that's at least what I heard from talking to different people. It
>> seems the most convenient to me instead of having some process defining
>> what you can quick add.
>> The only problem I see is how to get the "context", e.g. how to know that
>> the list of work items is currently just showing features, epics or user
>> types. Shall this be done with filters or maybe implicit filters?
>>
>> - Konrad
>>
>> On Mon, Jan 23, 2017 at 12:08 PM, Aslak Knutsen <aslak at redhat.com> wrote:
>>
>>> A few points to clear up around the generic type system.
>>>
>>> 'Epic'
>>>
>>> In the UX designs, Epic is special, e.g. it shows up as summary points
>>> in the same draw as Iterations and can be created directly from the
>>> 'right-click' menu: https://redhat.invisiona
>>> pp.com/share/QU9U8D8GF#/screens/212141138
>>>
>>> What is the generic term/feature for this? Is the intent to be able to
>>> define as part of the Process Template which Type should be the
>>> 'special/top' type? What is the equivalent type in the PDD style,
>>> Vision/Experience?
>>>
>>> Part of https://github.com/fabric8io/fabric8-planner/issues/657
>>>
>>>
>>> 'WorkItem Links hierarchy'
>>>
>>> Same as a Feature can be a Child of an Experience, a UserStory is a
>>> Child of an Epic. What are the Link Forward and Reverse names for this
>>> relationship?
>>>
>>> Relates to? Belongs to? Child of? Part of?
>>>
>>>
>>> 'Quick Add'
>>>
>>> The QuickAdd feature is currently hard coded to add items of type
>>> 'UserStory'. With no fixed types and no option to change the type this
>>> looks wrong.
>>>
>>> Should the Process Definition have some option to define a 'default'
>>> Type that should be used here?
>>> Should the Quick Add have an option to select which type it should quick
>>> add? Optionally, should the Quick Add remember the users previously used
>>> type? Or possible types based on some form of role, e.g. PM's would most
>>> likely create Experiences, SM UserStories and Devs Tasks?
>>>
>>>
>>>
>>> PM's input appreciated.
>>>
>>>
>>> -aslak-
>>>
>>>
>>> _______________________________________________
>>> almighty-public mailing list
>>> almighty-public at redhat.com
>>> https://www.redhat.com/mailman/listinfo/almighty-public
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20170123/6370f768/attachment.htm>


More information about the almighty-public mailing list