[almighty] modeling 'types' for planner work items

Wed Oct 5 06:19:08 UTC 2016

On 5 Oct 2016, at 8:07, Michael Kleinhenz wrote:

> 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.

Thats my thinking too - and one of those contexts could be "Backlog" as 
prioritised by product owner
but the context for iteration "Sprint #24" is the order setup by the 
team to execute.

Those contexts could also be boards - and could even go so far to let 
users viewing a board
choose which order context they want to see/manipulate.

That said I would also be annoyed having to reshuffle ranks everytime on 
every "context" a new issue comes in.
Thats visible when we add/remove issues on milestones in github and 
things "jump" around.

So it is not all perfect.

/max

>
> --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
>>
>>
>>

> _______________________________________________
> almighty-public mailing list
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public

/max
http://about.me/maxandersen