According to the Signpost, since 2005, accounts less than four days old aren't permitted to upload files. Is that just for the English Wikipedia? At the Vietnamese Wikipedia, we regularly get deluges of improperly licensed uploads from new users in the past, and it'd be nice if this feature could give us time to let our new users know the rules. Here are three examples from today that strike us as problematic, given our current issues with sockpuppets:
http://vi.wikipedia.org/wiki/%C4%90%E1%BA%B7c_bi%E1%BB%87t:Log?user=Pinorisk... http://vi.wikipedia.org/wiki/%C4%90%E1%BA%B7c_bi%E1%BB%87t:Log?user=Pck-Tieu... http://vi.wikipedia.org/wiki/%C4%90%E1%BA%B7c_bi%E1%BB%87t:Log?user=TieuLiDo...
On 6/24/07, Minh Nguyen mxn@zoomtown.com wrote:
According to the Signpost, since 2005, accounts less than four days old aren't permitted to upload files. Is that just for the English Wikipedia?
Probably. If another wiki would like that option enabled, they should ask a sysadmin to enable it (after discussion shows that it's agreed upon). Theoretically it's supposed to happen via Bugzilla, but in practice you'll get much quicker results if you hang around in #wikimedia-tech harassing shell users until they change the setting.
On 25/06/07, Simetrical Simetrical+wikilist@gmail.com wrote:
Probably. If another wiki would like that option enabled, they should ask a sysadmin to enable it (after discussion shows that it's agreed upon). Theoretically it's supposed to happen via Bugzilla, but in practice you'll get much quicker results if you hang around in #wikimedia-tech harassing shell users until they change the setting.
Theoretically, BugZilla *should not* be the first port of call for users wishing to have this sort of thing, as in general, system administrators don't really trawl through it on a regular basis; there's a large number of open bugs requiring the attention of users with shell access, most of which are configuration settings.
My personal recommendation, then, for what it's worth, is for users to ask first in #wikimedia-tech (be persistent, but polite, i.e. don't flood the request every five minutes, and if it looks like there's an active problem, don't ask at that time), falling back to a ticket on BugZilla so we don't lose the issue if there's no response.
In the long run, it might be a far better idea to move these sorts of requests to an OTRS queue so the system administration team is more actively harassed about them. :P
Rob Church
On 6/24/07, Rob Church robchur@gmail.com wrote:
Theoretically, BugZilla *should not* be the first port of call for users wishing to have this sort of thing, as in general, system administrators don't really trawl through it on a regular basis
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.
In the long run, it might be a far better idea to move these sorts of requests to an OTRS queue so the system administration team is more actively harassed about them. :P
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 25/06/07, Simetrical Simetrical+wikilist@gmail.com wrote:
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
Certain configuration changes will require maintenance scripts and the like to be run, e.g. messing about with namespaces...it might not be the best idea in the world to expose this via the web interface.
Rob Church
On 6/24/07, Rob Church robchur@gmail.com wrote:
Certain configuration changes will require maintenance scripts and the like to be run, e.g. messing about with namespaces...it might not be the best idea in the world to expose this via the web interface.
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.
wikitech-l@lists.wikimedia.org