A big complexity in Group Ware, as noted by Jon Udell, is adjusting the membership of the "group" you're talking to. Or, better, the memberships of the various groups of which you are a member.
http://www.oreilly.com/catalog/pracintgr/chapter/ch04_01.html
Radio Userland's use of Categories let you blog to multiple "sites", but leave it to the target web servers to control access, which is rarely something configurable by users. ZWiki isn't any better, in the sense that you need to access the overall Zope Management Interface to do such things. Zope CMF makes user controls more editor-configurable, which is a good thing.
A super-nasty conceptual problem is managing changes in group membership over time. If a "group" doesn't contain Mr X, and you write something nasty about him in that group blog, what happens if there's a good reason to include Mr X in the group later? Do you purge the earlier nastiness? Can you even find such things reliably? Jon Udell notes When you play the game of information hiding, it's easy to forget what has been hidden from whom, and why. And since information sources are never homogenous, you also have to think about federating different search engines.
as unnatural as it is for me, perhaps it's wisest to recognize that Information Wants To Be Public. So you should write clearly but in ways that won't embarrass you if your words get read by the "wrong" person.
A problem Jon doesn't address too much is matching Con Text to access. If you think just in terms of granular threads, you can stay fairly narrow in the scope you pick, or even use an EMail Nosy List. To capture the other extreme of access to your entire enterprise, you could have an Intra Net Vertical Search Engine which captures those small threads. But, back at the narrow level, how do you share context (background discussions, documents) with someone who's included in this thread but not normally part of the core group (e.g. a contractor, attorney)? This becomes especially problematic if context is contained in a bushy web of documents (Wiki For Collaboration Ware) rather than a single Ms Word file that can be distributed to peripheral members. I think this problem is not well addressed by environments like Gr Oove which make it easy to set up adhoc semi-disposable groups.
<hr>
How might this be accomplished, using Wi Ki?
For Wiki For Collaboration Ware, see RegulatingYourPages. Also see some notes on Collaboration Ware page.
Assume for now Wi Ki is the document store, most discussion happens via EMail.
Scenario 1 - access to 1 wiki by outsiders
Focus is 1 team (maybe an entire Small Co). They have a single Team Wiki. No individual Project Wiki-s.
The wiki contains various strategic planning pages, a page for each Team Member.
They're considering multiple vendors/partners for various roles. Each candidate has a page.
The Team Member-s have written a number of User Stories (1 per page) for business processes. (Some of those pages would spawn additional child/grandchild pages.) Some of these processes would involve integration between vendor activities and Team Member activities.
A given vendor role might be involved in many but not all of these User Stories. As a supplement/complement to a traditional RFP, it would be good for a potential vendor to read the relevant stories.
When I went through this in Aug'03 here's what I did:
I wrote a new Search Page variant which returned the full body of each returned node (since User Stories identified which role would perform them, I could use each role name as a search term)
- when I realized I was missing some grandchild pages, I went back and inserted the appropriate role names then re-ran the searches
a set of results would get dragged into an Html Email page
- I noticed that a couple pages were included that I didn't want to show, so I just deleted them from the email.
Wiki Name-s were links in the email, but if a message recipient tried to follow they'd be prompted for an id/password they didn't have.
Resulting questions:
<hr>
Scenario 2 -
...
<hr>