[almighty] Idea: modelling iterations

[Max Rydahl Andersen]

On 26 Sep 2016, at 9:47, Thomas Mäder wrote:

> Hi folks,
>
> I think the question how to represent iterations hinges on whether 
> iterations are an extension or an intrinsic concept.

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.

> 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.

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 ;)

> 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.

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.

> 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.

Yes, that is what I mean - we can have a pretty rich model behind but 
still make it easy and lightweight to use.

> If we decide that iterations are just labels, then let's treat them 
> like labels: they will not be a concept in our system.

Labels would be a useful concept in the system - even if just a simple 
name. Not following the logic here.

>> 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.

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).

>> 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.

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.

>> 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?

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
http://about.me/maxandersen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20160926/aa4898ee/attachment.htm>