<div dir="ltr"><p dir="ltr">I would think that. I would model that like a context based ranking map. That would enable us to model any context-based ranking later. Think of "show only my tasks" and then a personal reordering.</p><p>--Michael</p>
<div class="gmail_extra"><br><div class="gmail_quote">Am 04.10.2016 2:32 nachm. schrieb "Leonard Dimaggio" <<a href="mailto:ldimaggi@redhat.com" target="_blank">ldimaggi@redhat.com</a>>:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Would the ranking exist in the context of a project/team? In other words, would we want one work item to simultaneously have multiple rankings, one for each project? <br><br></div>(That's a question and not necessarily a recommendation.)<br><br></div>-- Len<br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 4, 2016 at 2:35 AM, Michael Kleinhenz <span dir="ltr"><<a href="mailto:kleinhenz@redhat.com" target="_blank">kleinhenz@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Coming back to the ranking problem, I'll see the req for having<br>
"local" rankings. As Max said, we could have one WI in multiple team<br>
boards (the exact think that we would need right now :-) and I would<br>
suppose we should avoid having people start a "ranking position update<br>
war".<br>
<br>
I think this might cause some deep considerations for the data model<br>
in the core.<br>
<span><font color="#888888"><br>
-- Michael<br>
</font></span><div><div><br>
On Fri, Sep 30, 2016 at 11:44 PM, Alexey Kazakov <<a href="mailto:alkazako@redhat.com" target="_blank">alkazako@redhat.com</a>> wrote:<br>
><br>
><br>
> On 09/30/2016 06:35 AM, Todd Mancini wrote:<br>
>><br>
>> I'll go on the record as saying that I once helped create a system whereby<br>
>> child tasks could automatically update parent tasks -- for example: "all the<br>
>> children are done, so mark the parent as done."<br>
>><br>
>> It was a terrible, terrible mistake.<br>
>><br>
>> Yes, on paper, it looks like the right thing to do. In reality, reality is<br>
>> much, much different. For very strict, waterfall processes, it can sometimes<br>
>> work. But that assumes you've got a completely well-defined, repeatable and<br>
>> essentially unchanging process. (e.g. an assembly line or a process you<br>
>> manage with a Gantt chart). But, outside of that scope, it rarely works<br>
>> well.<br>
>><br>
>> e.g. consider a value prop broken down into experiences to be accomplished<br>
>> over the next 6 months. Assume all of the experiences are completed. Is the<br>
>> value prop now 'done/realized'? Maybe it is, but maybe it is not (or at<br>
>> least not fully). Maybe to fully realize the value prop requires three 6<br>
>> month seasons of experiences. In other words, just because I have 4 children<br>
>> now doesn't mean I won't have additional children later. The closing out of<br>
>> the value prop is really a human decision, not an algorithmic one.<br>
>><br>
>> Will some people want automatically closing parents? Probably. Should we<br>
>> have that as an option? Maybe, but not for Pizza the Hutt. Many, many<br>
>> popular systems are surviving without this feature and happy users. The<br>
>> unhappy ones can go use IBM DOORS or something like that. :)<br>
><br>
><br>
> I would say this option could be useful on a task level. Not a global one.<br>
> For example for some tasks automatically generated by the system and where<br>
> the list of subtasks is not supposed to change. For example in devstudio<br>
> when we release we generate a task to create a New and Noteworthy docs with<br>
> a bunch of subtasks per component. So when such system generated tasks are<br>
> closed it would be useful to have the parent task automatically closed too.<br>
> Not sure there is any use case for the Pizza the Hutt right now but it may<br>
> be useful in the future.<br>
><br>
> Thanks.<br>
><br>
><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>
<br>
<br>
</div></div><span>--<br>
Michael Kleinhenz<br>
Principal Software Engineer<br>
<br>
Red Hat Deutschland GmbH<br>
Werner-von-Siemens-Ring 14<br>
85630 Grasbrunn<br>
Germany<br>
<br>
RED HAT | TRIED. TESTED. TRUSTED.<br>
Red Hat GmbH, <a href="http://www.de.redhat.com" rel="noreferrer" target="_blank">www.de.redhat.com</a>,<br>
Registered seat: Grasbrunn, Commercial register: Amtsgericht München,<br>
HRB 153243,<br>
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,<br>
Michael O'Neill<br>
<br>
</span><div><div>______________________________<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>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Len DiMaggio (<a href="mailto:ldimaggi@redhat.com" target="_blank">ldimaggi@redhat.com</a>)<br>JBoss by Red Hat<br>314 Littleton Road<br>Westford, MA 01886  USA<br>tel:  <a href="tel:978.392.3179" value="+19783923179" target="_blank">978.392.3179</a><br>cell: <a href="tel:781.472.9912" value="+17814729912" target="_blank">781.472.9912</a><br><a href="http://www.redhat.com" target="_blank">http://www.redhat.com</a><br><a href="http://community.jboss.org/people/ldimaggio" target="_blank">http://community.jboss.org/peo<wbr>ple/ldimaggio</a><br><br><img src="http://www.redhat.com/g/logos/RedHat_JBoss_logo.png"><br></div></div></div></div>
</div>
</blockquote></div></div>
</div>