[For the record, this was a response to http://bugzilla.wikimedia.org/show_bug.cgi?id=1085 ] [Civility:] Rob Church <robchur@...> writes: Being blunt or dismissive is completely contrary to the letter and spirit of WP:CIV. Things like: * Rudeness * Judgmental tone * Belittling contributors because of their skills * Personally targeted behavior that causes an atmosphere of greater conflict and stress "Bluntness", if that's what we're calling it now, only makes things worse, and I see it a lot when developers are involved. I would very much like to see some guidelines for interpersonal behavior in the development process. As far as community and wikilove are concerned, development of the site's software shouldn't be any different from development of the site. No one should get a special exemption to be an asshole to other Wikipedians just because they know PHP. Shouldn't that have been implemented *before* going live with this feature? What's a Subversion log? Oh please. The exact same thing could be said about the site's users. Without content contributors, there would be no point in even *having* a website, etc. etc. Disputes like this could drive *both* developers and editors away, and we need both (though in practice, it doesn't drive anyone away; it just causes them undue stress and impedes progress). We're all volunteers, here. We're all contributing our free time to the same altruistic project without getting anything in return except appreciation. Some of us know how to code websites, some of us know about Japanese fighter planes, some of us know how to write CSS, some of use know about rodent biology. More love and understanding and less arrogance, elitism, and belligerence, please. The problem here is that visible changes to the site's functionality can be made in a few different ways (Mediawiki itself, site javascript, site CSS, template markup), and when there is such a change, it's not discoverable at all how that change was made or who was responsible for it. It's not visible except to the few people who happen to be watching that template, or watching that CSS page, or know how to access and understand Mediawiki's CVS or whatever it is. There's no centralized place on the site where new features are announced ("You'll be noticing a new addition to the watchlists starting today; it tells you this and that and does this and that"). There's no centralized discussion point where people can present their ideas for features and have those features critiqued by the people who are actually going to use them. There's no test site where features are auditioned before going live. Things just go live randomly, in ways that may or may not be optimal for the site, and no one even knows where to complain. [Now, onto the actual feature being discussed:] Gurch <matthew.britton@...> writes: That's fine. But these numbers are similar to those changes. Only a few people want or use them, but they're on by default. Like implementing your "ugly as sin" diffs for the entire site by default, and then telling people they need to change their user CSS to remove them. It should be the other way around. Something like this should be a user preference. "Edit your user CSS" is NOT a user interface. Wikipedia editors are supposed to be regular people; not hackers. The site is supposed to be easy to edit, to avoid systemic bias, but it just gets more and more technical and more difficult to use all the time. Easy-to-use wiki markup has been abandoned in favor of HTML-esque tags for everything, article source code is cluttered with ref tags and table markup and on and on. (I don't think refs or tables are bad, of course; I just think they were not fully thought through, and implemented in a rush without much feedback from the non-hackers who have to use them. There are better solutions out there in the proposals bins that have just been ignored.) I don't even see what these numbers are useful for. Maybe if someone lies in an edit summary and says "small change" while the numbers say "big change", but that's about it. It doesn't give me any useful information about the diff except in that case. They don't actually tell how big the edit is, as some have said; they just tell how much the page has changed in size. That's a pretty meaningless metric. It may even be harmful; giving a false sense of security for low numbers. Changing "He was elected the" into "I like to eat poop", for instance, tells the patroller that nothing significant has been changed: 12:31 User:Omegatron/George W Bush (diff; hist) . . (0) . . Omegatron (Talk | contribs | block) These numbers don't tell me what the edit actually was; I still have to visit the diff as I normally would. They don't even tell me which edits to preferentially focus on for fighting vandalism. I behave exactly the same when viewing my watchlist with or without these numbers. I don't see how they help anything or save time anywhere. And no, I'm not a lone whiner: http://en.wikipedia.org/wiki/Wikipedia_talk:Added_or_removed_characters#To_… A much, much more useful solution would be to expand the automatic edit summary feature for all edits, as has been suggested several times for a few years. We finally got a limited auto edit summary feature recently (http://en.wikipedia.org/wiki/Wikipedia:Automatic_edit_summaries), which is great and really helpful, but it should be expanded to cover all types of diffs and then shown on *every* edit, regardless of whether the user fills out an edit summary or not. The edit summary field would be used for a prose summary of what was edited and the rationale for the edit, but the automatic summary would tell explicitly *what* was edited, and, in a lot of cases, completely prevent the need to view diffs to see whether the edits were valid or not, saving bandwidth and money for the servers and saving time for editors. Vandalism would be immediately visible on watchlists or recent changes. http://en.wikipedia.org/wiki/Wikipedia_talk:Automatic_edit_summaries#How_to… http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28perennial_proposals%… http://bugzilla.wikimedia.org/show_bug.cgi?id=1307