<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8"> </head> <body> <div style="font-family:sans-serif"><div style="white-space:normal"> On 26 Sep 2016, at 9:47, Thomas Mäder wrote: <blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"> Hi folks, I think the question how to represent iterations hinges on whether iterations are an extension or an intrinsic concept. </blockquote> I see iterations as intrinsic - they are the "thing" used to model any kind of repeated steps in any development process wether agile, waterfall or something in future. <blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"> If we expect to have different kinds of "iterations" with different properties, they should be represented as WIT's (or something similar). If we intend to have a predefined, fixed set of iteration objects, we should model them explicitly. </blockquote> Yes, they could eventually grow into be generically defined but I think to start with we could start very basic - I for one do not think they should be munged into being work item/work item types at our API level. Not everything is a java.lang.Object either ;) <blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"> Max, I suspect the fear you have is that the work item types degenerate to a simple hashmap and that all the business logic will end up in the client. However, I maintain that clients will know certain types of work items (Bug, Story) and will hard-code against them. </blockquote> I think I agree with you, but I fear if you think clients are going to hard code against the level of "Bug" and "Story" then I think we failed and made the workitem API's too diluted and too generic. <blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"> On the other hand, modeling iterations as work item types gives us a range of nice opportunities for reuse, I try to highlight them below: /Thomas On 09/23/2016 04:23 PM, Max Rydahl Andersen wrote: <blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"> That said - I agree that things like iterations and other data that are used for grouping/categorizing should be as nice and light to use. Nothing worse having to do several clicks to just put something in a specific bucket when it could be done by typing a label/version/iteration etc. and have it created on the fly. </blockquote> We may still implement this in a light way: just creating an iteration work item in the background if none exists. </blockquote> Yes, that is what I mean - we can have a pretty rich model behind but still make it easy and lightweight to use. <blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"> If we decide that iterations are just labels, then let's treat them like labels: they will not be a concept in our system. </blockquote> Labels would be a useful concept in the system - even if just a simple name. Not following the logic here. <blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"> <blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"> My preference for anything use for categorisation/grouping is to allow defining strictly hierarchical taxonomies via a path like structure. </blockquote> +1 on that. But what I would do is to generalize the concept of "containment" as a flag on a relationship between work items. This would in one fell swoop take care of all kinds of containment hierarchies. We can query subtrees easily be materializing the "parent" field as a parent path. So containment of "areas" in "components" is really just the same as containment of stories in an epic. This will also take care of having arbitrary depth containment and multiple containment hierarchies, something that is lacking in Jira, for example. </blockquote> I agree on the power of this and this is why I suggested generalising it - but I do feel we are overdoing it if we end up representing everything as the same thing (i.e. iterations, labels, components are all considered work items). <blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"> <blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"> Same for areas/components/labels could be useful as hierarchies that can be created on the fly or if a project chooses "locked" down. </blockquote> I don't understand the "locked down" part and how it pertains to the issue. </blockquote> i.e. git does not allow everyone to add lables, jira does not allow everyone to add components - these are "locked" down. jira does allow everyone to add labels - they are not locked down. <blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"> <blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"> Now writing through these one could maybe just have a "Categorisation type" and "Categorisation" and say work items can have fields of type "Categorization". i.e. Areas, Components, Labels, Iterations, ... And these have name, (optional) description, (optional) time frame (start/stop). </blockquote> -> that's a work item in anything but name, no? </blockquote> Just like everything is a hash map :) I see this more as they share a lot of the same traits, but they are not the same thing. /max <a href="http://about.me/maxandersen" style="color:#3983C4">http://about.me/maxandersen</a> </div> </div> </body> </html>