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 Thu, 18 Oct 2012 20:35:24 GMT
I had considered that but you would probably have to list out tasks within a ticket to cover
per task workflow, wouldn't you? 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?

Can we envisage a way of having a ticket like interface to summarise a set of related tickets?

Perhaps we can't.. perhaps it is too difficult.. but having the ability to model relationships
suggests this kind of view to me anyway.

Cheers,
    Gary

Joe Dreimann <joachim.dreimann@wandisco.com> wrote:

>Maybe this can be solved by having a smaller entity than a ticket?
>After all tickets have a lot of properties and are
>distinct/disconnected in the UI - for good reason, because they usually
>represent distinct issues.
>
>What if a Ticket could have a set of checkboxes within it? These
>wouldn't need any properties themselves, they could just list:
>
>[   ] Minor Task 1
>[   ] Minor Task 2
>[   ] Minor Task 3
>
>No matter the status of these the ticket could be closed, reopened,
>etc. They shouldn't add restrictions, just record small tasks that
>users otherwise would track outside Bloodhound.
>
>Pivotal Tracker and Trello use these to great effect for example.
>
>I expect this to be controversial, in fact I'm sitting on the
>proverbial sense myself.
>
>- Joe
>
>________________________
>@jdreimann - Twitter
>Sent from my phone
>
>On 18 Oct 2012, at 17:01, Peter Koželj <peter@digiverse.si> wrote:
>
>> On Thu, Oct 18, 2012 at 2:56 PM, Gary Martin
><gary.martin@wandisco.com>wrote:
>> 
>>> On 18/10/12 13:00, Peter Koželj wrote:
>>> 
>>>> On Thu, Oct 18, 2012 at 10:00 AM, Gary Martin
><gary.martin@wandisco.com>*
>>>> *wrote:
>>>> 
>>>> 
>>>>> "Peter Koželj" <peter@digiverse.si> wrote:
>>>>> 
>>>>> On Thu, Oct 18, 2012 at 5:19 AM, Olemis Lang <olemis@gmail.com>
>wrote:
>>>>>> 
>>>>>> On 10/17/12, Gary Martin <gary.martin@wandisco.com> wrote:
>>>>>>> 
>>>>>>>> On 17/10/12 17:15, Joe Dreimann wrote:
>>>>>>>> 
>>>>>>>>> On 17 Oct 2012, at 17:00, Peter Koželj <peter@digiverse.si>
>wrote:
>>>>>>>>> 
>>>>>>>>> On Wed, Oct 17, 2012 at 4:34 PM, Gary Martin
>>>>>>>>>> <gary.martin@wandisco.com>**wrote:
>>>>>>>>>> 
>>>>>>>>>> On 17/10/12 12:03, Ryan Ollos wrote:
>>>>>>>>>>> It gets interesting where really you want to
raise a bug
>against
>>>>>>>>>>> multiple
>>>>>>>>>>> versions but it is not the end of the world.
The main thing
>is
>>>>>>>>>> that
>>>>>> 
>>>>>>> there
>>>>>>>>>>> is a prompt for a primary version to raise against
- further
>>>>>>>>>> versions
>>>>>> 
>>>>>>> would
>>>>>>>>>>> probably be expected to be noted in the description
and
>those
>>>>>>>>>> dealing
>>>>>> 
>>>>>>> with
>>>>>>>>>>> the ticket could then determine whether further
tickets are
>>>>>>>>>> needed.
>>>>>> 
>>>>>>> I was just thinking about the multiple versions per ticket (bug)
>>>>>>>>>> support.
>>>>>>>>>> This needs to be formal and not just a in-comment
or
>>>>>>>>> in-description
>>>>>> 
>>>>>>> text.
>>>>>>> 
>>>>>>>> I
>>>>>>>>>> have some ideas how we could go about this but it
is off
>topic
>>>>>>>>> for this
>>>>>> 
>>>>>>> ticket. I'll start a separate discussion on the subject at some
>>>>>>>>> point
>>>>>> 
>>>>>>> in
>>>>>>> 
>>>>>>>> the fure (opening multiple unrelated tickets should be good
>>>>>>>>> enough at
>>>>>> 
>>>>>>> the
>>>>>>>>>> moment).
>>>>>>>>> The most obvious answer or me would be to allow to select
>multiple
>>>>>>>>> versions in the field, similar to how Multiple Select
works in
>the
>>>>>>>> Chosen
>>>>>>> 
>>>>>>>> plugin:
>>>>>>>>>
>http://harvesthq.github.com/**chosen/<http://harvesthq.github.com/chosen/>
>>>>>>>>> 
>>>>>>>>> - Joe
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> [...]
>>>>>>> 
>>>>>>>> In my case, I am not so much concerned with how it looks
as
>much as
>>>>>>> how
>>>>>> 
>>>>>>> it would be supported by the model. Depending on the way things
>>>>>>>> currently work, we might want to use a fresh field rather
than
>>>>>>> subvert
>>>>>> 
>>>>>>> the use of the current version field.
>>>>>>>> 
>>>>>>>> Two suggestions ...
>>>>>>> 
>>>>>>> 1. custom fields
>>>>>>> 2. keywords ... or something similar ;)
>>>>>>> 
>>>>>>> --
>>>>>>> Regards,
>>>>>>> 
>>>>>>> Olemis.
>>>>>>> 
>>>>>>> Blog ES: http://simelo-es.blogspot.com/
>>>>>>> Blog EN: http://simelo-en.blogspot.com/
>>>>>>> 
>>>>>>> Featured article:
>>>>>>> 
>>>>>>> Ticket needs to be resolved for each individual version
>separately. So
>>>>>> we
>>>>>> would need at least status per version.
>>>>>> And when the solutions for different versions must be different,
>one
>>>>>> would
>>>>>> also appreciate separate descriptions, comments... (but I am not
>sure
>>>>>> this
>>>>>> is common enough that it would warent special support).
>>>>>> 
>>>>>> We could stick to ticket per version (as what you have to do now)
>but
>>>>>> link
>>>>>> the tickets together with special relation type (when we have
>ticket
>>>>>> relations going). Basically what Gary is suggesting with
>subtickets but
>>>>>> build on top of the ticket relation concept (parent/child,
>duplicate,
>>>>>> version subticket,...) that we need to establish first.
>>>>>> 
>>>>>>> From the UI perspective, we could still allow for bulk create
of
>these
>>>>> 
>>>>>> tickets by selecting multiple versions in the version field and
>provide
>>>>>> the
>>>>>> user with ability of on overview of all the linked tickets.
>Again, also
>>>>>> built on top of ticket relations.
>>>>>> 
>>>>>> Personally I am still not decided whether I would rather see
>multiple
>>>>>> versions per ticket or version specific subtickets. But I do need
>the
>>>>>> ability to resolve them separately.
>>>>>> 
>>>>>> Peter
>>>>> For me it would have to be a user choice as to whether a multi
>version
>>>>> ticket should be split or treated as a single entity. In the
>latter case
>>>>> I
>>>>> would be happy with a single resolution.
>>>>> 
>>>>> Cheers,
>>>>>     Gary
>>>>> 
>>>>> 
>>>>> As we opened this discussion I have been thinking about this some
>more.
>>>> 
>>>> 1. Supporting per version comments, descriptions and attachments
>just does
>>>> not seem worth it. It would complicate things technically as well
>for the
>>>> user for very little benefit.
>>>> 
>>>> 2. Tickets are not necessarily resolved in the versions to which
>>>> they apply (bug for version 1.3 is resolved in 1.4, ticket planned
>for 1.4
>>>> is sliped to 1.5...). It becomes obvious that we need more then
>>>> one multiversion ticket field
>>>> 
>>>> 3. I still want to be able to plan and track progress. Versions are
>>>> essential here, so I need that resolution per version thing.
>>>>    Taking it all into account we would need 2 multiversion fields
>>>> (affected
>>>> and planned versions) and resolution per planned version:
>>>> 
>>>>   o A customer/tester will file a ticket about a bug that affects
>some
>>>> versions.
>>>>   o Project manager will make a plan in which versions a fix is
>necessary
>>>> (typically next planned release and a hot fix version for whatever
>>>> customer
>>>> is currently using)
>>>>   o Developers will resolve per version as a solution is being
>applied
>>>> across all the planned versions.
>>>> 
>>>> It seems that affected versions only apply to bugs and should be
>the same
>>>> as planned for other ticket types.
>>>> Ticket should be considered resolved only when all planned versions
>have
>>>> some kind of resolution. It can be the same for all versions or
>vastly
>>>> different.
>>>> 
>>>> I guess I am leaning toward the multiversion,multiresolution per
>ticket
>>>> approach. User can still use ticket relations if he has the need to
>split
>>>> the ticket into ticket/version.
>>>> 
>>>> Peter
>>> Clearly the way that the process works will be somewhat dependent on
>which
>>> versions remain supported. Equally it depends on the way that they
>work. A
>>> likely scenario is that a solution would first be created on trunk
>for
>>> future releases and the fix applied or adapted to other supported
>versions.
>>> 
>>> I think that multiresolution might be going a bit too far as it is
>not
>>> just multiresolution but multiple parallel workflow as a whole. I
>think it
>>> is better to model the process on multple tickets instead as the
>user
>>> benefits from all the per-ticket behaviour.
>>> 
>>> So, another alternative would be to see if we can create a combined
>ticket
>>> view for tickets in any relationship structure. The nice thing about
>this
>>> would that it could benefit more situations than just multiple
>versions.
>>> 
>>> Cheers,
>>>    Gary
>> 
>> Yeah, I was thinking the same way at first. But in 99.9% of cases
>having
>> descriptions, comments and attachments scattered across multiple
>tickets is
>> undesired. We would have to try really hard in the UI to prevent
>that. And
>> we manage to hide it, wat is the point of multiple tickets anyway?
>> 
>> I do not assume per version workflows with per version resolutions.
>Just a
>> constraint that would not allow for ticket to be closed until all
>planned
>> versions are resolved.
>> 
>> Anyway, I am still undecided about this.
>> 
>> Cheers,
>> Peter


Mime
View raw message