Bugzilla – Full Text Bug Listing
| Summary: | Option to show comments in reverse order | ||||||
|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Alex Blewitt <alex.blewitt> | ||||
| Component: | Mylyn | Assignee: | Project Inbox <mylyn-triaged> | ||||
| Status: | CLOSED MOVED | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P4 | CC: | david.shepherd, karsten.silz, mark.ringer, steffen.pingel | ||||
| Version: | unspecified | Keywords: | helpwanted | ||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 158921 | ||||||
| Attachments: |
|
||||||
|
Description
Alex Blewitt
In such a mode we would also want to put the editor on top. This would effectively be a classic Bugzilla mode. I always found it interesting that that nobody had asked for this yet considering that many have transitioned from to Bugzilla to Mylyn's rich editor. Fyi, the reason we haven't done it yet is that we've been trying to optimize a single layout (that's hard enough) and in our experimentation the Actions section worked better close to both the New Comment and the most recent comment. We can definitely consider layout options since this stuff is pretty easy to shuffle. To date we have also shied away from providing too many options so that we get as much feedback as possible about the current UI/layout so that we can prioritize related improvements such as bug 166123. Bugzilla actually puts the editor at the top, but comments in increasing date order. I was suggesting having a view where the editor was at top (but collapsed) with the comments in decreasing date order, so looking something like: [+] New Comment (collapsed) [-] 2. Alex Blewitt I think we should put .... [+] 1. Mik Kersten [+] Description This would give you the behaviour of seeing the most recent comment without any scrolling when you switch into a bug. I think having the editor at the top (unexpanded) would be mostly useless; that would mean if you switch to a view, you'd just see white space most of the time. Do you even need the editor? You could have a 'Reply' field/button/link at the bottom of each comment (much like, say, GMail) and only show the editor as needed. Whilst I agree that having too many options is unlikely to be great, I feel this particular mode could be very useful for others and might be worth an experiment to see how well it works. If you point me in the direction of the code (presumably, somewhere in the org.eclipse.mylar.ui.bugzlila plug-in) I could put a hacked version together to show you what I mean ... I don't think it would be a good idea to put description at the bottom (regardless of the comment sorting order). Also, changing comment sorting order won't really reduce amount of scrolling because Actions and People sections still going to be at the bottom. I think it would be more useful if bug 166123 is resolved and I also like Alex's suggestion about always expanding last comment (regardless of the incoming changes) BTW, Alex, are you aware that Task Editor provides content for the Outline view? It might be a good idea to also have a Quick Outline (Ctrl-O) to facilitate navigation with keyboard. Is comment #3 based on anything other than your opinion? That is, do you have some kind of specific problem caused by putting the description as effectively comment 0? Even in the real Bugzilla, the description is effectivley comment 0, followed by comment 1, followed by comment 2 ... there's nothing really 'special' about the first one. What I'm suggesting is different from what has been done before, but isn't mylyn as a whole different from what's been done before anyway? Why not see if it works? Also, note that whilst the 'actions' are at the bottom, there's no reason for them to be. I noted that it would be possible to have some kind of Gmail-like interface where clicking 'reply' brings up a text box for entry; the other options could be actions revealed at that point too. Note also that if the last comment is expanded and in reverse order (hence at the top), then bug 166123 becomes obsolete, because it already will be where the editor is. (In reply to comment #4) > Is comment #3 based on anything other than your opinion? There is an opinion and there is also 2 years of experience of using the tool to deal with the bug reports. While it may seem convenient to push Description far away when commenting, it doesn't work too well for other activities. For instance, discussion in comments is often fade away from the original report and it is important to have description next to the attributes, especially when planning and triaging. So, comment zero (aka description) does have special meaning. It seem like your suggestions are trying to address convenience of the commenting to the bug reports, but there are other activities that aren't much similar to UI interaction you could see in gmail. That is not to mention discoverability issues of the dynamically constructed UI and general layout issues in the RCP forms toolkit. I didn't say that Actions section has to be at the bottom and Mik will tel you that I've suggested number of alternative options that he had rejected. Also note that reversed comment order and layout you are suggesting may work ok when you only need to read one last comment, but when you have dozen comments to catch up it is much more natural and faster to read them in the chronological order. Even gmail don't give you option to reverse order of emails in the stack. Why were you thinking that the attributes would need to be far away from the description? I didn't say anything about that. Reversing the order of comments/description is easily doable if the attributes are then underneath. But look; it's clear that there's no interest in suggestions of how to do things differently, and nor any interest in trying to make it easier for other developers to help out, so rather than me prototyping a different UI for the bugzilla (which I was going to do) I'll spend my time on other projects where there is interest in my helping out. Feel free to close this bug as invalid; I don't care about it any more. Alex, I don't see why you have to take my comments personally and discouraging. I was barely pointing out at the aspects you left aside in your proposal and simply participated into the healthy discussion. Another thing worth to note is that most of the task editor layout details are coming from the AbstractTaskEditor, so any changes will be immediately inherited by all connectors and you need to be very careful when changing it, i.e. by design, you won't be able to change it just for Bugzilla. Marking as wontfix after comments received. Closing. Alex: your comment#6 makes sense to me based on the responses that your received from Eugene. Please note that these responses GO COMPLETELY AGAINST the communication guidelines that we have had for the project for a long time now and that have been instrumental in our success to date: http://wiki.eclipse.org/index.php/Mylyn_Contributor_Reference#Communication You are not the only person to be bitten by this and I have been trying repeatedly to correct this communication problem. Please do not consider it representative of other Mylyn committers or contributors. While I have avoided pointing to the email describing the problem because I dreaded writing it, I hope that it will demonstrate to you how important good communication is to our project and that as the project lead I will do whatever I can to ensure that it prevails: http://dev.eclipse.org/mhonarc/lists/mylar-dev/msg01351.html Eguene: you went against what I explicitly stated in comment#1 ("We can definitely consider layout options since this stuff is pretty easy to shuffle"), you mixed implementations details reasons as justification for your opinion and what's worst of this is that you said "There is an opinion and there is also 2 years of experience of using the tool to deal with the bug reports." To me this statement and your general tone could not be much more contradictory to our guidelines. I won't dwell further on this on the bug report, but this HAS to change. (In reply to comment #10) > Eguene: you went against what I explicitly stated in comment#1 I didn't went against anything. Just expressed my thought and I was quite "amazed" with reaction I received on those comments. Can someone explain to me which part of comment #3 was offensive? > you mixed implementations details reasons as justification for your opinion I wasn't aware that amount of scrolling and section expanding are the implementation details. I've been given some of those reasons as given and barely repeated them in my comment. > and what's worst of this is that you said "There is an opinion and > there is also 2 years of experience of using the tool to deal with the bug > reports." Which part of that wasn't true? Also, it is of course my fault just because I said that, but have you read comment I replied to? > To me this statement and your general tone could not be much more > contradictory to our guidelines. I won't dwell further on this on the bug > report, but this HAS to change. Meaning what? Should I stay still when someone spill on my face? Eugene: this will be my last non-technical reply on this bug report. Please do not act surprised because this is the same pattern as you've seen countless other times on bug reports and elsewhere and I have repeatedly brought it to your attention. You "just expressed your opinion", it was interpreted as either dismissing, disrespectful, or insulting, and it has turned a user away. Even if Alex's first sentence on comment#3 could be interpreted as having a harsh tone that is simply not an excuse, as I have explained before the communication guidelines are for committers, not users. Beyond that I have read all of Alex's comments carefully, thought they had good points that are likely to reflect the opinions of other newcommers and think that they should be considered when we prioritize this feature request. (In reply to comment #12) > Beyond that I have read all of Alex's comments carefully, thought they had good > points that are likely to reflect the opinions of other newcommers and think > that they should be considered when we prioritize this feature request. If you read my comment, I didn't say Alex didn't had good points. I just tried to explain that there are many angles to that issue. Also, I don't see why I can't express my opinion on some subject? Eugene: I'll consider this a final clarification of comment#12 and previous comments, although I believe that you have heard all this from me already. You, and anyone else, can express your opinions on bug reports. However, Mylyn committers need to be held to a much higher standard, and one that means that no matter what the opinions or individuals end result of what should be a technical discussion never results in anything remotely like comment#6. The fact that Alex is an "insider" of the Eclipse community meant that he actually bothered to post comment#6, which I'm thankful for because was a reasonable response given the tone of this discussion and others like it. A non-insider would have been likely to simply turn away from our project, or worse yet all of Eclipse, and tell the rest of their colleagues that while we may be building a good tool we are jerks and dismissive of newcommers' input. Based on everything that I know about running open source project and communities that is one of the most damaging things that can happen to a community that strives to be welcoming and to tools that require the input of newcomers to become widely adopted. Scheduling investigation for 3.0, since this is related to our theme of improving the Task Editor layout. My vote is for allowing comments in reverse chronological order. In my view, in many cases, the most interesting comments are the most recent and in some cases, the early comments need not be read. We are in the process of creating a Mylyn plugin for Rally and in our tool, we have a discussion (same as comment) capability in which we have decided to show the most recent discussion posts on top. Mark: thanks for the feedback. This is very closely related to one of our 3.0 plan items for improving the information density and interaction upon first open of the Task Editor. Ideally we want all of the information that you are going to want to see and the commands you will interact with to be visible without any need for scrolling, which strongly suggests a reverse chronological ordering of the comments, as long as we can come up with something reasonable to do about the Description. *** Bug 206888 has been marked as a duplicate of this bug. *** This is out of scope of the Mylyn 3.1 plan: http://wiki.eclipse.org/Mylyn/Plan/3.1. This hasn't been updated in a few years. Nor has it been deferred for a few plans as well. Will this ever get looked at? This bug is part of the feature backlog and will be considered during planning according to its priority. It is marked as P4 to indicate that it does not fall into the core scope of the project. I have added the helpwanted keyword to clarify that we would consider adding this functionality if it was provided through a community contribution. Any idea where I should look if I were to contribute this? The implementation is in TaskEditorCommentPart. I have attached a context. Created attachment 184877 [details]
mylyn/context/zip
Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn |