<div dir="ltr">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.</div><div class="gmail_extra"><br><div class="gmail_quote">On 25 January 2017 at 09:54, Pete Muir <span dir="ltr"><<a href="mailto:pmuir@redhat.com" target="_blank">pmuir@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On 24 January 2017 at 16:56, Max Rydahl Andersen <span dir="ltr"><<a href="mailto:manderse@redhat.com" target="_blank">manderse@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><div style="direction:inherit"><br></div><br>/</div><span><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><span>On Mon, Jan 23, 2017 at 1:39 PM, Todd Mancini <span dir="ltr"><<a href="mailto:tmancini@redhat.com" target="_blank">tmancini@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Epics are not 'special'. There are a work item type like any other.</div></blockquote><div><br></div></span><div>I know they are not 'special' in the sense of WIT, but they are 'special' in the sense of the Planner/Process. </div><div><br></div><div>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?</div></div></div></div></blockquote><div><br></div><div>I think of it as the root work item type in the tree of work item type parent-child relationships.</div><div><br></div><div>That's quite verbose, so I would suggest shortening to something like "root work item type".</div><div> </div></div></div></div></div></blockquote><div style="direction:inherit"><br></div></span><div style="direction:inherit"><div style="direction:inherit"><span style="background-color:rgba(255,255,255,0)">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.</span></div><div style="direction:inherit"><span style="background-color:rgba(255,255,255,0)"><br></span></div><div style="direction:inherit"><span style="background-color:rgba(255,255,255,0)">Here there will be either one root (Vision) very high up or two roots Vision and Epic.</span></div><div style="direction:inherit"><span style="background-color:rgba(255,255,255,0)"><br></span></div><div style="direction:inherit">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....</div></div></div></blockquote><div><br></div></span><div>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.</div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div style="direction:inherit"><span class="m_-8660551132573047530HOEnZb"><font color="#888888"><div style="direction:inherit"><br></div><div style="direction:inherit">/max</div></font></span></div><div><div class="m_-8660551132573047530h5"><div style="direction:inherit"><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>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.</div><div><br></div><div>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?)</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div></blockquote><div><br></div></span><div>That would be nice to get ASAP.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>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.</div></div></blockquote><div><br></div></span><div>Yes of course they are, but what would you name them assuming you were the one naming them for a methodology?</div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div></div><div class="m_-8660551132573047530m_-678812684175120576m_-6664446188193226054HOEnZb"><div class="m_-8660551132573047530m_-678812684175120576m_-6664446188193226054h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 23, 2017 at 6:08 AM, Aslak Knutsen <span dir="ltr"><<a href="mailto:aslak@redhat.com" target="_blank">aslak@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">A few points to clear up around the generic type system.<div><br></div><div>'Epic'</div><div><br></div><div>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: <a href="https://redhat.invisionapp.com/share/QU9U8D8GF#/screens/212141138" target="_blank">https://redhat.invisiona<wbr>pp.com/share/QU9U8D8GF#/screen<wbr>s/212141138</a></div><div><br></div><div>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?</div><div><br></div><div>Part of <a href="https://github.com/fabric8io/fabric8-planner/issues/657" target="_blank">https://github.com/fabric8i<wbr>o/fabric8-planner/issues/657</a></div><div><br></div><div><br></div><div><div>'WorkItem Links hierarchy'</div><div><br></div><div>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?</div><div><br></div><div>Relates to? Belongs to? Child of? Part of?</div></div><div><br></div><div><br></div><div>'Quick Add'</div><div><br></div><div>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.</div><div><br></div><div>Should the Process Definition have some option to define a 'default' Type that should be used here?</div><div>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?</div><div><br></div><div><br></div><div><br></div><div>PM's input appreciated. </div><span class="m_-8660551132573047530m_-678812684175120576m_-6664446188193226054m_-8854552438448067634HOEnZb"><font color="#888888"><div><br></div><div><br></div><div>-aslak-</div><div><br></div></font></span></div>
</blockquote></div><br></div>
</div></div></blockquote></span></div><br></div></div>
<br>______________________________<wbr>_________________<br>
almighty-public mailing list<br>
<a href="mailto:almighty-public@redhat.com" target="_blank">almighty-public@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/almighty-public" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/almighty-public</a><br>
<br></blockquote></div><br></div></div>
</div></blockquote><blockquote type="cite"><div><span>______________________________<wbr>_________________</span><br><span>almighty-public mailing list</span><br><span><a href="mailto:almighty-public@redhat.com" target="_blank">almighty-public@redhat.com</a></span><br><span><a href="https://www.redhat.com/mailman/listinfo/almighty-public" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/almighty-public</a></span><br></div></blockquote></div></div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>