[almighty] Idea: modelling iterations

[Thomas Mäder]

Hi folks,

I think the question how to represent iterations hinges on whether 
iterations are an extension or an intrinsic concept. 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.

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.

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:
> 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.
We may still implement this in a light way: just creating an iteration 
work item in the background if none exists. If we decide that iterations 
are just labels, then let's treat them like labels: they will not be a 
concept in our system.
>
> My preference for anything use for categorisation/grouping is to
> allow defining strictly hierarchical taxonomies via a path like 
> structure.
+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.
> Same for areas/components/labels could be useful as hierarchies that 
> can be created on the fly
> or if a project chooses "locked" down.
I don't understand the "locked down" part and how it pertains to the issue.
> 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).
-> that's a work item in anything but name, no?