[almighty] modeling 'types' for planner work items

[Michael Kleinhenz]

@ranjith so you mean there should be some sort of business process
management in place that could automates some tasks like moving
dependend WIs around, creating new WIs based on certain conditions
etc?
If that's what you mean, then I think that would be an advanced
feature and definitely useful. I talked to Todd some weeks ago about a
similar proposal. Such a feature would have some very interesting
applications. Like "schedule a security review task every second
sprint" or "if there is a CERT warning on a library that the project
has in it's dependencies, automatically add a task to check on it". I
would imagine such a feature would be located somewhere along the KPI
or monitoring stuff, because these would also require some level of
automation based on WIs.

That's an interesting discussion. Although I think it's not in the
scope of implementation for the next 6 months.

-- Michael

On Thu, Sep 29, 2016 at 9:05 AM, Max Rydahl Andersen
<manderse at redhat.com> wrote:
>
>> Assuming that ‘fundamentals’, ‘value propositions’ and ‘experiences' will
>> exist as part of the backlog. As the experiences get converted to epics,
>> user stories and these user stories move to completion (visualizing it as
>> a
>> Kanban board), we will need to come up with a mechanism to move the
>> associated ‘fundamentals’, ‘value propositions’ and ‘experiences' of of
>> the
>> backlog as well. As we should only have unfinished work as part of the
>> backlog.
>>
>> Since the behavior of some of these types of work items will be different,
>> do we need to build in logic associated with ‘type’ of work item? For
>> example would ‘value propositions’ or ‘experiences’ have a state
>> associated? If yes, would it  get incrementally updated along with each of
>> child work item?
>
>
> Yes, work items have a state - but what is the incremental updated you refer
> to ?
>
> Do you mean to be able to see the progress ? Then I would reckon that is
> best shown
> by visualising the parent/child relationships - i.e. 4 out of 10
> "child"/contained-tasks
> are done.
>
> That would work well for experiences especially.
>
> For ever running things like Fundamentals I don't follow why you would see
> those ever getting
> removed from "a board" or even backlog.
>
> They are inherently always there and not really in the backlog - but used
> for categorising the
> items in the backlog.
>
> /max
> http://about.me/maxandersen
>
> _______________________________________________
> 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