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 Wed, 24 Oct 2012 11:25:35 GMT
On 24/10/12 10:36, Peter Koželj wrote:
> On Fri, Oct 19, 2012 at 3:16 PM, Gary Martin <gary.martin@wandisco.com>wrote:
>
>> 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
>>
>
> We should split this discussion into two steps. We should form some kind of
> requirements first and only then discuss the implementation (multi version
> per ticket vs. ticket per version).
>
> I tried to sleep this over and than I questioned some of the colleges how
> would they use such a thing and than I tried to sleep it over again :)
>
> So this are my revisited guidelines that should drive multiversion
> requirements:
> a) Adding the multiversion support should not complicate things for cases
> where there is only a single or no version at all.
> b) The basic multiversion functionality should be as streamlined as
> possible and should deviate from the single version case as little as
> possible while still adding some value. Any part of the multiversion
> feature that would hurt usability (editing, searching, reports,
> notifications...) needs to be optional to the user and left for the user's
> project policy do dictate wether or how it should be used or not.
>
>
> Requirements:
>
> 1. Affects version field [MUST]
>
> User should be able to specify multiple versions to which the ticket
> applies to. That is, a versions in which the bug appears in and not the
> versions in which it will be fixed.
>
> For non-bug tickets this field has no meaning and it should not be
> available to the user. For all logic the value of the field should be
> derived directly from fix versions.
>
> Search can be done by "affects" field or by "version" field where "version"
> is union of "affects" and "fix" fields.
>
> This is essential functionality and it does not hurt the usability.
>
> 2. Fix version field [MUST]
>
> User decides in which versions the ticket should be resolved.
> This needs to be as simple as checking multiple versions in multiselect
> field.
>
> 3. Ticket data, workflow and search [MUST]
>
> All data (description, comments, attachements, standar and custom fields,
> status and resolution) are by default NOT version specific. It menas that
> they apply to all specified versions and there is no version specific
> workflow
>
> Search can be done by "affects" and "fix" field like it does now over
> version field. Search by "version" field should be changed to act like a
> union of "affects" and "fix" fields.
>
> 4. Version specific data and workflow [NICE TO HAVE]
>
> This should only be available when user requests it specifically (by
> following special recipe for creating version specific tickets). UI and
> search support for this can be very limited as cases that require version
> specific data and workflow are normally very rare and are usually taken
> care off by creating multiple unrelated tickets anyway.
>
> 5. Version specific resolution and verification [NICE TO HAVE]
>
> If user so chooses he should be able to track version specific resolutions
> and verifications. This should only be available if users marks the ticket
> as such and must not interfere with usability when not selected. This does
> not change the ticket workflow, it only gives the ability to enter version
> specific resolution and verification.
>
> As the ticket workflow and versions are not directly tied to the per
> version resolutions, search functions as is. The usefulness of version
> specific resolutions would benefit from search extensions that allows
> versions search narrowing by specifying that one is only interested in
> opened/resolved/verified versions.
>
> Additionally a strict mode can be offered that would not allow for ticket
> to be closed until all versions are resolved beforehand.
>
> --
>
> Now which of these do we want to implement and how is another metter
> entirely...
> Point 1 needs to be solved in-ticket. I would also take that approach for
> everything else except number 4 which has ticket relations written all over
> it, but would not provide any special support on top of relations at the
> beginning.
>
> Peter
>

Well, I immediately do not like the idea that we must make a distinction 
between ticket types. This is before looking at the technical difficulty 
of actually telling the difference between a bug tickets and another 
sort (or even what happens when it changes between ticket types). Who 
are we to say that this functionality is only available and useful for 
defects? Why can't a task or an enhancement be something that we want to 
perform on multiple versions? Whilst we might expect that it is most 
likely to be used for defects, I don't think that such a distinction is 
helpful.

I note that a fix version field would not be required in a multi-ticket 
approach as any version that should not be covered would either not be 
created or would be closed as wont-fix or similar.

For me, if the problem is small enough to deal with within a single 
ticket then there is relatively little reason for the support that all 
this gives. If there is a lot of work with a fix to be created and 
careful porting of fixes back to other versions, along with any code 
review and testing that implies, then these are better off as separate 
tickets, linked by a relationship. Independent scheduling of the porting 
work would seem to be important, for instance, which implies that it 
should be possible to set each version to be ported to a milestone 
independently, which itself is likely to be set based on a priority field.

At the moment I am really struggling to see this feature as being useful 
enough to spend time developing such a comprehensive solution. To me 
there does not seem to be enough value in it when we could look at 
providing enhancements that are more generic to all relationships instead.

Cheers,
     Gary

Mime
View raw message