[almighty] Clarification around Types

[Pete Muir]

Oh, I just realised what you are saying. You would add some sort of label
or flag to a type which indicates it is a root in the UI, e.g. by putting
the type in a category, and flagging that category. Yes, that makes sense.

On 25 January 2017 at 09:54, Pete Muir <pmuir at redhat.com> wrote:

>
>
> On 24 January 2017 at 16:56, Max Rydahl Andersen <manderse at redhat.com>
> wrote:
>
>>
>>
>> /
>>
>>
>>> On Mon, Jan 23, 2017 at 1:39 PM, Todd Mancini <tmancini at redhat.com>
>>> wrote:
>>>
>>>> Epics are not 'special'. There are a work item type like any other.
>>>>
>>>
>>> I know they are not 'special' in the sense of WIT, but they are
>>> 'special' in the sense of the Planner/Process.
>>>
>>> The question still remains, What would you call what Epic is to Scrum,
>>> as a generic term for a process? Is it just the highest order of 'major
>>> portofolio planning type', the one that can't be anyones child?
>>>
>>
>> I think of it as the root work item type in the tree of work item type
>> parent-child relationships.
>>
>> That's quite verbose, so I would suggest shortening to something like
>> "root work item type".
>>
>>
>>
>> I think root item is too limiting, at least if we expect to be able to
>> capture both PDD items (vision, experiences, value props, etc.) and scrum
>> items (epic, story, tasks) in the same Space.
>>
>> Here there will be either one root (Vision) very high up or two roots
>> Vision and Epic.
>>
>> I think we are better of very early on to introduce a way to categorize
>> types, i.e. "Epic" are of category "backlog planning hierarchy" which the
>> backlog ui will use for the root of its queries....
>>
>
> I think we're saying the same thing, I'm just saying that you mark certain
> types as root types, you're saying we mark a category of things root type.
> Both seem fine approaches to me.
>
>
>>
>> /max
>>
>>
>>>
>>>>
>>>> When creating a new Space, it's very likely that installed extensions
>>>> need a way to augment the Space -- and this augmentation can be driven by
>>>> the process methodology script/template chosen by the user.
>>>>
>>>> So, for example, when a user creates a new 'Scrum'-based Space, the
>>>> Scrum methodology template may include in it special instructions or
>>>> information of the Planner extension -- information such as 'the major
>>>> portfolio planning types are Epics, Features and PBIs, in that order (or
>>>> maybe order is deduced from work item type links?)
>>>>
>>>> In other words, why that list is on the side and presented the way it
>>>> is is because of something the Planner knows and has stored into the Space.
>>>> It's not a fundamental capability of the system -- although it's built
>>>> on-top-of fundamental features, such as work item type categories and work
>>>> item types.
>>>>
>>>> We haven't technically spelled out all of the capabilities and features
>>>> of these methodology templates, although I believe MichaelV has that on his
>>>> to-do list. I had given him some thoughts and materials in this space.
>>>>
>>>
>>> That would be nice to get ASAP.
>>>
>>>
>>>>
>>>> Hierarchy names: this should be defined by the work item type links,
>>>> which, in turn, should include forward and reverse names. Again, these get
>>>> added to the Space by the user-chosen methodology.
>>>>
>>>
>>> Yes of course they are, but what would you name them assuming you were
>>> the one naming them for a methodology?
>>>
>>>
>>>>
>>>>
>>>> On Mon, Jan 23, 2017 at 6:08 AM, 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
>>>
>>>
>> _______________________________________________
>> 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/20170125/b3416418/attachment.htm>