[almighty] Clarification around Types

Aslak Knutsen aslak at redhat.com
Mon Jan 23 13:36:24 UTC 2017


If that's the same QuickAdd bar, then I think it should visually be moved
inside the Open WI draw to show the context things are being added and the
'type selector' be filtered same as 'allowed links'.

-aslak-

On Mon, Jan 23, 2017 at 2:23 PM, Konrad Kleine <kkleine at redhat.com> wrote:

> Aslak,
>
> yes we need something superior, but if the quick add bar simply performs
> two actions rather than one, we're safe:
>
> 1. Add work item (userstory)
> 2. Link to currently "open" work item (epic)
>
> That implies three things (at least)
>
> 1. we can have some form of navigation that makes allows for filtering
> user stories based on a concrete link type (e.g. child of)
> 2. the quick add bar knows about which link type can be used (maybe the
> one which was used to filter in the first place?)
> 3. the quick add bar adds the new work item (userstory)
> 4. the quick add bar creates the link between the epic (currently filtered
> on) and the newly created user story
>
>
>
> On Mon, Jan 23, 2017 at 2:08 PM, Aslak Knutsen <aslak at redhat.com> wrote:
>
>> That workflow is unrelated to 'Epics'.
>>
>> It's what we do in every planning sessions on some level.
>>
>> Create/Read a userstory, add 10 tasks.
>>
>> It's a feature for, I create/have a parent, now create n children.
>>
>> We need a better approach than;
>>
>> * Create parent
>> * Create child 1
>> * Create child 2
>> * Create child n
>> ...
>> * Open parent
>> * Search and Link child 1
>> * Search and Link child 2
>> * Search and Link child n
>> ...
>>
>>
>> -aslak-
>>
>> On Mon, Jan 23, 2017 at 1:58 PM, Konrad Kleine <kkleine at redhat.com>
>> wrote:
>>
>>> If I were a user of the system I'd probably go in and
>>>
>>>
>>>    1. create an epic from the work item type dialog.
>>>    2. go to the quick add and add 10 features
>>>
>>> IMHO we shouldn't first build for custom tailored UI solutions that fit
>>> a work flow specific to epics. I'm not saying we shouldn't do this at all
>>> but if we have the tools in place to do operate generically, then this is
>>> good start, no?
>>>
>>> On Mon, Jan 23, 2017 at 1:51 PM, Todd Mancini <tmancini at redhat.com>
>>> wrote:
>>>
>>>> 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.githubuserconten
>>>>> t.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/2dc7b53a/attachment.htm>


More information about the almighty-public mailing list