First off, I'd like to welcome Swap and Dreamvirus to the coding team. They've both got good ideas and talent, and I'm looking forward to seeing what they come up with.
XP, Levels and Coolage
The biggest changes since my last Root Log actually happened around the end of October - mauler and I re-did the Everything2 Voting/Experience System, a change that was discussed at length many months ago, and anticipated in a series of Editor Logs. Although my own inaugural Lead Developer Ed Log avoided making too many specific commitments for coding projects, it was explicit about my intention of 'retiring the Honor Roll as soon a possible, to replace it with something that rewards well-received writing without penalising less successful experiments'. I'm pleased with the new system, which achieves those goals while remaining far simpler and more elegant than the one(s) it replaced, but I'd still like to re-iterate that the details of it will be kept under review, and it wouldn't be surprising if a few tweaks were made around the start of 2009.
The Site Trajectory node now shows the ratio of cools to new writeups, which had ranged between about three and five for the last few years, heavily diluting the power of the C! to bring new writeups to the attention of anyone, defeating much of their point. This ratio has now dipped below 2 for the first time in more than four years, but with THE IRON NODER CHALLENGE ongoing, it's impossible to guess how much of that is down to the reduced C! supply brought about by the new XP/levelling system, and how much is down to us just getting twice as many writeups as we're used to seeing - so it won't be till December that we can really start to gauge where we stand. Incidentally the Site Trajectory also bunches things by calendar month now, thanks to in10se, rather than just 'months from the present'.
Headers, Footers and Bookmarking
The old Writeup Settings page used a fantastically versatile but largely baffling system for customising the headers of writeups. This was never really desirable, and adding customisable footers into the mix only made it worse, so I put together a vastly simplified Writeup Settings page, but kept a version of the old one online for people who crave the power it gave them over precise positioning of everything.
The new version has all the interaction options - voting buttons, message boxes, cools and so on - in the writeup footer by default, since the idea is that you probably shouldn't be using those things until after you've read the writeup. Some of the fiddlier options are gone from the new settings because they just didn't seem necessary, while social bookmarking buttons are now turned on by default and there's an option to display the hit counter I added last month. I did play with the idea of using radio buttons to allow people to select whether they wanted things in their headers, footers, or not at all, but in the end I didn't think the added complexity of the interface was worth it. I'm open to feedback on this, though.
Speaking of adding complexity to the interface, I also added checkboxes in User Settings for people to opt out of sending or receiving social-bookmark notifications, or to entirely opt out of showing the buttons on their writeup. Some people love opting out of stuff, I've noticed.
Staff Stuff
(which may not be of any interest to most of you)
The staff's 'Master Control' nodelet was always inserted automatically at the top of the page by the code in nodelet meta-container, preventing it from being moved down the page like any other nodelet. I found what seems to be a pretty elegant way of simply inserting the nodelet into the user's VARS if it isn't there already, although one editor has complained of having two copies now, which I think is caused by having Nodelet Tabs turned on in Nodelet Settings.
Another change that only the staff will notice directly is that I've changed the admin toolset to show 'Edit Code' rather than 'Edit Node' for most code-based nodes. This takes us to pretty much the same view of a node that members of edev will get, only we also have the option to apply our own patches. The point of this change is to allow at least rudimentary version control, keeping track of changes and making it easy to undo them. This means that almost all changes are now visible in Patch Manager for anyone interested - the only big exceptions are test nodes (where we try stuff out before inflicting it on the public) and text nodes (where any code included is pretty trivial).
One last staff-only change, which will be noticed directly by even fewer people, is that the error logs now make a note of which node generated a given error, which was entertainingly absent from the reports until a few days ago. I've been generally picking at the error logs to reduce the number of errors generated (many of which otherwise go unnoticed) so this is largely for my own benefit.