incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <gary.mar...@wandisco.com>
Subject Re: [Apache Bloodhound] #234: Quick Ticket: link to /newticket, description and priority
Date Tue, 16 Oct 2012 11:44:33 GMT
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

Mime
View raw message