"Aryeh Gregor" <Simetrical+wikilist(a)gmail.com> wrote in message
news:7c2a12e21001191832g207d8f08ud4dc84f674d25e5d@mail.gmail.com...
On Tue, Jan 19, 2010 at 5:11 PM, Platonides
<Platonides(a)gmail.com> wrote:
If the admin wants to allow it, he can enable it
or publish a list of
pages to watch on the Vilalge Pump.
Suppose you open it. Who is more likely to start using it? People with
too few watched pages or vandals?
Since there's no effective way to watch a million pages, probably it's
not useful, no. I didn't realize quite how many such pages there
were. On the other hand, why do we make the page available at all if
it's useless to legitimate users? It's an expensive query AFAICT, so
if it's useless then we probably shouldn't bother generating it.
The page is essentially useless on enwiki at least. Despite a concerted
effort a while back, no one has ever even seen the 'B's...
If you make a
change on default configuration that forces users to
manually set it back to the previous one, you shouldn't have changed it.
If most sites want to change the default, that's a hint that it might
be a bad default, yeah.
I'm not seeing any evidence that most, many, or even some sites want to
change this default. I'm seeing a group of MW developers talking about
wanting to change it.
On Tue, Jan 19, 2010 at 7:49 PM, Happy-melon
<happy-melon(a)live.com> wrote:
I'm sure I'm not the only one to see the
monstrous hypocrisy in that
compared to the hoops we'd make the communities jump through if they
wanted
to propose *exactly the same change* from their end.
What? What hoops? We require evidence of community agreement, that's
all. enwiki happens to have a pathological and poorly-defined process
for making config change requests, but that's its requirement, not
ours. As far as sysadmins are concerned, if a community decides that
a three-day majority vote is enough, they'll change it on that basis
AFAIK. Small wikis might just have a sysop request it after a brief
discussion on the local village pump.
It might take a while for a shell user to get around to doing the
change, but that's a separate issue.
This is all true, and I think that's one of the most apt description of
enwiki's approach to the whole issue I've seen for a long while. But that
doesn't change the fact that if I filed a bug asking to set
$wgGroupPermissions['*']['unwatchedpages']=true on xxwiki, pointing to a
discussion where three yywiki editors mused that it would be a good idea, it
would be *immediately* LATER'd asking for a demonstration of consensus
*within that community*. Whatever the cause, there is hypocrisy there.
Fiat *is*
required
when a default is *first chosen*, that's certainly true, and talking to
the
communities before introducing *new* features is indeed the exception
rather
than the rule. If Special:UnwatchedPages was a new feature we'd be
perfectly free to pick a target usergroup out of a hat. But this is a
proposal to change an already existing feature, a configuration change
that
would be happily LATER'd without a clear consensus from the community in
question if it came up the other direction. So I totally disagree: for
feature **changes**, we most certainly do look to the communities to take
the lead.
I don't follow at all. Developers get to decide on defaults when we
introduce a new feature, but once a feature already exists then it's
locked in stone forever? That's certainly not how things work in
practice. We've made significant changes to existing features in the
past without asking communities first. Ditching Makesysop/Makebot in
favor of better core userrights comes to mind, but I'm sure there are
better examples.
There are; Make(Bot|Sysop) were deprecated everywhere I've looked before
they were disabled. In a very real sense, the sysadmins *did* consult the
people who would be affected by the change - the relatively small group of
WMF crats and stewards - before making the change. In a similar vein would
be the deprecation of Oversight: new functionality was deployed by fiat in
the form of RevDeleted, but disabling Oversight itself, despite being a Very
Good Thing from the PoV of "interpretation of our goals and the projects'
needs", has been delayed because of consultation with those who actually use
the functionality and would be affected by changes in it.
The model is always that the developers/sysadmins
decide on global
defaults based on their knowledge and interpretation of our goals and
the projects' needs, and projects can later request changes for
themselves. Both for new features, and existing features. We don't
ever hold up global development/system administration decisions on
community consensus. It would be impossible even if we wanted to --
how do we go about getting consensus from several hundred wikis? Do
we have to have a poll on Meta? Or is only enwiki supposed to count?
Why should changing an existing feature be any different from
introducing a new one?
FlaggedRevs? Rollback? I guess the real position is neither black nor
white, and neither of our blanket statements are valid. My original point
was that this is a particularly bad time to do this, because this is a point
of contention on enwiki in particular. A better way of phrasing it would be
to say that the communities' opinions are relevant but not binding on
sysadmin actions; where the area is more contentious, the community's
thoughts should be given a greater prominence. Raising this issue on enwiki
at the moment would be explosive, and making a change *without* raising the
issue equally so.
--HM