[almighty] Clarification around Types

[Pete Muir]

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/2545317c/attachment.htm>