Re: [Apache Bloodhound] #120: Context dependent activity

[Olemis Lang <ol...@gmail.com>]

On 6/29/12, Gary Martin <ga...@wandisco.com> wrote:
> Hi
>

Hi !

> Oops. So it is.. Thanks for pointing that out. For now I'll note the
> duplication in #120 and, hopefully, make it make more sense in the long
> run.
>

;)

> I should mention that when I was writing #120 I thought it might be
> better to separate out the Ticket side of this to a separate issue.

+1

> Although I believe it should follow the general principle of greater
> focus as suggested by #94
> (https://issues.apache.org/bloodhound/ticket/94), focusing on an
> individual Ticket, it will certainly have to show more types of events
> than at other levels.
>
> There is also the question of distinguishing the roles of the activity
> area and the 'Change History' area which is probably worth clearing up.
> Effectively the design that Joe provided us with changes that Change
> History area into a Comments only area (see
> https://svn.apache.org/repos/asf/incubator/bloodhound/trunk/doc/html-templates/ticket.html).
>
> Taking that to a hopefully logical conclusion, the Activity area
> effectively replaces the role of the Change History, showing *all* the
> Ticket change history, except using truncated comments.

so far I'm -0 about this . IMO all details of change history should be
fully available in ticket view .

[...]
>
> Anyway, I suspect that a full implementation of this approach is
> unlikely to make it into the initial release.
>

+1

[...]

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

Re: [Apache Bloodhound] #120: Context dependent activity

[Olemis Lang <ol...@gmail.com>]

On 7/1/12, Gary Martin <ga...@wandisco.com> wrote:
> On 01/07/12 16:13, Olemis Lang wrote:
>> On 6/29/12, Gary Martin <ga...@wandisco.com> wrote:
>>> Although I believe it should follow the general principle of greater
>>> focus as suggested by #94
>>> (https://issues.apache.org/bloodhound/ticket/94), focusing on an
>>> individual Ticket, it will certainly have to show more types of events
>>> than at other levels.
>>>
>>> There is also the question of distinguishing the roles of the activity
>>> area and the 'Change History' area which is probably worth clearing up.
>>> Effectively the design that Joe provided us with changes that Change
>>> History area into a Comments only area (see
>>> https://svn.apache.org/repos/asf/incubator/bloodhound/trunk/doc/html-templates/ticket.html).
>>>
>>> Taking that to a hopefully logical conclusion, the Activity area
>>> effectively replaces the role of the Change History, showing *all* the
>>> Ticket change history, except using truncated comments.
>> so far I'm -0 about this . IMO all details of change history should be
>> fully available in ticket view .
>
> I do not believe anyone wants to see any loss of details from the Ticket
> View.

this part agreed then

> This is effectively a rearrangement of the screen.

I c ... if you mean to render non-comment events at the right side
with activity appearance , then the situation improves ... but ...

> For this to
> provide a closer equivalence we should probably additionally specify
> that there is no limit on the number of events displayed in the Activity
> for a Ticket.
>

IMO , under the hood , that's something different to inserting the
activity widget , even if both approaches will make it look in a
similar way .

> Anyway, the point of the partial separation of comments from other
> events is that, while you might want to know how comments fit into the
> order of the other events (and I see us still providing the comments
> interleaved in the Activity albeit in the truncated form for compactness
> to meet this need), it is a streamlining of the process of understanding
> what a ticket is about rather than the way in which it has changed
> state.

My opinion about this is slightly different . IMO , most of the time
text in comments have a meaning in the context of ticket changes .
That relative references make sense if there's a chronological order
of ticket events .

For instance , consider #93 . Quite often in there comments make
reference to patchs , images ... previously attached at many different
time intervals . Some comments have real meaning when readers realise
it is related to a previous ticket change . IMO , if this is put apart
from main feed then readers will need to find a match between both
parts of the UI in order to figure out what's the comment about .
AFAICS this situation **might** get worst (... I need to imagine what
will happen in practice ...) if ticket is reopened a number of times .

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

... comments above were just my initial thoughts about what **might**
happen . I'll try to simulate later such reading using #93 (... and
maybe some long thread @ t.e.o) as example . Let's c how it goes ;)

[...]

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

Re: [Apache Bloodhound] #120: Context dependent activity

[Olemis Lang <ol...@gmail.com>]

On 7/2/12, Gary Martin <ga...@wandisco.com> wrote:
> On 07/02/2012 01:19 PM, Joe Dreimann wrote:
>> On 1 Jul 2012, at 22:40, Gary Martin <ga...@wandisco.com> wrote:
>>
[...]
>
> As Olemis points out, https://issues.apache.org/bloodhound/ticket/93 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.
>

If you ask me , I'm in favor of providing a more compact view
aggregating a group of successive attachment events ... even if that's
not the main goal .

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

Re: [Apache Bloodhound] #120: Context dependent activity

[Joachim Dreimann <jo...@wandisco.com>]

I see what you're saying, but I believe that functionality is only
needed _because_ the comment history became so cluttered in Trac.

When someone makes a comment while changing the state of the ticket,
that should be displayed in some way in the comment history. There's a
clear relationship between the change and the comment. I'll make a
proposal for how that may look and work next week.

This all important relationship between a change and comment made at
the same time gets hidden entirely when the option is toggled to hide
non-comment events, so it actually doesn't fix that issue.

What we don't need to see in the comment stream though are changes
that are applied by the ticket going through some process, being
changed as part of a batch or changing the version / milestone it's
associated with. This first (admittedly crude) change takes care of
that.

Cheers,
Joe

On 3 July 2012 06:34, Olemis Lang <ol...@gmail.com> wrote:
> On 7/2/12, Gary Martin <ga...@wandisco.com> wrote:
>> On 07/02/2012 01:19 PM, Joe Dreimann wrote:
>>> On 1 Jul 2012, at 22:40, Gary Martin <ga...@wandisco.com> 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!
>>
>
> That's a fair cause . I agree . Nonetheless I still don't think having
> two feeds improves this situation . IMO it makes it harder . Indeed
> afaics the same goal may be achieved by rendering the whole ticket
> feed and using "Show / hide comments" check box to toggle visibility
> of non-ticket events (... which is the way it works in my local
> install ... cmiiw ) . Maybe the most immediate improvement I can see
> so far , beyond that , is to make that box (i.e. only comments + sort
> by + ... ) sticky i.e. in such a way that users won't need to scroll
> to the top to hide non-ticket events since that control will always be
> handy
>
> [...]
>
> --
> Regards,
>
> Olemis.
>
> Blog ES: http://simelo-es.blogspot.com/
> Blog EN: http://simelo-en.blogspot.com/
>
> Featured article:

Re: [Apache Bloodhound] #120: Context dependent activity

[Olemis Lang <ol...@gmail.com>]

On 7/2/12, Gary Martin <ga...@wandisco.com> wrote:
> On 07/02/2012 01:19 PM, Joe Dreimann wrote:
>> On 1 Jul 2012, at 22:40, Gary Martin <ga...@wandisco.com> 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!
>

That's a fair cause . I agree . Nonetheless I still don't think having
two feeds improves this situation . IMO it makes it harder . Indeed
afaics the same goal may be achieved by rendering the whole ticket
feed and using "Show / hide comments" check box to toggle visibility
of non-ticket events (... which is the way it works in my local
install ... cmiiw ) . Maybe the most immediate improvement I can see
so far , beyond that , is to make that box (i.e. only comments + sort
by + ... ) sticky i.e. in such a way that users won't need to scroll
to the top to hide non-ticket events since that control will always be
handy

[...]

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

Re: [Apache Bloodhound] #120: Context dependent activity

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

On 07/02/2012 01:19 PM, Joe Dreimann wrote:
> On 1 Jul 2012, at 22:40, Gary Martin <ga...@wandisco.com> 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, https://issues.apache.org/bloodhound/ticket/93 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.

Cheers,
     Gary

Re: [Apache Bloodhound] #120: Context dependent activity

[Joe Dreimann <jo...@wandisco.com>]

On 1 Jul 2012, at 22:40, Gary Martin <ga...@wandisco.com> 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

Re: [Apache Bloodhound] #120: Context dependent activity

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

On 01/07/12 16:13, Olemis Lang wrote:
> On 6/29/12, Gary Martin <ga...@wandisco.com> wrote:
>> Although I believe it should follow the general principle of greater
>> focus as suggested by #94
>> (https://issues.apache.org/bloodhound/ticket/94), focusing on an
>> individual Ticket, it will certainly have to show more types of events
>> than at other levels.
>>
>> There is also the question of distinguishing the roles of the activity
>> area and the 'Change History' area which is probably worth clearing up.
>> Effectively the design that Joe provided us with changes that Change
>> History area into a Comments only area (see
>> https://svn.apache.org/repos/asf/incubator/bloodhound/trunk/doc/html-templates/ticket.html).
>>
>> Taking that to a hopefully logical conclusion, the Activity area
>> effectively replaces the role of the Change History, showing *all* the
>> Ticket change history, except using truncated comments.
> so far I'm -0 about this . IMO all details of change history should be
> fully available in ticket view .

I do not believe anyone wants to see any loss of details from the Ticket 
View. This is effectively a rearrangement of the screen. For this to 
provide a closer equivalence we should probably additionally specify 
that there is no limit on the number of events displayed in the Activity 
for a Ticket.

Anyway, the point of the partial separation of comments from other 
events is that, while you might want to know how comments fit into the 
order of the other events (and I see us still providing the comments 
interleaved in the Activity albeit in the truncated form for compactness 
to meet this need), 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.

Cheers,
     Gary