[almighty] modeling 'types' for planner work items

[Michael Kleinhenz]

Coming back to the ranking problem, I'll see the req for having
"local" rankings. As Max said, we could have one WI in multiple team
boards (the exact think that we would need right now :-) and I would
suppose we should avoid having people start a "ranking position update
war".

I think this might cause some deep considerations for the data model
in the core.

-- Michael

On Fri, Sep 30, 2016 at 11:44 PM, Alexey Kazakov <alkazako at redhat.com> wrote:
>
>
> On 09/30/2016 06:35 AM, Todd Mancini wrote:
>>
>> I'll go on the record as saying that I once helped create a system whereby
>> child tasks could automatically update parent tasks -- for example: "all the
>> children are done, so mark the parent as done."
>>
>> It was a terrible, terrible mistake.
>>
>> Yes, on paper, it looks like the right thing to do. In reality, reality is
>> much, much different. For very strict, waterfall processes, it can sometimes
>> work. But that assumes you've got a completely well-defined, repeatable and
>> essentially unchanging process. (e.g. an assembly line or a process you
>> manage with a Gantt chart). But, outside of that scope, it rarely works
>> well.
>>
>> e.g. consider a value prop broken down into experiences to be accomplished
>> over the next 6 months. Assume all of the experiences are completed. Is the
>> value prop now 'done/realized'? Maybe it is, but maybe it is not (or at
>> least not fully). Maybe to fully realize the value prop requires three 6
>> month seasons of experiences. In other words, just because I have 4 children
>> now doesn't mean I won't have additional children later. The closing out of
>> the value prop is really a human decision, not an algorithmic one.
>>
>> Will some people want automatically closing parents? Probably. Should we
>> have that as an option? Maybe, but not for Pizza the Hutt. Many, many
>> popular systems are surviving without this feature and happy users. The
>> unhappy ones can go use IBM DOORS or something like that. :)
>
>
> I would say this option could be useful on a task level. Not a global one.
> For example for some tasks automatically generated by the system and where
> the list of subtasks is not supposed to change. For example in devstudio
> when we release we generate a task to create a New and Noteworthy docs with
> a bunch of subtasks per component. So when such system generated tasks are
> closed it would be useful to have the parent task automatically closed too.
> Not sure there is any use case for the Pizza the Hutt right now but it may
> be useful in the future.
>
> Thanks.
>
>
> _______________________________________________
> almighty-public mailing list
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public



-- 
Michael Kleinhenz
Principal Software Engineer

Red Hat Deutschland GmbH
Werner-von-Siemens-Ring 14
85630 Grasbrunn
Germany

RED HAT | TRIED. TESTED. TRUSTED.
Red Hat GmbH, www.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht München,
HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
Michael O'Neill