Community
Participate
Working Groups
AFAIK "Show Annotations" is used to display information about the history of files. Can it also show something else? If not, why not find a better name to describe what is can show. If yes, why not find a better name to describe what is can show. As a user I have no idea what is behind this point and would expect that it shows / hides Java annotations in my code.
See also bug 355801.
If we change it, we need to consistently change it in all Team providers, e.g. EGit. The menu item is also in the Team menu, not just the ruler.
(In reply to Lars Vogel from comment #0) > AFAIK "Show Annotations" is used to display information about the history of > files. > > Can it also show something else? No.
I suggest "Show Revision Information". The "Hide Revision Information" is already used by EGit to hide this information again.
Ideally this command will be a *toggle* and change the name/behavior from "Show Revision Information" to "Hide Revision Information" if the annotations are already shown. None of my colleagues realized how to hide it, once I've shown them how to show it :-)
P.S: is this really contributed by *CVS* project? Not by EGit or Team? The active contribution item identifier: org.eclipse.egit.ui.team.ShowBlame The active contribution location URI: menu:#CompilationUnitRulerContext?after=org.eclipse.egit.ui.team.ShowBlame
(In reply to Andrey Loskutov from comment #6) > P.S: is this really contributed by *CVS* project? Not by EGit or Team? I plan soon to start search for it... :-) Feel free to take this bug
(In reply to Lars Vogel from comment #4) > I suggest "Show Revision Information". The "Hide Revision Information" is > already used by EGit to hide this information again. That sounds good to me. (In reply to Andrey Loskutov from comment #5) > Ideally this command will be a *toggle* and change the name/behavior from > "Show Revision Information" to "Hide Revision Information" if the > annotations are already shown. None of my colleagues realized how to hide > it, once I've shown them how to show it :-) That's a different request. (In reply to Andrey Loskutov from comment #6) > P.S: is this really contributed by *CVS* project? Not by EGit or Team? Yes, it is contributed by each team provider (CVS, EGit, ...), but that was already mentioned in comment 2.
Andrey, this bug was filed against Platform and we use it for CVS, or we can use it as umbrella bug to fix CVS and EGit (fine with me). Alternatively, an additional bug can be filed against EGit.
Some other alternatives: "Show Blame" IMO, the "annotations" suffix is redundant. Blame is the standard term used in git and perforce, and should be well understood. "Show Authorship" More informative than "Show Annotations" "Who wrote each line?" Much more descriptive, but does not conform to the general Eclipse UI patterns. Personally, I like "Show Blame". The negative connotations of the word "blame" are obviously tounge-in-cheek. Nobody is going to see the action and think that every line of code in every file is worthy of blame. However, assigning blame is a common use of that action and naming the action after that use is funny... and a name that is both funny and accurate is easier to remember than a name that is merely accurate.
(In reply to Stefan Xenos from comment #10) > Some other alternatives: > > > "Show Blame" -1 for that and, as mentioned before +1 for "Show Revision Information".
(In reply to Dani Megert from comment #11) > (In reply to Stefan Xenos from comment #10) > > Some other alternatives: > > > > > > "Show Blame" > > -1 for that and, as mentioned before +1 for "Show Revision Information". I think it's called "Show Annotations" because of this guy: https://en.wikipedia.org/wiki/Annotation#Source_control I find "blame" sort of entertaining and funny ^_^, but it's specific to git. Other version control systems have other terminology, ex "svn praise". "Blame" could be miss-understood if you don't know git. I.e people might think it might mean "show problems of this project" So I'd say +1 for "Show Revision Information" just to avoid ambiguity among diverse user base.
New Gerrit change created: https://git.eclipse.org/r/81658
(In reply to Eclipse Genie from comment #13) > New Gerrit change created: https://git.eclipse.org/r/81658 This removes two unused strings containing "Show Annotations". Not yet the solution but no need to continue to mislead my search command: find . -name "*.properties" -print0 | xargs -0 grep -i "Show Annotations"
"Show Revision Information" seems to be preferred suggestion, adjust the name accordingly. Gerrit review for EGit coming up soon.
New Gerrit change created: https://git.eclipse.org/r/81683
As for CVS (in the eclipse.platform.team repository, I cannot find the string "Show Annotations", neither via command line search nor Eclipse search. Dani, can you advice?
(In reply to Lars Vogel from comment #17) > As for CVS (in the eclipse.platform.team repository, I cannot find the > string "Show Annotations", neither via command line search nor Eclipse > search. > > Dani, can you advice? Two issues: 1. The command does not end with an 's' in CVS (see bug 355801 comment 4) 2. There can always be an '&' in the string to mark the mnemonic Fixed with http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/?id=d0eedce8cea40c36f94ff74f9234e85c4cb0c6ca
Gerrit change https://git.eclipse.org/r/81683 was merged to [master]. Commit: http://git.eclipse.org/c/egit/egit.git/commit/?id=2aee9d18b20919c03a8c0d4bd3cd4cc0e050836f
Dani, you assigned the bug to you. Please also add this to the N&N M3, as it is user facing change.
(In reply to Lars Vogel from comment #20) > Dani, you assigned the bug to you. Please also add this to the N&N M3, as it > is user facing change. Since we assume the new command is more descriptive, it should be a self-explaining change. I'm happy if you add an N&N entry though.
(In reply to Dani Megert from comment #21) > I'm happy if you add an N&N entry though. I understand your resistance, the quality pressure is very high these day in the N&N. ;-) Just kidding, I will add a N&N for this.
New Gerrit change created: https://git.eclipse.org/r/81708
Gerrit change https://git.eclipse.org/r/81708 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=576d0ead8fac766f6b761100038a0906160bc212
(In reply to Lars Vogel from comment #22) > I understand your resistance, the quality pressure is very high these day in > the N&N. ;-) Just kidding, I will add a N&N for this. No, the quality bar is relatively low, but you still consistently manage to go even lower. It's really sad how much time you cost me again and again.
> It's really sad how much time you cost me again and again. Please behave yourself, Markus. When we write publicly, we're acting as representatives of our community. Our community survives completely on people's willingness to join us and donate their time, so we have to behave like the sort of community people would want to join. Publicly insulting other contributors works directly against that goal. If you disapprove of something Lars has done and would like him to do something differently, please give him specific and actionable feedback. Do it politely. Just insulting him tells him nothing about what's bothering you and gives him plenty of incentive not to cooperate with you.
(In reply to Stefan Xenos from comment #26) Stefan, you shouldn't shoot the messenger if you don't understand what's going on. I don't publicly insult random contributors. I only point out rubbish, and I expect people to improve. I've repeatedly told Lars that he must spend more time checking his contributions, and he knows he should always compare the final N&N with his version and learn from his mistakes. Kind requests didn't help in the past. Maybe naming and shaming will?
(In reply to Markus Keller from comment #27) > Maybe naming and shaming will? I don't think such behavior ever helps. On EclipseCon Europe the topic of insults came up by lots of people and I think such behavior is hurting the project. Yes we all should improve, technical as well as in our social behavior.
> Kind requests didn't help in the past. Maybe naming and shaming will? Regardless of whether or not it's effective, naming and shaming would go against at least one of the "derogitory comments", "personal attacks", or "insults" clauses of the Eclipse code of conduct. Reference: https://wiki.eclipse.org/Eclipse_Code_of_Conduct > Stefan, you shouldn't shoot the messenger if you don't understand what's > going on. My claim is that a new contributor reading comment 25 (or similar comments I've read elsewhere) is likely to be left with a negative impression about our community. Do you think that would be any less true if I understood more of the background of what's going on? If so, please explain. > I don't publicly insult random contributors. I only point out > rubbish, and I expect people to improve. If your goal is to have the committer correct their problem and learn from their mistakes, this approach may have the opposite effect. People have a natural tendency to get defensive when hearing criticism. Their natural reaction is to get angry and stop listening. It takes self-control to stay focused on the problem and it takes humility to accept responsibility and learn from it. When you combine legitimate criticism with inflammatory language, you push people toward a defensive and hostile reaction and away from a productive and useful one. I'd suggest that, when dealing with such problems, to focus on the problem that needs to be solved and its solution rather than focusing on the person who caused it. If you want them to know, cc them or link to the change that caused the problem. That's enough - they'll know they screwed up. They may even be thankful to you afterward for not shaming them when you could have.
I like the new "Show Revision Information". This makes it much more clear. I submitted a small suggestion: Bug 509690 - Show/Hide revision information should be a single menu item
