On 1/1/07, Omegatron <9ybf94w02(a)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.