"Aryeh Gregor" <simetrical+wikil...@gmail.com> wrote in message news:7c2a12e21001191832g207d8f08ud4dc84f674d25...@mail.gmail.com... > On Tue, Jan 19, 2010 at 5:11 PM, Platonides <platoni...@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-me...@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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
