You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Gary Martin <ga...@wandisco.com> on 2012/10/16 13:44:33 UTC
Re: [Apache Bloodhound] #234: Quick Ticket: link to /newticket, description
and priority
On 16/10/12 12:26, Peter Koželj wrote:
> On Tue, Oct 16, 2012 at 12:33 PM, Apache Bloodhound <
> bloodhound-dev@incubator.apache.org> wrote:
>
>> #234: Quick Ticket: link to /newticket, description and priority
>> --------------------------+---------------------
>> Reporter: jdreimann | Owner: nobody
>> Type: enhancement | Status: new
>> Priority: major | Milestone:
>> Component: ui design | Version:
>> Resolution: | Keywords: starter
>> --------------------------+---------------------
>> Changes (by jdreimann):
>>
>> * keywords: => starter
>>
>>
>> Old description:
>>
>>> ,, ... via ''Bloodhound'' quick create ticket dialog,,
>> New description:
>>
>> 1. Currently the text {{{Create Ticket}}} in the Quick Ticket dialogue
>> links to the full [https://issues.apache.org/bloodhound/newticket
>> /newticket] page. Users can't be expected to know this. I believe we
>> should add some text to the {{{class="popover-title"}}} that links to the
>> dialogue instead - see the attached screenshot of a change I made locally.
>>
>> 2. The most common thing I find myself doing after using Quick Ticket is
>> to edit the resulting ticket to add a description. I believe we should
>> should provide a small description field in the Quick Ticket dialogue (3
>> rows?).
>>
>>
> +1
>
>
>> 3. Thinking about what we could expect the average user to know, we should
>> probably replace the **Version** dropdown with one for **Priority**. Few
>> users will actively scheduled tickets, while many will have some idea of
>> priority, even if it's just their own priority.
>>
>> **The order of fields should then be:**
>> 1. Summary
>> 1. Description
>> 1. Type
>> 1. Component
>> 1. Priority
>>
>> As an aside, I would question whether component should be a default field,
>> happy to discuss this in the comments.
>>
> I think version needs to be there. For any ticket that is a bug, it is
> important to know which version!
> And for any project that does feature planning, version is important for
> all ticket types.
I would be happy with that. Associating a bug to a version, where they
are defined, should be available.
Components should be good too and we appear to be missing product from
the list.
>
> Ideally this should be user configurable but we could also auto-hide any
> fields for which there are no values defined (id a project does not use
> components, don't show them).
Perhaps, in the long run, we should make these things configurable based
on permissions for a given project. That could make it local policy to
say whether an anonymous user (for instance) is allowed to set specific
aspects of tickets. This would probably have to extend into the
newticket interface too.
Hiding fields that are not available certainly makes sense.
Cheers,
Gary
Re: [Apache Bloodhound] #234: Quick Ticket: link to /newticket,
description and priority
Posted by Peter Koželj <pe...@digiverse.si>.
On Wed, Oct 17, 2012 at 6:15 PM, Joe Dreimann <joachim.dreimann@wandisco.com
> wrote:
> On 17 Oct 2012, at 17:00, Peter Koželj <pe...@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/
>
> - Joe
>
>
Ticket needs to be resolved for each individual version separately.
So we would need at least status per version. Then it might be better if we
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). From the UI perspective, we could still allow for bulk create of
these tickets by selecting multiple versions in the version field.
Re: ticket associated with multiple versions (Was: Re: [Apache
Bloodhound] #234: Quick Ticket: link to /newticket, description and priority)
Posted by Peter Koželj <pe...@digiverse.si>.
On Wed, Oct 24, 2012 at 1:25 PM, Gary Martin <ga...@wandisco.com>wrote:
> On 24/10/12 10:36, Peter Koželj wrote:
>
>> On Fri, Oct 19, 2012 at 3:16 PM, Gary Martin <ga...@wandisco.com>**
>> wrote:
>>
>> On 19/10/12 12:11, Joachim Dreimann wrote:
>>>
>>> On 18 Oct 2012, at 21:35, Gary Martin <ga...@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
>
Re: ticket associated with multiple versions (Was: Re: [Apache Bloodhound]
#234: Quick Ticket: link to /newticket, description and priority)
Posted by Gary Martin <ga...@wandisco.com>.
On 24/10/12 10:36, Peter Koželj wrote:
> On Fri, Oct 19, 2012 at 3:16 PM, Gary Martin <ga...@wandisco.com>wrote:
>
>> On 19/10/12 12:11, Joachim Dreimann wrote:
>>
>>> On 18 Oct 2012, at 21:35, Gary Martin <ga...@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
Re: ticket associated with multiple versions (Was: Re: [Apache
Bloodhound] #234: Quick Ticket: link to /newticket, description and priority)
Posted by Peter Koželj <pe...@digiverse.si>.
On Fri, Oct 19, 2012 at 3:16 PM, Gary Martin <ga...@wandisco.com>wrote:
> On 19/10/12 12:11, Joachim Dreimann wrote:
>
>> On 18 Oct 2012, at 21:35, Gary Martin <ga...@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
Re: ticket associated with multiple versions (Was: Re: [Apache Bloodhound]
#234: Quick Ticket: link to /newticket, description and priority)
Posted by Gary Martin <ga...@wandisco.com>.
On 19/10/12 12:11, Joachim Dreimann wrote:
> On 18 Oct 2012, at 21:35, Gary Martin <ga...@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
Re: ticket associated with multiple versions (Was: Re: [Apache Bloodhound] #234: Quick Ticket: link to /newticket, description and priority)
Posted by Joachim Dreimann <jo...@wandisco.com>.
On 18 Oct 2012, at 21:35, Gary Martin <ga...@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.
> 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.
>
> 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
>
> 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 <jo...@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
>
Re: ticket associated with multiple versions (Was: Re: [Apache Bloodhound] #234: Quick Ticket: link to /newticket, description and priority)
Posted by Gary Martin <ga...@wandisco.com>.
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 <jo...@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 <pe...@digiverse.si> wrote:
>
>> On Thu, Oct 18, 2012 at 2:56 PM, Gary Martin
><ga...@wandisco.com>wrote:
>>
>>> On 18/10/12 13:00, Peter Koželj wrote:
>>>
>>>> On Thu, Oct 18, 2012 at 10:00 AM, Gary Martin
><ga...@wandisco.com>*
>>>> *wrote:
>>>>
>>>>
>>>>> "Peter Koželj" <pe...@digiverse.si> wrote:
>>>>>
>>>>> On Thu, Oct 18, 2012 at 5:19 AM, Olemis Lang <ol...@gmail.com>
>wrote:
>>>>>>
>>>>>> On 10/17/12, Gary Martin <ga...@wandisco.com> wrote:
>>>>>>>
>>>>>>>> On 17/10/12 17:15, Joe Dreimann wrote:
>>>>>>>>
>>>>>>>>> On 17 Oct 2012, at 17:00, Peter Koželj <pe...@digiverse.si>
>wrote:
>>>>>>>>>
>>>>>>>>> On Wed, Oct 17, 2012 at 4:34 PM, Gary Martin
>>>>>>>>>> <ga...@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
Re: ticket associated with multiple versions (Was: Re: [Apache Bloodhound] #234: Quick Ticket: link to /newticket, description and priority)
Posted by Joe Dreimann <jo...@wandisco.com>.
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 <pe...@digiverse.si> wrote:
> On Thu, Oct 18, 2012 at 2:56 PM, Gary Martin <ga...@wandisco.com>wrote:
>
>> On 18/10/12 13:00, Peter Koželj wrote:
>>
>>> On Thu, Oct 18, 2012 at 10:00 AM, Gary Martin <ga...@wandisco.com>*
>>> *wrote:
>>>
>>>
>>>> "Peter Koželj" <pe...@digiverse.si> wrote:
>>>>
>>>> On Thu, Oct 18, 2012 at 5:19 AM, Olemis Lang <ol...@gmail.com> wrote:
>>>>>
>>>>> On 10/17/12, Gary Martin <ga...@wandisco.com> wrote:
>>>>>>
>>>>>>> On 17/10/12 17:15, Joe Dreimann wrote:
>>>>>>>
>>>>>>>> On 17 Oct 2012, at 17:00, Peter Koželj <pe...@digiverse.si> wrote:
>>>>>>>>
>>>>>>>> On Wed, Oct 17, 2012 at 4:34 PM, Gary Martin
>>>>>>>>> <ga...@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
Re: ticket associated with multiple versions (Was: Re: [Apache
Bloodhound] #234: Quick Ticket: link to /newticket, description and priority)
Posted by Peter Koželj <pe...@digiverse.si>.
On Thu, Oct 18, 2012 at 2:56 PM, Gary Martin <ga...@wandisco.com>wrote:
> On 18/10/12 13:00, Peter Koželj wrote:
>
>> On Thu, Oct 18, 2012 at 10:00 AM, Gary Martin <ga...@wandisco.com>*
>> *wrote:
>>
>>
>>> "Peter Koželj" <pe...@digiverse.si> wrote:
>>>
>>> On Thu, Oct 18, 2012 at 5:19 AM, Olemis Lang <ol...@gmail.com> wrote:
>>>>
>>>> On 10/17/12, Gary Martin <ga...@wandisco.com> wrote:
>>>>>
>>>>>> On 17/10/12 17:15, Joe Dreimann wrote:
>>>>>>
>>>>>>> On 17 Oct 2012, at 17:00, Peter Koželj <pe...@digiverse.si> wrote:
>>>>>>>
>>>>>>> On Wed, Oct 17, 2012 at 4:34 PM, Gary Martin
>>>>>>>> <ga...@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
Re: ticket associated with multiple versions (Was: Re: [Apache Bloodhound]
#234: Quick Ticket: link to /newticket, description and priority)
Posted by Gary Martin <ga...@wandisco.com>.
On 18/10/12 13:00, Peter Koželj wrote:
> On Thu, Oct 18, 2012 at 10:00 AM, Gary Martin <ga...@wandisco.com>wrote:
>
>>
>> "Peter Koželj" <pe...@digiverse.si> wrote:
>>
>>> On Thu, Oct 18, 2012 at 5:19 AM, Olemis Lang <ol...@gmail.com> wrote:
>>>
>>>> On 10/17/12, Gary Martin <ga...@wandisco.com> wrote:
>>>>> On 17/10/12 17:15, Joe Dreimann wrote:
>>>>>> On 17 Oct 2012, at 17:00, Peter Koželj <pe...@digiverse.si> wrote:
>>>>>>
>>>>>>> On Wed, Oct 17, 2012 at 4:34 PM, Gary Martin
>>>>>>> <ga...@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/
>>>>>>
>>>>>> - 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
Re: ticket associated with multiple versions (Was: Re: [Apache
Bloodhound] #234: Quick Ticket: link to /newticket, description and priority)
Posted by Peter Koželj <pe...@digiverse.si>.
On Thu, Oct 18, 2012 at 10:00 AM, Gary Martin <ga...@wandisco.com>wrote:
>
>
> "Peter Koželj" <pe...@digiverse.si> wrote:
>
> >On Thu, Oct 18, 2012 at 5:19 AM, Olemis Lang <ol...@gmail.com> wrote:
> >
> >> On 10/17/12, Gary Martin <ga...@wandisco.com> wrote:
> >> > On 17/10/12 17:15, Joe Dreimann wrote:
> >> >> On 17 Oct 2012, at 17:00, Peter Koželj <pe...@digiverse.si> wrote:
> >> >>
> >> >>> On Wed, Oct 17, 2012 at 4:34 PM, Gary Martin
> >> >>> <ga...@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/
> >> >>
> >> >> - 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
Re: ticket associated with multiple versions (Was: Re: [Apache Bloodhound] #234: Quick Ticket: link to /newticket, description and priority)
Posted by Gary Martin <ga...@wandisco.com>.
"Peter Koželj" <pe...@digiverse.si> wrote:
>On Thu, Oct 18, 2012 at 5:19 AM, Olemis Lang <ol...@gmail.com> wrote:
>
>> On 10/17/12, Gary Martin <ga...@wandisco.com> wrote:
>> > On 17/10/12 17:15, Joe Dreimann wrote:
>> >> On 17 Oct 2012, at 17:00, Peter Koželj <pe...@digiverse.si> wrote:
>> >>
>> >>> On Wed, Oct 17, 2012 at 4:34 PM, Gary Martin
>> >>> <ga...@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/
>> >>
>> >> - 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
Re: ticket associated with multiple versions (Was: Re: [Apache
Bloodhound] #234: Quick Ticket: link to /newticket, description and priority)
Posted by Peter Koželj <pe...@digiverse.si>.
On Thu, Oct 18, 2012 at 5:19 AM, Olemis Lang <ol...@gmail.com> wrote:
> On 10/17/12, Gary Martin <ga...@wandisco.com> wrote:
> > On 17/10/12 17:15, Joe Dreimann wrote:
> >> On 17 Oct 2012, at 17:00, Peter Koželj <pe...@digiverse.si> wrote:
> >>
> >>> On Wed, Oct 17, 2012 at 4:34 PM, Gary Martin
> >>> <ga...@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/
> >>
> >> - 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
Re: ticket associated with multiple versions (Was: Re: [Apache
Bloodhound] #234: Quick Ticket: link to /newticket, description and priority)
Posted by Olemis Lang <ol...@gmail.com>.
On 10/17/12, Gary Martin <ga...@wandisco.com> wrote:
> On 17/10/12 17:15, Joe Dreimann wrote:
>> On 17 Oct 2012, at 17:00, Peter Koželj <pe...@digiverse.si> wrote:
>>
>>> On Wed, Oct 17, 2012 at 4:34 PM, Gary Martin
>>> <ga...@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/
>>
>> - 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 associated with multiple versions (Was: Re: [Apache Bloodhound]
#234: Quick Ticket: link to /newticket, description and priority)
Posted by Gary Martin <ga...@wandisco.com>.
On 17/10/12 17:15, Joe Dreimann wrote:
> On 17 Oct 2012, at 17:00, Peter Koželj <pe...@digiverse.si> wrote:
>
>> On Wed, Oct 17, 2012 at 4:34 PM, Gary Martin <ga...@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/
>
> - Joe
>
>
Sorry to start the new thread early Peter.. It is not a high priority at
the point but I am happy to discuss while it is fresh in my mind.
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.
I would not be restricting this to bugs, by the way. Tasks and
enhancements are equally valid in this discussion where a project is
maintaining multiple versions of a product.
Perhaps off topic again but.. Given this ability to be a part of
multiple versions, would it be appropriate to offer the possibility of
generating tickets for the individual versions, perhaps with the new
tickets as sub tickets of the original?
Cheers,
Gary
Re: [Apache Bloodhound] #234: Quick Ticket: link to /newticket, description and priority
Posted by Joe Dreimann <jo...@wandisco.com>.
On 17 Oct 2012, at 17:00, Peter Koželj <pe...@digiverse.si> wrote:
> On Wed, Oct 17, 2012 at 4:34 PM, Gary Martin <ga...@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/
- Joe
Re: [Apache Bloodhound] #234: Quick Ticket: link to /newticket,
description and priority
Posted by Peter Koželj <pe...@digiverse.si>.
On Wed, Oct 17, 2012 at 4:34 PM, Gary Martin <ga...@wandisco.com>wrote:
> On 17/10/12 12:03, Ryan Ollos wrote:
>
>> On Tue, Oct 16, 2012 at 4:44 AM, Gary Martin <ga...@wandisco.com>**
>> wrote:
>>
>> [...]
>>>
>>>> I think version needs to be there. For any ticket that is a bug, it is
>>>> important to know which version!
>>>> And for any project that does feature planning, version is important for
>>>> all ticket types.
>>>>
>>>> I would be happy with that. Associating a bug to a version, where they
>>> are
>>> defined, should be available.
>>>
>>> +1 ... having a user report a bug without a version is almost always
>> undesirable, so at least we should put the Version field right in front of
>> them.
>>
>
> 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).
>
>> Components should be good too and we appear to be missing product from
>>> the
>>> list.
>>>
>>>
>>> Ideally this should be user configurable but we could also auto-hide any
>>>> fields for which there are no values defined (id a project does not use
>>>> components, don't show them).
>>>>
>>>> Perhaps, in the long run, we should make these things configurable
>>> based
>>> on permissions for a given project. That could make it local policy to
>>> say
>>> whether an anonymous user (for instance) is allowed to set specific
>>> aspects
>>> of tickets. This would probably have to extend into the newticket
>>> interface
>>> too.
>>>
>>> I also like the idea of having TICKET_VIEW_<FIELD> and
>> TICKET_EDIT_<FIELD>
>> permissions. One use case is, in the past, I've had the need to restrict
>> who can assign the milestone, and I suspect this would be common in
>> organization for which only the configuration control board or project
>> manager should be able to set the ticket milestone.
>>
>
> Yes, this is the case I have in mind in particular. It would be silly to
> expect an anonymous user who is allowed to raise a ticket to also be able
> to set when it happens.
>
>
> Similarly, we have a
>> use-case on trac-hacks for revoking some fields that are abused by
>> anonymous, such as Priority or Severity, and ideally these might only be
>> set by the product owner.
>>
>
> Indeed, although I think these cases also suggest that we should also be
> able to set permissions that only allow initial setting of a field. In the
> case of Priority/Severity you might want to use one to indicate a
> customer's preference and the other to indicate internal priorities of
> course.
>
> Talking of which, Severity should probably be in the list of fields to put
> in the quick ticket dialog when a choice of severity levels is available.
>
>
> Following the thought you started of extending this to the newticket
>> interface ... the permissions would also allow for simplifying the ticket
>> entry form, in ways that the SimpleTicketPlugin (2) and
>> BlackMagicTicketTweaksPlugin (3) have tried to do. If the user only has
>> only TICKET_VIEW_<FIELD> permission, the <FIELD> presumably wouldn't be
>> shown on the newticket form, or in the modify ticket section of the ticket
>> page.
>>
>> (1) http://trac.edgewall.org/**ticket/8778<http://trac.edgewall.org/ticket/8778>
>> (2) http://trac-hacks.org/wiki/**SimpleTicketPlugin<http://trac-hacks.org/wiki/SimpleTicketPlugin>
>> (3) http://trac-hacks.org/wiki/**BlackMagicTicketTweaksPlugin<http://trac-hacks.org/wiki/BlackMagicTicketTweaksPlugin>
>>
>>
> Interesting.. these might be worth looking into further if this kind of
> behaviour is seen as appropriate.
>
> Cheers,
> Gary
>
Re: [Apache Bloodhound] #234: Quick Ticket: link to /newticket, description
and priority
Posted by Gary Martin <ga...@wandisco.com>.
On 17/10/12 12:03, Ryan Ollos wrote:
> On Tue, Oct 16, 2012 at 4:44 AM, Gary Martin <ga...@wandisco.com>wrote:
>
>> [...]
>>> I think version needs to be there. For any ticket that is a bug, it is
>>> important to know which version!
>>> And for any project that does feature planning, version is important for
>>> all ticket types.
>>>
>> I would be happy with that. Associating a bug to a version, where they are
>> defined, should be available.
>>
> +1 ... having a user report a bug without a version is almost always
> undesirable, so at least we should put the Version field right in front of
> them.
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.
>
>> Components should be good too and we appear to be missing product from the
>> list.
>>
>>
>>> Ideally this should be user configurable but we could also auto-hide any
>>> fields for which there are no values defined (id a project does not use
>>> components, don't show them).
>>>
>> Perhaps, in the long run, we should make these things configurable based
>> on permissions for a given project. That could make it local policy to say
>> whether an anonymous user (for instance) is allowed to set specific aspects
>> of tickets. This would probably have to extend into the newticket interface
>> too.
>>
> I also like the idea of having TICKET_VIEW_<FIELD> and TICKET_EDIT_<FIELD>
> permissions. One use case is, in the past, I've had the need to restrict
> who can assign the milestone, and I suspect this would be common in
> organization for which only the configuration control board or project
> manager should be able to set the ticket milestone.
Yes, this is the case I have in mind in particular. It would be silly to
expect an anonymous user who is allowed to raise a ticket to also be
able to set when it happens.
> Similarly, we have a
> use-case on trac-hacks for revoking some fields that are abused by
> anonymous, such as Priority or Severity, and ideally these might only be
> set by the product owner.
Indeed, although I think these cases also suggest that we should also be
able to set permissions that only allow initial setting of a field. In
the case of Priority/Severity you might want to use one to indicate a
customer's preference and the other to indicate internal priorities of
course.
Talking of which, Severity should probably be in the list of fields to
put in the quick ticket dialog when a choice of severity levels is
available.
> Following the thought you started of extending this to the newticket
> interface ... the permissions would also allow for simplifying the ticket
> entry form, in ways that the SimpleTicketPlugin (2) and
> BlackMagicTicketTweaksPlugin (3) have tried to do. If the user only has
> only TICKET_VIEW_<FIELD> permission, the <FIELD> presumably wouldn't be
> shown on the newticket form, or in the modify ticket section of the ticket
> page.
>
> (1) http://trac.edgewall.org/ticket/8778
> (2) http://trac-hacks.org/wiki/SimpleTicketPlugin
> (3) http://trac-hacks.org/wiki/BlackMagicTicketTweaksPlugin
>
Interesting.. these might be worth looking into further if this kind of
behaviour is seen as appropriate.
Cheers,
Gary
Re: [Apache Bloodhound] #234: Quick Ticket: link to /newticket,
description and priority
Posted by Ryan Ollos <ry...@wandisco.com>.
On Tue, Oct 16, 2012 at 4:44 AM, Gary Martin <ga...@wandisco.com>wrote:
> [...]
>>
>> I think version needs to be there. For any ticket that is a bug, it is
>> important to know which version!
>> And for any project that does feature planning, version is important for
>> all ticket types.
>>
>
> I would be happy with that. Associating a bug to a version, where they are
> defined, should be available.
>
+1 ... having a user report a bug without a version is almost always
undesirable, so at least we should put the Version field right in front of
them.
> Components should be good too and we appear to be missing product from the
> list.
>
>
>> Ideally this should be user configurable but we could also auto-hide any
>> fields for which there are no values defined (id a project does not use
>> components, don't show them).
>>
>
> Perhaps, in the long run, we should make these things configurable based
> on permissions for a given project. That could make it local policy to say
> whether an anonymous user (for instance) is allowed to set specific aspects
> of tickets. This would probably have to extend into the newticket interface
> too.
>
I also like the idea of having TICKET_VIEW_<FIELD> and TICKET_EDIT_<FIELD>
permissions. One use case is, in the past, I've had the need to restrict
who can assign the milestone, and I suspect this would be common in
organization for which only the configuration control board or project
manager should be able to set the ticket milestone. Similarly, we have a
use-case on trac-hacks for revoking some fields that are abused by
anonymous, such as Priority or Severity, and ideally these might only be
set by the product owner.
Following the thought you started of extending this to the newticket
interface ... the permissions would also allow for simplifying the ticket
entry form, in ways that the SimpleTicketPlugin (2) and
BlackMagicTicketTweaksPlugin (3) have tried to do. If the user only has
only TICKET_VIEW_<FIELD> permission, the <FIELD> presumably wouldn't be
shown on the newticket form, or in the modify ticket section of the ticket
page.
(1) http://trac.edgewall.org/ticket/8778
(2) http://trac-hacks.org/wiki/SimpleTicketPlugin
(3) http://trac-hacks.org/wiki/BlackMagicTicketTweaksPlugin