[Wikipedia-l] Server-side backlink redirects

[Tim Starling]

After a discussion on wikitech-l titled "bot approval request", we decided 
that perhaps it would be better if my bot were implemented on the server 
side, so that everyone could use it, and so that it would be relatively 
efficient. I offered to do the coding, on the condition that someone will 
block me if I try to make any ordinary edits -- I don't want Wikipedia 
totally taking over my life :)

Anyway, here's my proposal. I originally posted it on wikitech-l, but it 
drew no responses. What I'm suggesting is a significant extension to 
Special:Movepage capabilities.

------------------------------------------------

What we want to be able to do is:

1) Change a set of links pointing to a redirect, so that they're pointing to 
the real article
2) Change a set of links pointing to an incorrectly named image, to a new, 
correctly named image.

The second one was suggested by Tarquin on [[User talk:Timbot]]. Now the 
problem with this feature is that it has the potential to create excessive 
server load, especially if an edit war breaks out utilising it. My scheme 
below is intended to do the following things:

* Make it appear weighty and time-consuming, so that users won't do it 
frivolously.
* Make the smallest impact on the server possible while not wasting people's 
time.
* Make edit wars utilising the feature take up a minimum of server load, and 
to favour a conservative (changeless) outcome.

As a tentative short name, I suggest the "backlink redirect". It's a 
mouthful, it doesn't make much sense, but it's better than anything else 
I've come up with.

Here's my current vision for how it will operate:

On Special:Movepage, you now get an OPTION group looking like this:

(*) Move page only
( ) Make the page a redirect, and update all links so that they point to the 
new article
( ) Move page and update links

Any logged in user has access to these options. If the user selects the 
second or third option, a new thread is created on the server, set to low 
priority -- low enough that it might take an hour or more during peak times 
to fix a large set of articles. This new thread does the following:

* Updates Wikipedia:BacklinkRedirects (or related DB table) to indicate that 
a backlink redirect has started. This appears on RC.
* Starts updating the links, one at a time. Changes do not appear on RC.
* After it finishes updating each article, it checks to see if someone has 
clicked on the "cancel" link in Wikipedia:BacklinkRedirects. If so, it 
reverts its changes and stops, indicating this on RC and 
Wikipedia:BacklinkRedirects.
* Once it has finished, it updates the table related to 
Wikipedia:BacklinkRedirects to indicate that the job is now over. This does 
not appear on RC.

The job stays there on the lower half of the page for all time, with some 
method of accessing multiple pages of them. Anyone can revert such completed 
jobs. Reversions of complete jobs are handled at the usual thread priority 
(arguable, I could be wrong). Articles which have changed since the initial 
update are, of course, not reverted.

As you can see, with this scheme, even an edit war over a huge set of links 
will create little server load in peak times, as long as both sides of the 
fray watch Wikipedia:BacklinkRedirects vigilantly.

-- Tim Starling.


_________________________________________________________________
MSN Instant Messenger now available on Australian mobile phones. Go to  
http://ninemsn.com.au/mobilecentral/hotmail_messenger.asp