On 6/24/07, Rob Church <robchur(a)gmail.com> wrote: Well, no, in practice, but *theoretically* it makes the most sense to use Bugzilla for it. It used to be okay when Brion went through and did all of them every once in a while, but he's a busy man, and despite River's semi-recent plow-through of most of them, the number of open shell bugs has crept back up to 72. Nah, there are plenty of ways to harass the system administration team. When you have so few actual employees, though, your mileage may be limited. In any case, the clear answer to this is just to allow configuration of namespaces and (some routine) permissions from within the wiki interface and allow bureaucrats to do it through the actual interface of the site, like on every other Web package in the universe. Then we wouldn't have to bother the system administrators about every damn thing. Of course, that's something anyone with commit access can fix, so I'm not going to be too critical about this whole thing. :P

On 6/24/07, Rob Church <robchur(a)gmail.com> wrote: It goes without saying that all such options would have to be tweaked until they worked without breaking things, just as the rest of the software does. If something is only available to sysadmins anyway, of course we're not going to bother putting in safety catches and padded walls, because a) they presumably know what the script actually does on the level of the backend and have a very real idea of what any issues should be with running it; b) trust that the tool will not be used maliciously is absolute, because sysadmins who were inclined to go on a rampage would have vastly more destructive paths open to them anyway; and c) if they break something, they should have the skills and access to fix it. So currently, changing namespaces looks like 1) Edit LocalSettings.php. No checks whatsoever; if you make a typo, you just screwed up the wiki. 2) Run namespaceDupes.php or whatever to move a bunch of pages around. If there are conflicts, say because you're recycling a namespace ID because things like IDs aren't transparent to you, oh well, move them somewhere and hope they get sorted out. If it were done through the GUI, it would be more like 1) Add the namespace through a nice shiny GUI, no possibility for significant mistakes. Hit Save. 2) Bring up a confirmation dialog reiterating the exact namespace name chosen and giving the number of pages that will be automoved to the new namespace. (Very fast, indexed SELECT.) 3) Add the new namespace to the database, and immediately (preferably within the same transaction) move all appropriate pages. (Very fast, also indexed.) 4) Present "mission accomplished" message. All of that is fast, easily understandable, and reversible in the case of error. It's no more dangerous or problematic than allowing sysops to delete pages. Even if some rogue bureaucrat (and we've gotten single digits of rogue sysops out of a couple thousand, whereas we only have maybe fifty or sixty bureaucrats/stewards across all projects, and they're quite a bit more heavily screened) decided to move everything to the main namespace, it could be moved back immediately, since logically the pages would keep their prefixes in such a case. Basically the same principles apply to various other options. The only thing that we really need to worry about, as always, is reversibility. If we have that, it doesn't really matter what happens, which is the entire principle of wiki. Either way, it's ridiculous to have shell users make every single routine change to the wiki's setup, especially when it frequently takes them months to find time for it.