bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <>
Subject Re: [Apache Bloodhound] #120: Context dependent activity
Date Mon, 02 Jul 2012 16:08:53 GMT
On 07/02/2012 01:19 PM, Joe Dreimann wrote:
> On 1 Jul 2012, at 22:40, Gary Martin <> wrote:
>> it is a streamlining of the process of understanding what a ticket is about rather
than the way in which it has changed state. If you extract the comments all into one place
then it is easier to read it through without all the other information getting in the way.
The status change information is still all there and, in fact, the Activity draws attention
to the last changes closer to the top of the page which should be useful.
> +1 that was my thinking behind suggesting the change.
> - Joe

Excellent. I am glad that I interpreted this correctly then!

I don't want to imply that this is perfect yet - for example, for ticket 
change events that do not have comment text, a comment number is given. 
I don't know if people will care about holes in the comment numbers but 
it should be remembered that it is possible to refer to these empty 
comments which is a useful feature. Interestingly, the same is not true 
of attachment events.

As there are anchors associated with empty comments, would it be worth 
expanding an empty comment in the Comments list for those? Or should the 
ability to reply to such events be restricted to a control on the event 
in the Activity?

Are there any other issues that others have spotted?

On the plus side, it seems to me that there is an opportunity for the 
Activity to provide additional information that is lacking from the 
current Ticket view. For example, we might want to see the changesets 
for a ticket interleaved with the other events. Meanwhile, if we use one 
of the plugins that specify relationships between Tickets, we could have 
the events associated with related Tickets shown as well, as long as it 
is easy to distinguish the related events from the current Ticket events.

As Olemis points out, is 
the kind of complex ticket that we want to help developers make easier 
sense of. In this case, the number of state changes is relatively low 
but there are a large number of attachments and comments.


View raw message