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.