(At the risk of becoming tedious to people not interested in the Alabaster project — sorry about that.)
Release 8 incorporates a little new material, and also revises some of the existing material a little for consistency. It is slightly problematic when there are two very similar dialogue quips that lead the player in very different directions; I’ve tried to resolve that (especially the feedback about what happens when you look into the mirror) by making the later-submitted of the two quips into a follow-up by Snow White (ie, she volunteers more information later in the conversation). This actually makes it more likely that the player will encounter both bits of information.
There are also some minor cosmetic cleanups — I’ve made Alabaster a little pickier about what quips it will suggest to the player, in order to reduce some of those long “You could…” lines to more topical results. (It is in fact possible to customize the wording of the suggestion lines quite a lot, but that’s beyond the scope of the collaborator interface at the moment, and also in my own experience it’s the kind of polishing that is best done once most of the conversation is written and you can really start to worry about presentation.)
In general, I am finding that the role of code-assembler is less obviously distinct from the role of editor than one might think; that is to say, there are a certain number of judgment calls involved about how to put things together consistently from a code perspective, and those lap over into judgment calls on more aesthetic points (like “this code could just as well be a follow-up quip”, or even “these two quips seem to contradict one another”). At the same time, bringing in the new stuff so far is not really that hard; I’ve spent a good bit of time on this project today, but it has almost all been on adjustments to the core system based on user feedback, not effort just to reconcile the submitted code. So that’s encouraging.
People have suggested that it would be neat to have an arrangement where a game could “recompile itself”, or be hosted on a server where players could recompile it after each playthrough, and thus grow organically. My present experience suggests that at the very least such an arrangement would need to offer people the ability to come in and tweak the code later by hand, in order to reconcile inconsistencies, fix typos, and otherwise polish up.
Emily Short's Interactive Storytelling 
This is fascinating. Are you thinking of packaging any of this as an extension?
Yeah, that’s the plan — this project is a way of testing out the usability of part of the package.
The conversation system currently consists of two main extensions: “Threaded Conversation” (which does the modeling) and “Conversation Builder” (which does the interface for creating new conversation). The idea is that the author can use Conversation Builder to draft conversation, then comment it out of the final game, leaving only Threaded Conversation in the release. There’s also a fair amount of drafted documentation to go with all this, and a couple of things I’ve written as examples. The largest of these has turned into a major WIP, but that’s actually a good thing. I want to pound on the core system and ensure it’s up to handling a sizable game (and that the performance doesn’t degrade horribly) before I offer it to people to try to use themselves.
The current project is partly a way of beta-testing Conversation Builder to find out whether it’s flexible enough for collaboration work, and to get out some of the kinks in the interface it would present even for an individual author. I’ve been using it for a while, so I’m used to it, which means that I’m no longer able to see the ways in which it’s somewhat inconvenient. This feedback has been hugely helpful.
(The fact that Glulx interpreters on some platforms don’t line-wrap input is a bit of a blow — Zoom and the Inform IDE do so beautifully, so I assumed everyone else’s interpreters would too. [Which is why we test!] I’m trying to think what is the best way around this.)
Yeah, the lack of wraparound on WinGlulxe is annoying. I resorted to copying and pasting from notepad (which, to be fair, is what I do with pretty much everything I write ever, including shopping lists).
The best solution to interpreters not line wrapping is to hassle the people behind them (i.e. me for WinGlulxe) to fix it!
Let’s hassle you, then, DavidK!
I remember I noticed this line-wrap problem of WinGlulxe in games like Ekphrasis, in which the text window is smaller because of the graphics. It wasn’t a problem for most of the commands I typed, but it definitely was for my notes (lines beginning with “*”): when they were long, I had to either type part of them blindly or to press return (and type “*”) many times.
Sure, it wasn’t unbearable, but still a bit annoying. So, I agree it should be fixed, if possible.