[almighty] Clarification around Types

[Todd Mancini]

Can someone describe to me the experience of this common usage pattern: a
user wants to create a new Epic and ten related Features. What's that
workflow for that?

On Mon, Jan 23, 2017 at 7:39 AM, Konrad Kleine <kkleine at redhat.com> wrote:

> 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/8a973fdb/attachment.htm>