Overlapping Scopes Of Collaboration

A big complexity in GroupWare, 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. ZopeCMF 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 Context 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 Intranet 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 (WikiForCollaboration Ware) rather than a single MsWord file that can be distributed to peripheral members. I think this problem is not well addressed by environments like Groove which make it easy to set up adhoc semi-disposable groups.

How might this be accomplished, using Wiki?

For Wiki For CollaborationWare, see Zwiki:RegulatingYourPages. Also see some notes on Collaboration Ware page.

Assume for now Wiki is the document store, most discussion happens via EMail.

Scenario 1 - access to 1 wiki by outsiders

Focus is 1 team (maybe an entire SmallCo). They have a single TeamWiki. No individual ProjectWikis.

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 HtmlEmail 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:

Scenario 2 -

...