[almighty] modeling 'types' for planner work items

Wed Oct 5 06:07:35 UTC 2016

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.

--Michael

Am 04.10.2016 2:32 nachm. schrieb "Leonard Dimaggio" <ldimaggi at redhat.com>:

> 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?
>
> (That's a question and not necessarily a recommendation.)
>
> -- Len
>
>
>
> On Tue, Oct 4, 2016 at 2:35 AM, Michael Kleinhenz <kleinhenz at redhat.com>
> wrote:
>
>> 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
>>
>> _______________________________________________
>> almighty-public mailing list
>> almighty-public at redhat.com
>> https://www.redhat.com/mailman/listinfo/almighty-public
>>
>
>
>
> --
> Len DiMaggio (ldimaggi at redhat.com)
> JBoss by Red Hat
> 314 Littleton Road
> Westford, MA 01886  USA
> tel:  978.392.3179
> cell: 781.472.9912
> http://www.redhat.com
> http://community.jboss.org/people/ldimaggio
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20161005/1997c7d5/attachment.htm>