A little earlier, I talked about the possiblity of setting up a meta-wiki service where users could go, initialize a generic wiki area, and then limit/allow access to it based on their specific needs. After some research, I have discovered that this is a common need amongst wiki-ers out there; and the term used to describe this type of service is a wiki farm.
It just so happens that one of the (many) projects I am working on could use such a service. The project's goals are to improve the ways the large email lists are handled... more specifically towards students. We want to be able to better target sub-sets of students (undergrads, sophomores, grad students at Weatherhead, professional students at the Law school, etc.); we want more features embedded into the lists (i.e. leverage the feature set of lists.case.edu); we want emailers to the list to be able to use their standard email client; we want security so only approved messages go to the list; and we want it to work easily, smoothily, and expectedly.
The first part is better data. We need better, cleaner, more accurate, and more flexible data from the student systems to better identify the roles of a given student. From there, we can start creating the necessary groupings for these targetted emails; and we can start building out the infrastructure that will enable the rest of what we want to do. But first, the data needs to be taken care of.
So, as with any project, I began fleshing out the details of it on our internal wiki. Unfortunately, only people from ITS can access the internal wiki. This project involves persons from the Registrar, Admissions, and elsewhere (especially when we begin exploring the graduate and professional level students). Those people don't have access to our internal wiki. It would be nice if I could just generate a wiki out of thin air and then grant the dozen or so people on the project access to it.
I've had similar requests from others on campus asking if this was possible.
There are a couple of things upfront you need to think about. And, you may run into upgrade issues depending on how you handle it. And, you want to make sure the feature set of the wiki engine you choose is complete enough but not enormously complex (the simplest thing that could possibly work and work well). And, you want to make sure integration with the other large services (portal, blog, main wiki, email, etc.) are in place.
I'm just saying... it could be useful.
1 I just wanted to make an extra comment on the statement "the simplest thing that could possibly work and work well." I hate, and I mean I loathe, software that once you log in to it, it seems like you are staring at the dashboard of a 747. Too many options. Too many buttons that could be pressed. Too many widgets of marginal functionality cluttering up the area. You can't figure out what to do next. I like software that gets out of my way and helps me do stuff. I don't like software that throws its weight on you challenging you at every move "would you like to enable workflow processing?"; "please target the specific project area that your content is subscribed to"; "your project start date is greater than two weeks in the future, would you like to enable prophesy mode?"; "your document sharing filesystem has global change access available for your primary group's users, would you like to change the permissions?"; etc. Who has time to read 10+ page manuals to just share some basic content with some other people? If it doesn't work as easy as email, I am just going to stick with email; and if I were a betting man (and I am), I would say that I am not the only one.