incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <gary.mar...@wandisco.com>
Subject Re: ticket associated with multiple versions (Was: Re: [Apache Bloodhound] #234: Quick Ticket: link to /newticket, description and priority)
Date Fri, 19 Oct 2012 13:16:57 GMT
On 19/10/12 12:11, Joachim Dreimann wrote:
> On 18 Oct 2012, at 21:35, Gary Martin <gary.martin@wandisco.com> wrote:
>
>> I had considered that but you would probably have to list out tasks within a ticket
to cover per task workflow, wouldn't you?
> I don't believe there should be a per task workflow. It should be a ticket if it's big
enough to need a workflow.

I agree with that entirely. In addition I think it is generally better 
to be able to state that the work associated with a particular version 
is complete with the closure of a ticket having gone through the 
workflow that the project specifies.

I think the idea of ticket substructure can probably work well but I am 
wary of using it for this purpose which may encourage users to shortcut 
local policy.

>
>> This is why I was thinking of making use of structure around tickets for relationships
that we are going to support anyway.
>>
>> Also, are we expecting that users might sometimes create tickets separately that
should be joined by a multi version relationship? Would you pull them into a single ticket
and mark the others as invalid?
> That should be entirely up to the user.

.. or local normal procedures, and I think we may want to help them with 
either choice.

>
>> Can we envisage a way of having a ticket like interface to summarise a set of related
tickets?
> We have a few of these already: Products, Versions, Milestones. They are like tickets
in some ways, but their main purpose is to group tickets. We could introduce kilometre-stones
for a smaller measureāø®
>
> - Joe

If I were just talking about displaying a list of tickets, that would be 
easy - we will eventually be able to provide a way to construct a query 
which would show these specific relationships in a dashboard like 
focused view, but this is not really what I am talking about.

Essentially tickets with ticket relations specified might be considered 
to have common conversations, particularly in a master ticket which, it 
might be argued, is worth displaying on subtickets of a given relation 
type. You could also argue that it might be worth allowing the master 
ticket of a relation to be expandable to show the subticket data in some 
way.

The alternative I was suggesting before was more about allowing tickets 
to remain simpler whilst being able to get a view of the conversation 
and progress.

Before doing that I would suggest that as a minimum we probably need 
ticket queries on the relations to be provided automatically in the 
ticket, along with the related ticket events to be shown in the activity 
feed.

Cheers,
     Gary

Mime
View raw message