Keith M Wesolowski wrote: > The only question here is one of granularity - and so far feedback has > been overwhelmingly in favour of fineness.
Agreed >> So this seems to suggest that we need a path for "promoting" projects to >> be communities once they have reached some threshold. > > Right, although I don't think promotion is the right word - a > Community Group forms organically around the project's artifacts. > Certainly the original project team is likely to form the nucleus of > the new Group, but it would be expected to be a subset of it, just as > any follow-on projects the original team does would be a subset of the > Group's total activities. Promotion also suggests that being a > Project is a second-class status, one assigned to less important or > less desirable work or people. That's not true at all - and instead > we probably have to return to the older idea that a project has a > limited (though not necessarily timid) set of goals and a finite life > span during which it achieves, or fails to achieve, those goals. I was thinking in terms of "core contributor"-ship. I didn't mean to say that Projects are second-class citisens, clearly they aren't since Projects are the entity that are allowed to have SCM repositories - whereas Communities can't. The problem is projects that don't have a finite life span. e.g.: my hypothetical Whizzix distribution. If Whizzix wants to conduct all its work on opensolaris.org - it's never going to end, it will be infinite. So I suppose at some point maybe it gains enough traction that it becomes a community. But what if it doesn't? What if it has a very very steady existence consisting of 2 or 3 determined individuals. Is that considered enough traction to be deserving of a community? What about projects that never integrate into an existing consolidation? The "Live Media" project could conceivably be ongoing without integration or a finite life span. >>From an implementation perspective, it's likely to be helpful for our > infrastructure to support continuity. But that doesn't mean we need a > process for promotion - the existing Group formation process offers us > the right set of tests to determine whether there in fact exists a > viable community interested in extending, using, and evangelising the > new artifacts. > >> So maybe we give up the idea of uniformity in classification of >> communities/projects - and say *everything* starts as a project until it >> reaches said threshold at which point it becomes a community with >> governance? It lends itself to more organic growth, which seems to be >> the feedback I've been receiving here. > > Yes, except that "governance" isn't the distinction between projects > and Groups - project teams govern themselves just as Groups do, albeit > less formally. The only governance distinction is that Groups name > Core Contributors who have additional privileges in the wider > community. And since every project will be sponsored by one or more > Groups we expect to track and nurture them, successful project teams > will be recognised for their contributions. Unless they are sponsored by a defunct community who doesn't grant recognition. > One of the undercurrents here is that although Groups are large and > broad enough to warrant a more formal governance process, they should > not be so large and diversely composed as to engender continuous > internal conflict (and thus the need for more governance). Yup. cheers, steve -- stephen lau // stevel at sun.com | 650.786.0845 | http://whacked.net opensolaris // solaris kernel development
