On 19/10/12 12:11, Joachim Dreimann wrote:
On 18 Oct 2012, at 21:35, Gary Martin <[email protected]> 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
