IMHO, this isn't a matter of either-or, but of concurrent development along 2 related tracks:
You're right, it doesn't have to be either-or.
[snip] It would be good to have (1) ASAP. There's no reason that people who are interested in (2) have to be interested in (1) or vice versa.
I agree that this makes sense, and if you did this it wouldn't be a problem whatsoever. However, I think that, with rapid prototyping and whatnot, we can actually get an original, minimal, working wiki, and build from there. The database design will go together quickly, some kind of architecture can go up quickly (scaffolding, if you will), and then development on the most important, essential parts will come first. Then, as the wiki is being used concurrently with the development of it, you have a good deal of immediate feedback on what's wrong and what needs to be changed. But, really, that's my idea of how it should be done: I am neither the one with the money, nor the one capable of doing it all on my own. I just really loathe the idea of having to go from the one to the next, when the latter will do what we need just as well with a little bit of effort. It's important to start the project with a certain goal for quality, but doing it rapidly. But, as of right now, nobody's really been thinking the same (or those that have haven't spoken up) so I can't get a community moving on it just yet. And, personally, I've been pretty swamped with work so learning Perl6 has been on the backburner (along with Haskell and Scheme, unfortunately). M.T.
