You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@bloodhound.apache.org by Apache Bloodhound <bl...@incubator.apache.org> on 2012/06/28 19:22:45 UTC

[Apache Bloodhound] #120: Context dependent activity

#120: Context dependent activity
-------------------------+-------------------------------------
 Reporter:  gjm          |      Owner:  nobody
     Type:  enhancement  |     Status:  new
 Priority:  major        |  Milestone:  RC1 for initial release
Component:  dashboard    |    Version:
 Keywords:               |
-------------------------+-------------------------------------
 Change of focus of the different dashboard views should extend to the
 activity feed area. This means that for a milestone view you should see
 events associated with the milestone.

-- 
Ticket URL: <https://issues.apache.org/bloodhound/ticket/120>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker

Re: [Apache Bloodhound] #120: Ticket specific context dependent activity (was: Context dependent activity)

Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#120: Ticket specific context dependent activity
--------------------------+-------------------------------------
  Reporter:  gjm          |      Owner:  nobody
      Type:  enhancement  |     Status:  new
  Priority:  major        |  Milestone:  RC1 for initial release
 Component:  dashboard    |    Version:
Resolution:               |   Keywords:
--------------------------+-------------------------------------

Old description:

> Change of focus of the different dashboard views should extend to the
> activity feed area. This means that for a milestone view you should see
> events associated with the milestone.

New description:

 Activity contexts in general are to be looked at in #94. Once that is
 complete, we need to decide how this should be extended in the case of
 Ticket views.

 In order for the activity to be consistent we should:

  * Only list events associated with the ticket (or related tickets when
 appropriate plugins are available)
  * Include all the ticket change events including attachments and commits

--

Comment (by gjm):

 There has been a discussion of this, roughly starting from [http://mail-
 archives.apache.org/mod_mbox/incubator-bloodhound-
 dev/201206.mbox/%3C4FED7E9A.1010206@wandisco.com%3E this message]

 This may lead to effective removal of non-comment events in the current
 "Change History" area which can then be re-labeled "Comments"

-- 
Ticket URL: <https://issues.apache.org/bloodhound/ticket/120#comment:2>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker

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

Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#120: Context dependent activity
--------------------------+-------------------------------------
  Reporter:  gjm          |      Owner:  nobody
      Type:  enhancement  |     Status:  new
  Priority:  major        |  Milestone:  RC1 for initial release
 Component:  dashboard    |    Version:
Resolution:               |   Keywords:
--------------------------+-------------------------------------

Comment (by gjm):

 As pointed out by Olemis on the mailing list, this ticket is effectively a
 duplicate of #94, though it is meant to have a smaller scope.

-- 
Ticket URL: <https://issues.apache.org/bloodhound/ticket/120#comment:1>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker

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

Posted by 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

Posted by 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

Posted by 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

Posted by 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

Posted by 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

Posted by 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

Posted by 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


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

Posted by 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

Posted by Gary Martin <ga...@wandisco.com>.
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. 
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. Oh, and as seen 
in the design, it will happen to be last change first order, matching 
the other activity feeds.

This does suggest that a slightly different approach for initial 
population of the Event area could be considered for Tickets.

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

Does all this all make sense?

Cheers,
     Gary


On 06/29/2012 06:07 AM, Olemis Lang wrote:
> isn't this ticket a duplicate of #94 ?
>
> On 6/28/12, Apache Bloodhound<bl...@incubator.apache.org>  wrote:
>> #120: Context dependent activity
>> -------------------------+-------------------------------------
>>   Reporter:  gjm          |      Owner:  nobody
>>       Type:  enhancement  |     Status:  new
>>   Priority:  major        |  Milestone:  RC1 for initial release
>> Component:  dashboard    |    Version:
>>   Keywords:               |
>> -------------------------+-------------------------------------
>>   Change of focus of the different dashboard views should extend to the
>>   activity feed area. This means that for a milestone view you should see
>>   events associated with the milestone.
>>
>> --
>> Ticket URL:<https://issues.apache.org/bloodhound/ticket/120>
>> Apache Bloodhound<https://issues.apache.org/bloodhound/>
>> The Apache Bloodhound (incubating) issue tracker
>>
>


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

Posted by Olemis Lang <ol...@gmail.com>.
isn't this ticket a duplicate of #94 ?

On 6/28/12, Apache Bloodhound <bl...@incubator.apache.org> wrote:
> #120: Context dependent activity
> -------------------------+-------------------------------------
>  Reporter:  gjm          |      Owner:  nobody
>      Type:  enhancement  |     Status:  new
>  Priority:  major        |  Milestone:  RC1 for initial release
> Component:  dashboard    |    Version:
>  Keywords:               |
> -------------------------+-------------------------------------
>  Change of focus of the different dashboard views should extend to the
>  activity feed area. This means that for a milestone view you should see
>  events associated with the milestone.
>
> --
> Ticket URL: <https://issues.apache.org/bloodhound/ticket/120>
> Apache Bloodhound <https://issues.apache.org/bloodhound/>
> The Apache Bloodhound (incubating) issue tracker
>


-- 
Regards,

Olemis.

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

Featured article: