incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Koželj <pe...@digiverse.si>
Subject Re: [BEP-0003] Per product ticket workflow (Was: Re: [Apache Bloodhound] Proposals/BEP-0003 modified)
Date Wed, 14 Nov 2012 18:48:08 GMT
On 14 November 2012 17:47, Gary Martin <gary.martin@wandisco.com> wrote:

> On 14/11/12 15:45, Peter Koz(elj wrote:
>
>> +=== Per product ticket workflow
>>>
>>>> +Depending on the product, different ticket workflows should be
>>>> supported.
>>>> +
>>>>
>>>
> I should probably note that we can live with a single workflow in the
> short term so this may not be top priority. Saying that, it is still good
> for people to see where we are likely to be going I think.
>
>
>
>> 1. Not strictly a multiproduct  feature but we should keep in mind: At
>> some
>> point workflow should actually be per product and PER TICKET TYPE.
>>
>
> Yes, a bit off-topic. However..
>
> I have my doubts about per ticket type workflow but I do understand that
> it is something that people may well want. It could probably be achieved
> through ticket type dependent transitions so that there is some sharing of
> states and transitions. It should be remembered that tickets can change
> type and the types should be expected to be modified by users.
>
>
>  2. Most products will end up using the same workflow so this needs to be
>> optional feature
>>
>
> I completely agree although I might suggest taking it a small step
> further. If we get to the point where we are looking at supporting very
> large numbers of products, we might want something like this:
>
>  * a base workflow - for when a product does not specify a workflow for
>    itself
>  * product specific workflows - used when a product requires a unique
>    workflow definition that is not expected to be shared
>

yes, this is exactly what I had in mind, so +1


>  * named workflows - alternatives to the base workflow that are
>    potentially selectable for many products.. and perhaps the base
>    workflow could point to one of these by default
>

+1


>
> Cheers,
>     Gary
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message