There are a couple of other complications here. First, we must recognize that a single person may very well be a part of not just one community but many distinct communities within a single dotLRN installation. To make matters even more complicated, each community may have distinctly different rules and norms.
As an example, let me describe a situation I ran into while I was the instructional designer on one online class where a prominent professor taught his investment analysis ideas to some employees at a large financial services firm. The class involved group project work that necessarily included data about customers and possibly new and proprietary business ideas that came out of groups. To make matters more complicated, the professor was occasionally hired by the firm's competitors as a consultant and wanted to be sure (to his credit) that he didn't inadvertently walk away with an idea that emerged from the class which could be fairly considered property of the firm.
As a result, we decided to create subgroup workspaces where even the professor did not have access. The students themselves decided what could be shared with the class (and the professor) and published sanitized versions of their ideas and examples to the class. In turn, there was another set of rules for what could go from the class to the outside world.
Communities are fundamentally ideosynchratic based on the needs of their members. Therefore, the balance between sharing and privacy is also fundamentally ideosyncratic. We need to come up with a range of use cases and make sure our architecture makes it easy to accomodate those use cases.
