On Tue, Jan 19, 2010 at 5:11 PM, Platonides <[email protected]> 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. > 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. On Tue, Jan 19, 2010 at 7:49 PM, Happy-melon <[email protected]> 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. > 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. 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? There are good reasons to not allow all users to use UnwatchedPages (and at this point they've convinced me), but the fact that we haven't consulted the communities is not one of them. _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
