WebSeitz/wikilog
z2006-03-31- Boyd Base Camp Unjoined Identity
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 Apr 8, 2008 11:34 pm

on the broken model at - he needs a separate [ID] there for every group his collaborates in. Many times in the past few months, I have started a project up with a group, or groups, who like me are already using Basecamp. The problem that arises: Whose Basecamp implementation to use? I would, of course, rather manage projects that I am involved with in my own Basecamp instance, while the others have the same perspective. But what happens, quickly, is that I have a bunch of memberships in other Basecamp projects, which do not collate into a coherent single view. Basecamp lacks the notion of federating project work. While I can invite my pal, [Greg Narain], to join a project I am running, Basecamp is only willing to consider Greg as another individual, not as the owner of his own Basecamp instance. As a result, Greg must login to my instance to participate, and the status of the project does not show up on his dashboard. Image the nightmare of tracking multiple -s/-s.

is just as bad, though youi're probably less likely to be a member of multiple "spaces". But we needed separate spaces for 2 very different markets (different custom fields, forms, use of , etc.), and the few people who needed access to both spaces needed to use separate addresses (which is the there) for each space! And of course, if you actually needed to manage events in both sets of leads, you'd go bananas. I have no idea how that would work if you were using their integration or custom synch system...

See : | |


 




Bill Seitz, fluxent at gmail dot com, Weblog