Create a link between WorkItems about fabric8-planner HOT 23 CLOSED

Shouldn't that be "..create and display.."?

from fabric8-planner.

@joshuawilson @maxandersen @aslakknutsen @michaelvirgil @mindreeper2420 We need to decide which one of these scenarios has priority, so that we can focus and design on one of these during our next sprint. Which of the following would you rate as priority and why?

*Network
*Directed Network
*Dependency

Which are next in the priority order?

from fabric8-planner.

At this time, I would just go for Network only. Multiple parents, multiple childs, not directed, with a label as the relation definition. Something like "these are the parents with that relation label each" and "these are the childs with that relation label each". There are some caveats, like the label mapping. We'll discuss this this week hopefully.

from fabric8-planner.

Directed or not makes imho no difference for the ux at this time. Should be only a thing with the normalizing of the graph data.

from fabric8-planner.

The decision on what we support directly impacts the UI and what and how we surface this information. Once decided on which relationships to support to start, we can explore how to surface them to the use in the interface. @maxandersen has mentioned starting with what sounded like singular directional links, which may support what you are suggesting?

from fabric8-planner.

We can start with the most common use case from an Agile perspective.
1. Parent-child link between work items

• A Feature (parent) can have multiple User Stories (children). We have work items Feature and User Story (http://demo.almighty.io/#/work-item-list)
• A User Story (parent) can have multiple sub stories/tasks (children). We do NOT have work item task type currently.

2. Association

• One user story depends on another user story
• One (many) user story is blocked by one (many) user story

I'm not sure where work item type 'bug' would fit :)

from fabric8-planner.

@maxandersen Please confirm that we are only showing links as a list of items, at this time in the UI. UI to support the graphs as mentioned above, have not prioritized or vetted for requirements just yet. "Relates to", as simple links was what I think Max suggested... as where to start.

from fabric8-planner.

+1

A many-to-many relationship. We will also want to see this type of
relationship when we start tracing requirements. It's a frequent case that
you want to trace requirements to tests in a many-to-many relationship.

-- Len

On Mon, Sep 12, 2016 at 12:53 PM, Nimisha [email protected] wrote:

We can start with the most common use case from an Agile perspective.
1. Parent-child link between work items

• A Feature (parent) can have multiple User Stories (children). We
  have work items Feature and User Story (http://demo.almighty.io/#/
  work-item-list)
• A User Story (parent) can have multiple sub stories/tasks
  (children). We do NOT have work item task type currently.

2. Association

• One user story depends on another user story
• One (many) user story is blocked by one (many) user story

I'm not sure where work item type 'bug' would fit :)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#69 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAnOPeU_4BLMOzQ8HrG5BEjIUtNSVim5ks5qpYNsgaJpZM4J26hz
.

Len DiMaggio ([email protected])
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

from fabric8-planner.

@ldimaggi many-to-many is what a simple association will allow.

And I agree with @nimishamukherjee that parent/child and association will cover most usecases. Doing assoications first at UI level in lets say next sprint sounds fine to me, and then in future sprints we can look at how hiearchies (parent/child) will be handled.

Would that work for you @Mgranfie ?

from fabric8-planner.

@maxandersen @nimishamukherjee yes this sounds like a good starting point, as far as keeping the relationships simple and just parent/child.

Doing associations first at UI level in lets say next sprint sounds fine to me, and then in future sprints we can look at how hierarchies (parent/child) will be handled.

Translates to requirements as:

• First deliverable for ( ? date) will be the back end support, no UI
• In future sprint will surface in the UI as a parent/child relationship only

@maxandersen am I understanding this or can you translate for me?

from fabric8-planner.

+1 @nimishamukherjee

-1 There are too many open questions with associations (many-2-many).

+1 Hierarchical, parent/child (initiative, Epic, story) relationships are well structured, common approach in agile planning and well understood. Simplest use case, easy to extend.

Anyone managing or working through a backlog understands the relationships and it provides context for the team. Parent/child is a very specific association. More general associations would be a natural next step.

I would recommend following the progression @nimishamukherjee suggested - simpler path and the first pass of the design/development will be on the main success scenario...

from fabric8-planner.

A many-to-many relationship. We will also want to see this type of
relationship when we start tracing requirements. It's a frequent case that
you want to trace requirements to tests in a many-to-many relationship.

what do you see many-to-many relationship does that is not possible with associations ?

from fabric8-planner.

+1 on the many to many scenario to start with.

On Tue, Sep 13, 2016 at 12:34 PM, Michael [email protected] wrote:

+1 @nimishamukherjee https://github.com/nimishamukherjee

-1 There are too many open questions with associations (many-2-many).

+1 Hierarchical, parent/child (initiative, Epic, story) relationships are
well structured, common approach in agile planning and well understood.
Simplest use case, easy to extend.

Anyone managing or working through a backlog understands the relationships
and it provides context for the team. Parent/child is a very specific
association. More general associations would be a natural next step.

I would recommend following the progression @nimishamukherjee
https://github.com/nimishamukherjee suggested - simpler path and the
first pass of the design/development will be on the main success scenario...

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#69 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ARTwq9cwxfh5BZti3mMWwxLYYhVvxRbcks5qptB5gaJpZM4J26hz
.

from fabric8-planner.

+1 on the many to many scenario to start with.

what does that mean ? that you want many-to-many included from the start ?

if yes, then I have same question as I had to @ldimaggi, what is a many-to-many doing that cannot be done with associations ?

from fabric8-planner.

Whatever model we choose for the start, we should try to do it that it also serves as a base for the 6 month goal (meaning "designed that we don't have to throw most of the ui code away after 2 sprints to rework it to something completely different"). Therefore, I think it is important to understand where we are headed and not only what we want now. This is a special case where we should really do that! The visualization/implementation of the links is complex on the tech and UX side.

For this special area, I would design the final 6 month scenario and then "dumb it down" to the current goal. I would also expect the UX design will generate questions and req's for the core model implementation this way ("oh, while we did the UX, we encountered needs for this or that metadata.."). UX first :-)

from fabric8-planner.

Follow up to Max's followup - the association model sounds find. What I am
trying to do here is to solve the problem of linking tests to requirements

• this has been a problem for RH QE for a long time, so I expect that
  customers are probably having the same problem too.

-- Len

On Tue, Sep 20, 2016 at 1:23 AM, Max Rydahl Andersen <
[email protected]> wrote:

+1 on the many to many scenario to start with.

what does that mean ? that you want many-to-many included from the start ?

if yes, then I have same question as I had to @ldimaggi
https://github.com/ldimaggi, what is a many-to-many doing that cannot
be done with associations ?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#69 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAnOPXuq9uC5bD-5i5-RbZYDd2loIzOYks5qr23pgaJpZM4J26hz
.

Len DiMaggio ([email protected])
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

from fabric8-planner.

so what I read is noone can come up with a reason for why many-to-many is needed.

That associations with a type/direction is sufficient since that can then be used to visualize the links as necessary.

from fabric8-planner.

@maxandersen a many-to-many is easy to prove. A Value Prop can have many Experiences. An Experience can belong to many Value Props.

A WorkItem has a recursive many-to-many relation.

from fabric8-planner.

@joshuawilson maybe we are using different terminology here :)

They are all the same basic links used to model many to many, right?

from fabric8-planner.

@joshuawilson @maxandersen @michaelvirgil checking to see if there has been any consensus on this? If so can we nail down the requirements and rewrite the story around this? This way, I can either grab it off the backlog, potentially this sprint, or it will be ready to go next week for us... let me know.. thanks.

from fabric8-planner.

There were discussions on Friday with @joshuawilson @aslakknutsen about having intelligent links. If a work item is referenced in a chat or a comment, a link can automatically be created on the issue that is referenced.

from fabric8-planner.

@Mgranfie That would be a Backend feature, not a UI feature. And it should be it's own Story.

from fabric8-planner.

@Mgranfie the intelligent or auto-linking is a separate story imo.

from fabric8-planner.