Create a link between WorkItems #69
Comments
|
Shouldn't that be "..create and display.."? |
|
@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 Which are next in the priority order? |
|
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. |
|
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. |
|
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? |
|
We can start with the most common use case from an Agile perspective.
2. Association
I'm not sure where work item type 'bug' would fit :) |
|
@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. |
|
+1 A many-to-many relationship. We will also want to see this type of -- Len On Mon, Sep 12, 2016 at 12:53 PM, Nimisha notifications@github.com wrote:
Len DiMaggio (ldimaggi@redhat.com) |
|
@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 ? |
|
@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:
@maxandersen am I understanding this or can you translate for me? |
|
-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... |
what do you see many-to-many relationship does that is not possible with associations ? |
|
+1 on the many to many scenario to start with. On Tue, Sep 13, 2016 at 12:34 PM, Michael notifications@github.com wrote:
|
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 ? |
|
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 :-) |
|
Follow up to Max's followup - the association model sounds find. What I am
-- Len On Tue, Sep 20, 2016 at 1:23 AM, Max Rydahl Andersen <
Len DiMaggio (ldimaggi@redhat.com) |
|
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. |
|
@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. |
|
@joshuawilson maybe we are using different terminology here :) They are all the same basic links used to model many to many, right? |
|
@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. |
|
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. |
|
@Mgranfie That would be a Backend feature, not a UI feature. And it should be it's own Story. |
|
@Mgranfie the intelligent or auto-linking is a separate story imo. |
Update readme issue 34
We need some way to visually link in a parent / child way workitems.
Experience 1603E131
A user with appropriate privileges obtains a definition file (for example via a web interface or a command line), edits the definition file which describes a work item link type between two work item types, and, associates it with the project (for example by uploading it via a web browser or using the command line). A default definition file is provided out of the box, and can be modified via this process.. Each link type must describe both the forward and reverse relationship (e.g. Parent/Child, Successor/Predecessor, Tested By/Tests, etc.) and also must also be one of four topologies: Network (undirected; circular relationships possible); Directed Network (directed; circular relationships possible); Dependency (directed; circular relationships prohibited); Tree (directed; circular relationships prohibited; one-to-many).
-- this is not end-user functionality for Pizza the Hutt.
The text was updated successfully, but these errors were encountered: