Regarding the "change size" indicator in change lists

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Regarding the "change size" indicator in change lists

Rob Church
[This is in response to all the bitching and whining that's taken
place since December 24th, on mailing lists, bug trackers, village
pumps and sleazy little back-alley forums...I apologise for the
crossposting. As ever, please feel free to forward this to other
appropriate parties or lists, but keep responses and/or discussion on
one.]

All right, this bickering has gone far enough. The fact of the matter
is that we're under constant pressure to keep the site alive and
introduce new features and fixes on a regular basis. I can well
understand that a lot of people will object to each change, and we do
our best to make things non-intrusive.

When this feature was first introduced, some bright spark on the
English Wikipedia edited the global CSS and made the numbers bright,
garish green and red, and emboldened them - I didn't agree with that,
but whatever. However, there were a huge number of not-too-polite
complaints blaming us for doing it, and some of these failed to
subside when it was pointed out that this had nothing to do with the
development team.

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. If I've been
particularly rude to anyone over this issue, I do apologise for it -
and I'm sure anyone else who may have been apologises too.

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 to
determine a clean means of doing so (we want to avoid duplication of
code when generating changes list items), and we want people to
remember that politeness goes both ways.

Just because user A dislikes a feature, it doesn't mean that user B
will, and it is not fair to scream and rant and rave over it because
we tried to implement something that was useful. I would like to note
also that the numbers, as with the "minor edit" flag, and the whole
concept of edit summaries, are advisory - what we provide is a factual
statement of who changed what, and how much they changed, and we allow
that user to present justification for their changes. If that user
chose to lie in their edit summary, or deliberately mis-labelled a
minor edit, then there is nothing any of us can do - and you (the
users) have coped with that well enough over (at least) the past four
years or so.

I will open a fresh feature request, giving an opportunity for Brion
to say "yes" or "no" definitively, and I will avail myself to Leon or
anyone else who would then wish to implement the outcome should they
want any input.

I point-blank refuse, however, to work with any user who feels that it
is acceptable to assume bad faith on the part of the development team.
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.


Rob Church
_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Regarding the "change size" indicator in change lists

Steve Bennett-8
On 12/30/06, Rob Church <[hidden email]> wrote:
> When this feature was first introduced, some bright spark on the
> English Wikipedia edited the global CSS and made the numbers bright,
> garish green and red, and emboldened them - I didn't agree with that,
> but whatever. However, there were a huge number of not-too-polite
> complaints blaming us for doing it, and some of these failed to
> subside when it was pointed out that this had nothing to do with the
> development team.

It's not reasonable to expect the average person to differentiate
between "people who hack CSS and JavaScript" and "developers". I read
wikitech-l, know what CSS, JavaScript, PHP and MediaWiki are, and
still don't really get who is responsible for what, or what caused
each visible change. How is the average Wikipedia user supposed to
have any idea?

I don't really know how to improve this situation, but some sort of
more visible process for improvements to MediaWiki and to the
Wikipedia stylesheets might help. I don't consider Mediazilla
"visible" at all.

Hope this helps.

Steve
_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Regarding the "change size" indicator in change lists

Ligulem
In reply to this post by Rob Church
On 30.12.2006 10:53, Rob Church wrote:
> [This is in response to all the bitching and whining that's taken
> place since December 24th, on mailing lists, bug trackers, village
> pumps and sleazy little back-alley forums...I apologise for the
> crossposting. As ever, please feel free to forward this to other
> appropriate parties or lists, but keep responses and/or discussion on
> one.]
>

I'm not sure what the problem is here. But the change size is pretty
cool and I love it. It helps a lot for spotting problem edits on recent
changes.

I didn't like the bold red and green either and this has been improved
in the mean time by choosing a bit less bright colors in the style sheet
:-).

Per the complaints, I saw only the ones on
http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29 
which were pretty harmless given the large user base Wikipedia has.

Disagreeing voices are usually the loudest and fastest. Don't forget all
the people who just silently use the cool new features and are happy
with them.

So keep up the good work!

_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Regarding the "change size" indicator in change lists

Rob Church
In reply to this post by Steve Bennett-8
On 30/12/06, Steve Bennett <[hidden email]> wrote:
> It's not reasonable to expect the average person to differentiate
> between "people who hack CSS and JavaScript" and "developers". I read
> wikitech-l, know what CSS, JavaScript, PHP and MediaWiki are, and
> still don't really get who is responsible for what, or what caused
> each visible change. How is the average Wikipedia user supposed to
> have any idea?

It is reasonable, however, to expect people not to go ape shit when
something happens that they don't like. It's furthermore reasonable to
expect that people will listen when we say, for instance, "that change
was done by one of your colleagues, not us - please go moan at them,
kthx".

> I don't really know how to improve this situation, but some sort of
> more visible process for improvements to MediaWiki and to the
> Wikipedia stylesheets might help. I don't consider Mediazilla
> "visible" at all.

If you're suggesting that we need to start asking for permission
before we commit every single improvement to the software, then you
can forget it; a lot of them have to be done to make the site more
stable.

As I've said before, I well appreciate that not every change benefits
everyone, but hopefully, none of them seriously hamper other users'
ability to continue to operate. I for one *do* solicit user opinion
when it comes to introducing major new things, or more likely, making
significant changes to existing processes - and I not only involve the
users, but I also check with Brion on a frequent basis that what I'm
doing is sane.

BugZilla is the bug tracking software, and it's where we track bugs
and feature requests. I'm sorry if it's not considered wholly visible
to all users, but it's not our fault no-one likes to link to it in,
e.g. the sidebar, or other visible places on Wikipedia. If people have
significant objections to something, we have that; and we also have
this mailing list, which is not private, and at least two public IRC
channels, which are not invite-only.

I strongly object to the assertion that the development team is in
anyway elitist or deliberately ignorant of user opinion; that is
simply unfair and completely untrue. If we didn't care about the user
base, we wouldn't actually be doing this.

> Hope this helps.

Not really; your attitude is rather what I was talking about in my last post.


Rob Church
_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Regarding the "change size" indicator in change lists

Ilmari Karonen
In reply to this post by Ligulem
Ligulem wrote:

> On 30.12.2006 10:53, Rob Church wrote:
>> [This is in response to all the bitching and whining that's taken
>> place since December 24th, on mailing lists, bug trackers, village
>> pumps and sleazy little back-alley forums...I apologise for the
>> crossposting. As ever, please feel free to forward this to other
>> appropriate parties or lists, but keep responses and/or discussion on
>> one.]
>
> I didn't like the bold red and green either and this has been improved
> in the mean time by choosing a bit less bright colors in the style sheet
> :-).

You know, while you do have a point about the colors, I can't help but
think the reason this has caused such a tempest in a teapot is that what
we have here is a concrete example of the proverbial [[bikeshed]].

(See also http://red.bikeshed.com/ and/or http://green.bikeshed.com/)

--
Ilmari Karonen
_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Regarding the "change size" indicator in change lists

Ligulem
On 30.12.2006 17:36, Ilmari Karonen wrote:
> You know, while you do have a point about the colors, I can't help but
> think the reason this has caused such a tempest in a teapot is that what
> we have here is a concrete example of the proverbial [[bikeshed]].
>
> (See also http://red.bikeshed.com/ and/or http://green.bikeshed.com/)
>

The colors are just fine now. Also the bolding for larger numbers is
very cool.

I thought everything is in harmony now. So I was a bit surprised by
Rob's post. But maybe I missed something.


_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Regarding the "change size" indicator in change lists

Jay Ashworth-2
In reply to this post by Rob Church
On Sat, Dec 30, 2006 at 03:37:45PM +0000, Rob Church wrote:
> I strongly object to the assertion that the development team is in
> anyway elitist or deliberately ignorant of user opinion; that is
> simply unfair and completely untrue. If we didn't care about the user
> base, we wouldn't actually be doing this.

And I wanna throw an oar in the water here, too...

40 million users...

10 developers?

Yeah, they're not gonna roll over for everything anyone says; there
*has* to be a filtering process or they'll all catch fire, like they
were dumb enough to dance for [[Sweet (Buffyverse)]].

That's going to look to the 'civilians' like the developers are copping
an attitude, sometimes; I see no way to completely avoid it.

But yes, people are going to be expected to filter themsleves through
the funneling system if they want to get stuff done.


Wikipedia probaly serves more 'users' with fewer developers than any
other OSS project I've ever seen... and I, for one, think they're doing
a pretty decent job...


Happy Next Year to all of them....

Cheers,
-- jra
--
Jay R. Ashworth                                                [hidden email]
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274
_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Regarding the "change size" indicator in change lists

Simetrical
In reply to this post by Rob Church
On 12/30/06, Rob Church <[hidden email]> wrote:
> BugZilla is the bug tracking software, and it's where we track bugs
> and feature requests. I'm sorry if it's not considered wholly visible
> to all users, but it's not our fault no-one likes to link to it in,
> e.g. the sidebar, or other visible places on Wikipedia.

Good grief, do you want us to get 250 bug reports a day?
_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Regarding the "change size" indicator in change lists

Rob Church
On 31/12/06, Simetrical <[hidden email]> wrote:
> Good grief, do you want us to get 250 bug reports a day?

On the one hand, we have the likelihood that it will not happen,
because Wikipedians now believe us all to be blood-sucking,
infant-eating monsters.

On the other hand, I believe in the power of WONTFIX.


Rob Church
_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Regarding the "change size" indicator in change lists

Steve Bennett-8
In reply to this post by Rob Church
On 12/31/06, Rob Church <[hidden email]> wrote:
> If you're suggesting that we need to start asking for permission
> before we commit every single improvement to the software, then you
> can forget it; a lot of them have to be done to make the site more
> stable.

Asking permission? No. But the current situation looks to me like:

1) Developers randomly without any warning make unannounced changes
that affect users.
2) CSS and Javascript hackers randomly without any warning make
unannounced changes that affect users.
3) Users get peeved due to their feeling of powerlessness, and not
knowing any better, blame developers or CSS/Javascript hackers at
random.
4) Developers consider this unfair.

How do you think this can be improved?

> BugZilla is the bug tracking software, and it's where we track bugs
> and feature requests. I'm sorry if it's not considered wholly visible
> to all users, but it's not our fault no-one likes to link to it in,
> e.g. the sidebar, or other visible places on Wikipedia. If people have
> significant objections to something, we have that; and we also have
> this mailing list, which is not private, and at least two public IRC
> channels, which are not invite-only.

And I guess the technical village pump
(http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29).

It's probably fair to say that the developers prefer Bugzilla and IRC,
and that users prefer wiki-based discussion, hence the yawning gap
between them.

Is there a running changelog accessible from Wikipedia perhaps? Some
centralised place where highly visible changes are logged?

> I strongly object to the assertion that the development team is in
> anyway elitist or deliberately ignorant of user opinion; that is
> simply unfair and completely untrue. If we didn't care about the user
> base, we wouldn't actually be doing this.

I would disagree with that assertion, too.

Steve
_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Regarding the "change size" indicator in change lists

Michael Wechner
Steve Bennett wrote:

>On 12/31/06, Rob Church <[hidden email]> wrote:
>  
>
>>If you're suggesting that we need to start asking for permission
>>before we commit every single improvement to the software, then you
>>can forget it; a lot of them have to be done to make the site more
>>stable.
>>    
>>
>
>Asking permission? No. But the current situation looks to me like:
>
>1) Developers randomly without any warning make unannounced changes
>that affect users.
>2) CSS and Javascript hackers randomly without any warning make
>unannounced changes that affect users.
>3) Users get peeved due to their feeling of powerlessness, and not
>knowing any better, blame developers or CSS/Javascript hackers at
>random.
>4) Developers consider this unfair.
>
>How do you think this can be improved?
>  
>

one could introduce a RTC (review then commit) process instead CTR,
whereas one could do the review on a "staging branch" in order to
be more efficient.

I am a developer myself and I also would prefer to commit every time
I do a change and consider it good, but I had to come to realize that
software in general is for people using it and hence the user is king/queen
and all good intentions are worthless if such a gap arises.

Just my 2 cents

Michael


--
Michael Wechner
Wyona      -   Open Source Content Management   -    Apache Lenya
http://www.wyona.com                      http://lenya.apache.org
[hidden email]                        [hidden email]
+41 44 272 91 61

_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Regarding the "change size" indicator in change lists

Simetrical
In reply to this post by Steve Bennett-8
On 12/31/06, Steve Bennett <[hidden email]> wrote:

> Asking permission? No. But the current situation looks to me like:
>
> 1) Developers randomly without any warning make unannounced changes
> that affect users.
> 2) CSS and Javascript hackers randomly without any warning make
> unannounced changes that affect users.
> 3) Users get peeved due to their feeling of powerlessness, and not
> knowing any better, blame developers or CSS/Javascript hackers at
> random.
> 4) Developers consider this unfair.
>
> How do you think this can be improved?

I don't think it can be.  Twenty-nine times out of thirty, step 3
never happens, and any further review processes or whatever will hold
up those twenty-nine times as well as (even more than) the last.
Generally the only criticism of developers is failure to institute
desirable things, not institution of undesirable things.  People are
happy with almost every change we make, and in fact, in this case
almost everyone was happy as well as far as I can see.

On 12/31/06, Michael Wechner <[hidden email]> wrote:
> one could introduce a RTC (review then commit) process instead CTR,
> whereas one could do the review on a "staging branch" in order to
> be more efficient.

Review by whom, the users?  How would you get the general body of
users to review even a few changes a week without making them live?
Real businesses and whatnot get around this by market studies and so
forth, but we don't have those.
_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Regarding the "change size" indicator in change lists

Rob Church
In reply to this post by Steve Bennett-8
On 31/12/06, Steve Bennett <[hidden email]> wrote:
> Asking permission? No. But the current situation looks to me like:
>
> 1) Developers randomly without any warning make unannounced changes
> that affect users.

We try to avoid doing this wherever possible - Tim in particular is
very good at alerting wikitech-l and wikipedia-l in advance of making
changes, e.g. to the blocking mechanism, earlier this year.

Sometimes, stuff slips through the net, and what seems major to users
is not so major to us.

> 2) CSS and Javascript hackers randomly without any warning make
> unannounced changes that affect users.

Not our fault, I'm afraid; discipline them accordingly.

> 3) Users get peeved due to their feeling of powerlessness, and not
> knowing any better, blame developers or CSS/Javascript hackers at
> random.

Not our fault.

> 4) Developers consider this unfair.

Well, it is!

> How do you think this can be improved?

Encourage administrators with poor aesthetic taste not to make changes
to the sitewide CSS without consulting users. I thought this was the
usual precedent on your wiki?

> And I guess the technical village pump
> (http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29).

No longer an official forum because it's not suitable for tracking bugs.

> Is there a running changelog accessible from Wikipedia perhaps? Some
> centralised place where highly visible changes are logged?

The Wikipedia Signpost has a "bugs, repairs and internal operational
news" slot each week, which includes software changes; I used to
maintain that bit before I disappeared in August, and Simetrical now
does a sterling job of it (although it's not necessarily fair to
expect that he will continue to do so), providing a damn sight better
description of most things than I ever did.

This isn't necessarily particularly official, either, but since you've
got a committer updating it...infer what you like. There's always the
Subversion log. Oh, but of course...non developers don't apparently
like opening their damn browsers.

> I would disagree with that assertion, too.

That's odd, because it seemed to me that your previous post perpetuated it.


Rob Church
_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Regarding the "change size" indicator in change lists

Ligulem
On 31.12.2006 19:07, Rob Church wrote:
> ... discipline them accordingly.

I'm sorry to say this, but it's this kind of language that makes
problems larger than they actually are.

People are sensitive to arrogance and it's sometimes a bit hard to find
out where the joke ends and the arrogance starts.

Yes, Mets501 was a bit bold adding the colors. But the colors are still
in effect, so it can't be that bad.

Repeat after me: Assume Good Faith.

And nobody is perfect.

Happy 2007!

_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Regarding the "change size" indicator in change lists

Rob Church
On 31/12/06, Ligulem <[hidden email]> wrote:
> I'm sorry to say this, but it's this kind of language that makes
> problems larger than they actually are.

Perhaps I could have worded it better, I do apologise.

> Repeat after me: Assume Good Faith.

I have done. I wasn't the one raising objections against anything on
the English Wikipedia, because I don't edit it - nothing there affects
me.


Rob Church
_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Regarding the "change size" indicator in change lists

Omegatron
In reply to this post by Rob Church
[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_remove_these_numbers_completely

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_really_implement_this_feature
  http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28perennial_proposals%29#A_better_description

http://bugzilla.wikimedia.org/show_bug.cgi?id=1307
_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Regarding the "change size" indicator in change lists

Rob Church
On 01/01/07, Omegatron <[hidden email]> 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
_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Regarding the "change size" indicator in change lists

Simetrical
In reply to this post by Omegatron
On 1/1/07, Omegatron <[hidden email]> 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.
_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Regarding the "change size" indicator in change lists

Anders Wegge Keller
In reply to this post by Omegatron
"Omegatron" <[hidden email]> 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.

--
// Wegge
<http://geowiki.wegge.dk/wiki/Forside> - Alt om geocaching
Bruger du den gratis spamfighther ser jeg kun dine indlæg *EN* gang.
_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Regarding the "change size" indicator in change lists

Jay Ashworth-2
In reply to this post by Omegatron
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
--
Jay R. Ashworth                                                [hidden email]
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274
_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
12