[For the record, this was a response to http://bugzilla.wikimedia.org/show_bug.cgi?id=1085 ]
[Civility:]
Rob Church <robchur@...> writes:
We might not implement their letter, but the spirit of the ideas of keeping civil and assuming good faith *are* applied at the development level; we just reserve the right to be blunt.
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.
If we're to implement certain tweaks for this in user preferences, then we need some co-operation from the user base to allow us time
Shouldn't that have been implemented *before* going live with this feature?
There's always the Subversion log. Oh, but of course...non developers don't apparently like opening their damn browsers.
What's a Subversion log?
That attitude could very well lose you a lot of the behind-the-scenes supporting cast one day, without whom you wouldn't even *have* a website.
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:
Exactly. I very much doubt anyone wants their diffs to look like mine (the stuff that's usually grey isn't even visible, they're blue and yellow, and generally ugly as sin). I also doubt many people want the "Go" and "Search" buttons hidden, as I have done (I just press Enter to Go, and my browser has a search box). But that's the way *I* want things, and because the interface can be customized that way I can have it that way.
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_r...
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%2...
On 01/01/07, Omegatron 9ybf94w02@sneakemail.com wrote:
"Bluntness", if that's what we're calling it now, only makes things worse, and I see it a lot when developers are involved.
When I say "being blunt", I mean calling a bad idea a bad idea from the get-go, and not messing around.
of the site. No one should get a special exemption to be an asshole to other Wikipedians just because they know PHP.
Are you calling me an asshole?
Are you calling some other developer(s) assholes?
Shouldn't that have been implemented *before* going live with this feature?
It wasn't deemed necessary at the time, because we didn't realise users would get so up in arms about it.
What's a Subversion log?
The log of commits to the Subversion repository.
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.
Oh, for goodness' sake...
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
You're saying we should have some sort of centralised updates page?
"There's no centralized discussion point where people can present their ideas for features" -- BugZilla, when it comes down to being up to us to get it written. Prior to that, discussion can take place somewhere in the Wikipedia namespace.
Could I just remind you here that MediaWiki is not written just for the English Wikipedia. It is written to benefit every single Wikimedia wiki, in every single language that we support. It often happens that features are added because the English Wikipedia asks for them, but it often happens that feature requests come from other Wikipedias, and they have an absolute right to ask for things, and an absolute right to have their requests taken into consideration, too.
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.
Well, apparently, you do.
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.
"Only a few people want or use them". Well, it's always the ones who're complaining who are the loudest. I'm pretty sure there are hundreds of users who find the information useful, and haven't once complained. I know for a *fact* that users of many other language wikis absolutely love the feature.
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.
We have established that you would like some sort of user preference. We have established that you do not like CSS.
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 really find this hilarious, and I'm not being rude here...it's the *editors* who were pushing for the longest time for us to implement a lot of conditionals, etc. and other "fancy features" to use in markup. And eventually, after much protesting of a point that is very much like yours, we caved in, and it was implemented.
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
Of what use is the minor edit marker? Of what use are edit summaries, really? How can you be absolutely certain what happened in an edit without viewing the diff?
You can't. Like edit summaries and like minor edit flags, this information is PURELY ADVISORY. As I've said somewhere else; we offer factual information - WHO changed WHAT, WHEN they did it, and HOW MUCH they appear to have changed. We then offer information that the user is trusted to provide - namely WHAT THEY CHANGED and WHY, and whether they consider it IMPORTANT.
If you don't personally see a benefit to this, fine. But we've been asked to implement it for some time, by several different users, and we've implemented it. Apparently *someone* finds it useful.
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
As above, edit summaries are only advisory; automatic edit summaries should be viewed more as a cover-up for laziness or momentary forgetfulness than as the output of some fantastic artificial intelligence engine.
You are entitled to suggest further improvements to any aspect of MediaWiki, including ideas for the types of additional automatic edit summaries we could plausibly provide. You know, I think, where to make this suggestion.
[Side note for anyone actually following this thread: I really hate arguing with people before the end of a year, as I always like to kid myself that I can make a fresh start in the next. This issue is dragging on and on, and both sides are essentially regurgitating the same opinions. I welcome any third party review on my attitude (feel free to email it to me) if it has been inappropriate during this particular thread.]
Rob Church
On Mon, Jan 01, 2007 at 07:42:20PM +0000, Rob Church wrote:
[Side note for anyone actually following this thread: I really hate arguing with people before the end of a year, as I always like to kid myself that I can make a fresh start in the next. This issue is dragging on and on, and both sides are essentially regurgitating the same opinions. I welcome any third party review on my attitude (feel free to email it to me) if it has been inappropriate during this particular thread.]
They're morons; you're just fine.
Happy This Year. :-)
(Well, I was *going* to make this off-list, but the list configuration has 'better' ideas for me, and I'm too lazy to retype it. So be it.)
Cheers, -- jra
On 1/1/07, Omegatron 9ybf94w02@sneakemail.com wrote:
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.
If you want Rob disciplined or something for being rude, go ahead and talk to Brion.
Shouldn't that have been implemented *before* going live with this feature?
No, because nobody thought that anyone would actually object significantly. When we think that, we're usually right, but there are bound to be occasional exceptions.
What's a Subversion log?
http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/?view=log
(takes forever to load . . . there's probably some option to restrict it, timespan-wise, so it's not like ten megabytes or whatever)
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.
Yeah, there is. Bugzilla. That most people don't follow it, we can't help.
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.
I've heard more people praising them than rejecting them. Actually, who aside from you really dislikes them?
Something like this should be a user preference.
No, it should not. Adding dozens and dozens of user preferences to account for every possible thing people might like will clutter the appropriate part of the interface and be a pain in the neck to maintain. Only the most common preferences should be available as checkboxes, and not when it's whether to display an extra few characters that users can ignore anyway.
We give users the power to implement their own advanced preferences via CSS and JavaScript. We're aware that most people can't use these by themselves, but that's unavoidable for such powerful features. If they really don't like something, they can always ask someone to write the CSS/JS for them for such a simple thing.
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.
In other words, display the diffs in compressed/truncated form on the history or watchlist page. That will frequently amount to a couple hundred characters or more. A few people have already grumbled about clutter on Special:Newpages; this would be much worse. That is something I would definitely say should be an option on the page to display or not, and/or a user preference.
But it's a different request. Please file it on Bugzilla.
"Omegatron" 9ybf94w02@sneakemail.com writes:
[For the record, this was a response to http://bugzilla.wikimedia.org/show_bug.cgi?id=1085 ]
[Civility:]
Rob Church <robchur@...> writes:
We might not implement their letter, but the spirit of the ideas of keeping civil and assuming good faith *are* applied at the development level; we just reserve the right to be blunt.
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
Well, if you think so, you should probably never have posted the mail I'm replying now.
I'll not go into details, but you have a serious amount of attitude-readjustment to do, before it's safe for you to discuss tecnical issues again. Your "I'm not a developer, so I alone know what the users want"-tone, does not exactly help either.
So, in short:
* Never impose organization on something that doesn't need it. * Never mistake your opinion for the norm. * Never *ever* treat a developer as a low-class individual.
Learn that, and we can talk.
On Mon, Jan 01, 2007 at 01:58:11PM -0500, Omegatron wrote:
"Bluntness", if that's what we're calling it now, only makes things worse, and I see it a lot when developers are involved.
See my earlier reply to this, and realy *really* think hard about
40,000,000... versus 12.
Cheers, - jr '*really* hard' a
Omegatron wrote:
- Rudeness
- Judgmental tone
- Belittling contributors because of their skills
- Personally targeted behavior that causes an atmosphere of greater
conflict and stress
Well, you certainly managed at least three of the four; if you can find a way to "belittle" Rob's technical skills, you could have the full house.
Go on, we're all waiting with bated breath...
wikitech-l@lists.wikimedia.org