On Fri, Apr 25, 2014 at 04:23:43PM +0200, Philippe Vaucher wrote: > > I agree, but I think it's better than "index" tho. That one is heavily > overloaded and easily confused with other meaning in other softwares. There is a big difference between being used in a difference sense than other software --- there is a one-time learning curve after which point people can generally understand that a term in a given context has a single meaning --- and when we have two very easily confused terms (i.e., "stage versus staged") or a single identical term, overloaded within a single context. So I'm much more worried about the git documentation using the same term or two closely related terms in an overloaded fashion, much more than I am with "index" meaning one thing for databases, and another thing for book publishers, and yet another for compilers. > Yes, of course there should be a list of both positive and negative > tradeoffs. But I think the "overloaded" argument can be easily solved > by renaming one of the overloads. And renaming one of a term also has costs, especially if it is one that is in use in large amounts of documentation, both in the git man pages, and in web pages across the web. And my plea for data extends even here. For example, things like this: www.google.com/trends/explore#q=git%20staging%20area%2C%20git%20index&cmpt=q > Unfortunately yes, I see many people being silly in order to win > arguments, both in the pro-changes and against-changes side of the > discussion. I'd be much simpler to simply gather arguments on some > wiki and eventually do a vote when the list is complete about the > proposed change. Voting is not a good way to do software development. That way lies people wanting to whip up clueless folks using rhetoric (exhibit one: Fox News) to "vote" and so it's not necessarily the best way to make thoughtful decisions. Using hard data, including possibly formal UX experiments, is a much better way to make such decisions. Cheers, - Ted -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html