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: ticket associated with multiple versions (Was: Re: [Apache Bloodhound] #234: Quick Ticket: link to /newticket, description and priority)
Date Thu, 25 Oct 2012 09:33:49 GMT
On Wed, Oct 24, 2012 at 1:25 PM, Gary Martin <gary.martin@wandisco.com>wrote:

> 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 need to clarify. I was not trying to say that multiversion is only for
defects but that differentiation between affects and fixes version fileds
(both multiselect) apply to defects only. But you may be right and it would
be unwise to impose different behavior based on ticket type.


>
> 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.
>

Not sure I follow you here. Not required as not required for user to eneter
or not required as not needed to implement? Both are needed
to differentiate the version in which some bug appears vs. the version in
which the bug is fixed. From the ticket
workflow/resolution perspective, the "fix versions" field is the one that
it matters (and that is the current Trac's version field). That is why I
was suggesting that the "affected" field applies mostly to defects.


>
> 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.
>

Requirement nr.4 does just that and can be added on it's own even if don't
do anything else. However it is a heavyweight solution that brings a new
set of problems that can be avoided when a lightweight (nr. 1,2 and 3)
solution would do (please keep in mind that at least theoretically this
first three points can be implemented on top of ticket relations as well,
wether that would be sensible I would doubt it). I have already marked nr.
5 as a nice-to-have anyway.


>
> Cheers,
>     Gary
>

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