[almighty] modeling 'types' for planner work items

[Leonard Dimaggio]

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/20161004/48c076e4/attachment.htm>