[Wikipedia-l] Recent changes page

[lcrocker at nupedia.com]

This is a general reply to a couple of mails relating to the new 
software's Recent Changes page.

It was a guiding principle of my new design that it be *fast*.  I 
think the performance of this page is critical to usability.  Speed 
is a feature too.  So if you're going to suggest features, make sure 
they are either (1) not hindrances to performance, or (2) really, 
truly, vitally necessary.

1) If you wan't 1000, 2500, or more changes, you can do that by 
editing the URL directly.  They are removed as links from the page so 
that robots won't spider them, putting a load on the server.  The 
occasional human use shouldn't be a problem.  If enough people 
complain, I might consider putting 1000 back, though the need for it 
might be supplanted by other features mentioned below.

I'd also be happy to put in some shorter time limits: currently the 
shortest is "1 day", but I can see that it might be useful to have, 
say, "3 hours", "6 hours", and "12 hours".  This would make it 
possible to extend the limit to a bigger number and still have a 
reasonably fast query, because the time limit really trims down the 
result set and makes things fast.

Along those lines, I've had enough requests to restore the "show only 
new changes" feature, and that feature can actually speed up the 
database query, so I plan to put that back.

Yes, it is confusing that the "diff" link on early edits shows a 
recent diff.  I agree that this is a bug, and I will fix it as soon 
as I can figure out a good method.  This one just happens to be 
trickier than it looks, but it's not a performance issue, so I'm all 
in favor of doing it right.

Any other desired feature that limits the set of pages returned is 
also likely to get a favorable hearing.  Maybe a feature that shows 
only pages beginning with a certain letter or string, pages edited by 
certain people, etc.  If we can design a reasonable interface for it, 
these kinds of changes must meet a lower burden of acceptance because 
they will generally be fast.

The tricky one is consolidating multiple edits to a page into one 
entry on the Recent Changes page, the way UseMod and Phase II did.  
This is a big performance hit.  Perhaps a later redesign of the 
database would make it more reasonable, or perhaps a new 
implementation will come to mind that cures the problem, but for now 
I just don't want to burden the server with extra work for what is, 
to me, a cosmetic change that doesn't add functionality.