Re: User feedback after BH survey

[Ryan Ollos <ry...@wandisco.com>]

On Mon, Dec 30, 2013 at 9:56 AM, Gary Martin <ga...@wandisco.com>wrote:

> On 30 December 2013 00:11, Ryan Ollos <ry...@wandisco.com> wrote:
>
> > On Fri, Dec 20, 2013 at 4:14 PM, Ryan Ollos <ry...@wandisco.com>
> > wrote:
> >
> > > On Tue, Dec 17, 2013 at 8:29 AM, Gary Martin <gary.martin@wandisco.com
> > >wrote:
> > >
> > >> On 17/12/13 15:48, Joachim Dreimann wrote:
> > >>
> > >>> On 17 December 2013 14:22, Olemis Lang <ol...@gmail.com> wrote:
> > >>>
> > >>>  Hi !
> > >>>>
> > >>>> Recently I have received user feedback from Bloodhound users and
> > wanted
> > >>>> to
> > >>>> highlight these points for us to discuss (as usual, my comments
> > inline)
> > >>>> :
> > >>>>
> > >>>>
> > >>>>   - After ticket creation, if the ticket is automatically assigned
> > >>>> (depending on the product), the ticket status is inconsistent. When
> > >>>> you enter the ticket url, you can see that the ticket has been
> > >>>> assigned to xxxx, but the ticket status is still new. You must
> > >>>> manually modify the ticket status and select "reassign to: xxxx" so
> > >>>> that the ticket status becomes "assigned".
> > >>>> If the ticket is automatically assigned on creation, the ticket
> status
> > >>>> must be changed accordingly without user intervention.
> > >>>>
> > >>>>   From a user experience perspective I don't think "assigned"
> helpful
> > >>> as a
> > >>> status (like "new" or "re-opened", I mentioned this before).
> > >>>
> > >>> A ticket is:
> > >>> - re-opened => if it was closed before
> > >>> - assigned => if it currently has an owner
> > >>> - new => if it was recently created
> > >>> - etc
> > >>>
> > >>> They are properties, not a status.
> > >>>
> > >>
> > >> They each look like a status to me. Obviously a status is a property!
> > >>
> > >> You could of course state that assigned is closer in meaning to
> > >> ownership. We could offer an alternative workflow that defines a
> better
> > set
> > >> of ticket states than the current default. I think we are only
> > constrained
> > >> in having new and closed states at the moment.
> > >>
> > >>
> > >>  None of these may be true for a ticket, or some, or all of them. I
> > think
> > >>> it's a bad decision to have a singular status define one properties
> to
> > be
> > >>> displayed. This problem described by Olemis would not have happened
> if
> > it
> > >>> wasn't the status.
> > >>>
> > >>> Just throwing it out there in hope other people agree and are willing
> > to
> > >>> change this. It's certainly not the easiest solution to this
> particular
> > >>> problem :-)
> > >>>
> > >>
> > >> Yeah, I am fine with improving the possible states and offering those
> up
> > >> by default or whatever if we can basically agree.
> > >>
> > >> Essentially we seem to be considering better terms for a ticket that
> has
> > >> been given to a user but is pre-work being performed (currently
> > assigned)
> > >> and for when a ticket is being worked on (currently accepted seems to
> be
> > >> used for that purpose).
> > >
> > >
> > > I was similarly troubled at one time by new tickets with an owner not
> > > being in the assigned state, which led to a small change in Trac. The
> > > following threads reference a plugin to address the issue, and some
> > similar
> > > opinions on the matter:
> > > http://trac.edgewall.org/ticket/8484
> > > https://groups.google.com/forum/#!topic/trac-users/_ndwqwz9MUU
> > > https://groups.google.com/forum/#!topic/trac-users/Sih7yxnLH9o
> > >
> > > I think it would make sense to have the assigned state track with the
> > > owner property in the same way that the closed state tracks with the
> > > resolution property. However, we'd need to look into the consequences
> of
> > > changing Trac's constraint that all tickets start in the new state.
> > >
> >
> > This issue has also been discussed in trac:#2045. I think we can probably
> > change the behavior for Trac 1.2 so that tickets with an owner are always
> > in the assigned state.
> >
> > http://trac.edgewall.org/ticket/2045#comment:2<
> http://trac.edgewall.org/ticket/2045#comment:27>
>
>
> So this looks like you want to make it so that the ticket can start either
> as new or as assigned as the original message suggests. This is probably OK
> as long as we also keep note that 'assigned' is not a state that a workflow
> has to define. As such we cannot predict the status that a user will want
> to go directly to and that either means that it only works when that status
> is available or we allow the initial-state-if-owned to be configurable
> (perhaps defaulting to new if the specified state does not exist.)
>
> Cheers,
>     Gary
>

That is a good point about the potential of constraining the workflow to
have an assigned state.

I've proposed a different way to solve this issue, which I'm continuing to
investigate:
http://trac.edgewall.org/ticket/2045#comment:28

Re: User feedback after BH survey

[Gary Martin <ga...@wandisco.com>]

On 01/01/14 03:58, Ryan Ollos wrote:
> On Mon, Dec 30, 2013 at 9:56 AM, Gary Martin <ga...@wandisco.com>wrote:
>
>> On 30 December 2013 00:11, Ryan Ollos <ry...@wandisco.com> wrote:
>>
>>> On Fri, Dec 20, 2013 at 4:14 PM, Ryan Ollos <ry...@wandisco.com>
>>> wrote:
>>>
>>>> On Tue, Dec 17, 2013 at 8:29 AM, Gary Martin <gary.martin@wandisco.com
>>>> wrote:
>>>>
>>>>> On 17/12/13 15:48, Joachim Dreimann wrote:
>>>>>
>>>>>> On 17 December 2013 14:22, Olemis Lang <ol...@gmail.com> wrote:
>>>>>>
>>>>>>  Hi !
>>>>>>> Recently I have received user feedback from Bloodhound users and
>>> wanted
>>>>>>> to
>>>>>>> highlight these points for us to discuss (as usual, my comments
>>> inline)
>>>>>>> :
>>>>>>>
>>>>>>>
>>>>>>>   - After ticket creation, if the ticket is automatically assigned
>>>>>>> (depending on the product), the ticket status is inconsistent. When
>>>>>>> you enter the ticket url, you can see that the ticket has been
>>>>>>> assigned to xxxx, but the ticket status is still new. You must
>>>>>>> manually modify the ticket status and select "reassign to: xxxx" so
>>>>>>> that the ticket status becomes "assigned".
>>>>>>> If the ticket is automatically assigned on creation, the ticket
>> status
>>>>>>> must be changed accordingly without user intervention.
>>>>>>>
>>>>>>>   From a user experience perspective I don't think "assigned"
>> helpful
>>>>>> as a
>>>>>> status (like "new" or "re-opened", I mentioned this before).
>>>>>>
>>>>>> A ticket is:
>>>>>> - re-opened => if it was closed before
>>>>>> - assigned => if it currently has an owner
>>>>>> - new => if it was recently created
>>>>>> - etc
>>>>>>
>>>>>> They are properties, not a status.
>>>>>>
>>>>> They each look like a status to me. Obviously a status is a property!
>>>>>
>>>>> You could of course state that assigned is closer in meaning to
>>>>> ownership. We could offer an alternative workflow that defines a
>> better
>>> set
>>>>> of ticket states than the current default. I think we are only
>>> constrained
>>>>> in having new and closed states at the moment.
>>>>>
>>>>>
>>>>>  None of these may be true for a ticket, or some, or all of them. I
>>> think
>>>>>> it's a bad decision to have a singular status define one properties
>> to
>>> be
>>>>>> displayed. This problem described by Olemis would not have happened
>> if
>>> it
>>>>>> wasn't the status.
>>>>>>
>>>>>> Just throwing it out there in hope other people agree and are willing
>>> to
>>>>>> change this. It's certainly not the easiest solution to this
>> particular
>>>>>> problem :-)
>>>>>>
>>>>> Yeah, I am fine with improving the possible states and offering those
>> up
>>>>> by default or whatever if we can basically agree.
>>>>>
>>>>> Essentially we seem to be considering better terms for a ticket that
>> has
>>>>> been given to a user but is pre-work being performed (currently
>>> assigned)
>>>>> and for when a ticket is being worked on (currently accepted seems to
>> be
>>>>> used for that purpose).
>>>>
>>>> I was similarly troubled at one time by new tickets with an owner not
>>>> being in the assigned state, which led to a small change in Trac. The
>>>> following threads reference a plugin to address the issue, and some
>>> similar
>>>> opinions on the matter:
>>>> http://trac.edgewall.org/ticket/8484
>>>> https://groups.google.com/forum/#!topic/trac-users/_ndwqwz9MUU
>>>> https://groups.google.com/forum/#!topic/trac-users/Sih7yxnLH9o
>>>>
>>>> I think it would make sense to have the assigned state track with the
>>>> owner property in the same way that the closed state tracks with the
>>>> resolution property. However, we'd need to look into the consequences
>> of
>>>> changing Trac's constraint that all tickets start in the new state.
>>>>
>>> This issue has also been discussed in trac:#2045. I think we can probably
>>> change the behavior for Trac 1.2 so that tickets with an owner are always
>>> in the assigned state.
>>>
>>> http://trac.edgewall.org/ticket/2045#comment:2<
>> http://trac.edgewall.org/ticket/2045#comment:27>
>>
>>
>> So this looks like you want to make it so that the ticket can start either
>> as new or as assigned as the original message suggests. This is probably OK
>> as long as we also keep note that 'assigned' is not a state that a workflow
>> has to define. As such we cannot predict the status that a user will want
>> to go directly to and that either means that it only works when that status
>> is available or we allow the initial-state-if-owned to be configurable
>> (perhaps defaulting to new if the specified state does not exist.)
>>
>> Cheers,
>>     Gary
>>
> That is a good point about the potential of constraining the workflow to
> have an assigned state.
>
> I've proposed a different way to solve this issue, which I'm continuing to
> investigate:
> http://trac.edgewall.org/ticket/2045#comment:28
>

Yes, I think that your solution there has a lot of merit, particularly
as, if I read it correctly, we would effectively become free to use any
name we like for the "new" state. As I implied in my reply on the
ticket, I would probably see if it were possible to avoid having a named
"none" state.

Cheers,
    Gary