WebSeitz/wikilog
Overlapping Scopes Of Collaboration
Whenever any Form of Government becomes destructive of these ends, it is the Right of the People to alter or to abolish it, and to institute new Government, laying its foundation on such principles and organizing its powers in such form, as to them shall seem most likely to effect their Safety and Happiness.

(backlinks off) (map off)
(search off)
last edited by BillSeitz on Jun 21, 2008 1:38 pm

A big complexity in , as noted by , 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

'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. isn't any better, in the sense that you need to access the overall [Zope Management Interface] to do such things. 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 [MrX], and you write something nasty about him in that group blog, what happens if there's a good reason to include [MrX] in the group later? Do you purge the earlier nastiness? Can you even find such things reliably? 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.

A problem Jon doesn't address too much is matching 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 . To capture the other extreme of access to your entire enterprise, you could have an 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 () rather than a single file that can be distributed to peripheral members. I think this problem is not well addressed by environments like which make it easy to set up adhoc semi-disposable groups.

How might this be accomplished, using ?

For , see ZWiki:RegulatingYourPages. Also see some notes on page.

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

Scenario 1 - access to 1 wiki by outsiders

Focus is 1 team (maybe an entire ). They have a single . No individual -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 (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 . 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:

Resulting questions:

Scenario 2 -

...

See : | | | | | | | | | | | | | | | | |


 



Bill Seitz, fluxent at gmail dot com, Weblog