From benr at cuddletech.com  Wed Mar  8 01:25:46 2006
From: benr at cuddletech.com (Ben Rockwood)
Date: Wed, 08 Mar 2006 01:25:46 -0800
Subject: [cab-discuss] The Constitution and Organizational Structure
Message-ID: <440EA31A.5030802@cuddletech.com>

In the Feb 22nd CAB call a number of issues relating to the creation of 
the constitution were brought up.  Of them all, the impending 
restructuring of communities and projects was particularly interesting 
to me.  While the approved charter doesn't require that the constitution 
outline the organizational structure of OpenSolaris, I think that part 
of the purpose of a constitution is to describe just that.  Keith's 
point that the constitution/governance should be "implementation 
independent" is well taken, but I think that until we form a picture of 
what the organization will look like we will have a difficult 
determining how it should be governed.

It would seem to me that the consensus is to reorganize OpenSolaris as a 
small number of high-level "communities" (such as Storage, Networking, 
Evangelism), beneath which would be a variety of "projects" (such as 
ZFS, SMF, Dtrace, SVM).  This model is effectively already in place but 
isn't enforced and a large amount of consolidation can be done with the 
existing 39 communities.

I think its time for discussion of structure and delegation to begin in 
the context of a constitutional framework.  I think that having a CAB 
consensus on structure will more easily serve as a base reference by 
which to address nearly all the assigned items of inclusion outlined in 
the charter. 

Once that structure can be agreed upon, we can discuss more clearly the 
various roles that fit within that framework and the rights and 
responsibilities that those roles entail.

Thoughts?

benr.


From sch at eng.sun.com  Wed Mar  8 10:07:07 2006
From: sch at eng.sun.com (Stephen Hahn)
Date: Wed, 8 Mar 2006 10:07:07 -0800
Subject: [cab-discuss] The Constitution and Organizational Structure
In-Reply-To: <440EA31A.5030802@cuddletech.com>
References: <440EA31A.5030802@cuddletech.com>
Message-ID: <20060308180707.GB158700@eng.sun.com>

* Ben Rockwood <benr at cuddletech.com> [2006-03-08 01:31]:
> In the Feb 22nd CAB call a number of issues relating to the creation of 
> the constitution were brought up.  Of them all, the impending 
> restructuring of communities and projects was particularly interesting 
> to me.  While the approved charter doesn't require that the constitution 
> outline the organizational structure of OpenSolaris, I think that part 
> of the purpose of a constitution is to describe just that.  Keith's 
> point that the constitution/governance should be "implementation 
> independent" is well taken, but I think that until we form a picture of 
> what the organization will look like we will have a difficult 
> determining how it should be governed.
> 
> It would seem to me that the consensus is to reorganize OpenSolaris as a 
> small number of high-level "communities" (such as Storage, Networking, 
> Evangelism), beneath which would be a variety of "projects" (such as 
> ZFS, SMF, Dtrace, SVM).  This model is effectively already in place but 
> isn't enforced and a large amount of consolidation can be done with the 
> existing 39 communities.
> 
> I think its time for discussion of structure and delegation to begin in 
> the context of a constitutional framework.  I think that having a CAB 
> consensus on structure will more easily serve as a base reference by 
> which to address nearly all the assigned items of inclusion outlined in 
> the charter. 
> 
> Once that structure can be agreed upon, we can discuss more clearly the 
> various roles that fit within that framework and the rights and 
> responsibilities that those roles entail.
> 
> Thoughts?

  I think it's a valid way to approach the problem, although I don't
  agree that there is consensus on restricting the number ("small") or
  nature ("high-level") of the communities.  In fact, a
  contributor-oriented membership would not necessarily lead to high
  level communities like the examples you mention.  

  As an example, if we restrict the communities, then we end up
  restricting the types of contributor we are willing to recognize.
  Another way to look at that is that wide definition communities, like
  Storage, need to be able to identify many kinds of contributor
  (Storage driver developer, Storage management software developer,
  Storage best practice author, Storage helpful sysadmin, Storage
  visionary, ...).  Whether such distinct roles would want to be in a
  single community--they go to different conferences--may be too severe
  a constraint.

  Should the existing communities to be able to block the creation of
  new communities?

  - Stephen

-- 
Stephen Hahn, PhD  Solaris Kernel Development, Sun Microsystems
stephen.hahn at sun.com  http://blogs.sun.com/sch/


From benr at cuddletech.com  Thu Mar  9 01:13:55 2006
From: benr at cuddletech.com (Ben Rockwood)
Date: Thu, 09 Mar 2006 01:13:55 -0800
Subject: [cab-discuss] The Constitution and Organizational Structure
In-Reply-To: <20060308180707.GB158700@eng.sun.com>
References: <440EA31A.5030802@cuddletech.com>
	<20060308180707.GB158700@eng.sun.com>
Message-ID: <440FF1D3.2020606@cuddletech.com>

Stephen Hahn wrote:

>* Ben Rockwood <benr at cuddletech.com> [2006-03-08 01:31]:
>  
>
>>In the Feb 22nd CAB call a number of issues relating to the creation of 
>>the constitution were brought up.  Of them all, the impending 
>>restructuring of communities and projects was particularly interesting 
>>to me.  While the approved charter doesn't require that the constitution 
>>outline the organizational structure of OpenSolaris, I think that part 
>>of the purpose of a constitution is to describe just that.  Keith's 
>>point that the constitution/governance should be "implementation 
>>independent" is well taken, but I think that until we form a picture of 
>>what the organization will look like we will have a difficult 
>>determining how it should be governed.
>>
>>It would seem to me that the consensus is to reorganize OpenSolaris as a 
>>small number of high-level "communities" (such as Storage, Networking, 
>>Evangelism), beneath which would be a variety of "projects" (such as 
>>ZFS, SMF, Dtrace, SVM).  This model is effectively already in place but 
>>isn't enforced and a large amount of consolidation can be done with the 
>>existing 39 communities.
>>
>>I think its time for discussion of structure and delegation to begin in 
>>the context of a constitutional framework.  I think that having a CAB 
>>consensus on structure will more easily serve as a base reference by 
>>which to address nearly all the assigned items of inclusion outlined in 
>>the charter. 
>>
>>Once that structure can be agreed upon, we can discuss more clearly the 
>>various roles that fit within that framework and the rights and 
>>responsibilities that those roles entail.
>>
>>Thoughts?
>>    
>>
>
>  I think it's a valid way to approach the problem, although I don't
>  agree that there is consensus on restricting the number ("small") or
>  nature ("high-level") of the communities.  In fact, a
>  contributor-oriented membership would not necessarily lead to high
>  level communities like the examples you mention.  
>
>  As an example, if we restrict the communities, then we end up
>  restricting the types of contributor we are willing to recognize.
>  Another way to look at that is that wide definition communities, like
>  Storage, need to be able to identify many kinds of contributor
>  (Storage driver developer, Storage management software developer,
>  Storage best practice author, Storage helpful sysadmin, Storage
>  visionary, ...).  Whether such distinct roles would want to be in a
>  single community--they go to different conferences--may be too severe
>  a constraint.
>  
>
As you point out, there are too many possible contribution roles to set 
them in stone, therefore I think that a prudent approach is to place the 
authority to name someone as a "member" or "contributer" with the 
leadership of a given high level community.  This approach, however, 
assumes that the leadership of each community is, a) qualified, b) 
engaged, and c) aware.  Honestly, these attributes may be harder to 
enforce than they sound.

I think the key is delegation of authority.  In a sense, we can compare 
the structure I'm envisioning as similar to a traditional organizational 
entity such as a country or corperation.  The OGB acts as a federal 
government, communities act as states, and projects as counties/cities.  
In such a case, its the community that oversee most matters, using power 
granted by the OGB and constitution.  They select their own membership 
since they have a better understanding of who and what they are doing.  
The only trick is to avoid turning the whole thing into a big bureaucracy.

>  Should the existing communities to be able to block the creation of
>  new communities?
>
No.  I think that only the OGB should have the authority to block a new 
community, and even then, the process should be initiated by someone 
outside of the OGB, namely a leader from the disputing community.



Maybe some of these ideas are good, maybe not, but its important that we 
get discussions under way and keep this effort moving.

benr.


From sch at eng.sun.com  Thu Mar  9 09:53:04 2006
From: sch at eng.sun.com (Stephen Hahn)
Date: Thu, 9 Mar 2006 09:53:04 -0800
Subject: [cab-discuss] The Constitution and Organizational Structure
In-Reply-To: <440FF1D3.2020606@cuddletech.com>
References: <440EA31A.5030802@cuddletech.com>
	<20060308180707.GB158700@eng.sun.com>
	<440FF1D3.2020606@cuddletech.com>
Message-ID: <20060309175303.GA170429@eng.sun.com>

* Ben Rockwood <benr at cuddletech.com> [2006-03-09 01:14]:
> Stephen Hahn wrote:
> >* Ben Rockwood <benr at cuddletech.com> [2006-03-08 01:31]:
> > I think it's a valid way to approach the problem, although I don't
> > agree that there is consensus on restricting the number ("small") or
> > nature ("high-level") of the communities.  In fact, a
> > contributor-oriented membership would not necessarily lead to high
> > level communities like the examples you mention.  
> >
> > As an example, if we restrict the communities, then we end up
> > restricting the types of contributor we are willing to recognize.
> > Another way to look at that is that wide definition communities, like
> > Storage, need to be able to identify many kinds of contributor
> > (Storage driver developer, Storage management software developer,
> > Storage best practice author, Storage helpful sysadmin, Storage
> > visionary, ...).  Whether such distinct roles would want to be in a
> > single community--they go to different conferences--may be too severe
> > a constraint.
> >
> As you point out, there are too many possible contribution roles to set 
> them in stone, therefore I think that a prudent approach is to place the 
> authority to name someone as a "member" or "contributer" with the 
> leadership of a given high level community.  This approach, however, 
> assumes that the leadership of each community is, a) qualified, b) 
> engaged, and c) aware.  Honestly, these attributes may be harder to 
> enforce than they sound.
 
  I think that the leadership might seed the initial contributors, but I
  believe that the community itself needs to participate in the proposal
  and agreement on contributorship.  The notion of an "ASF member" seems
  pretty close:

  http://apache.org/foundation/how-it-works.html#asf-members

  although that role appears to require ASF-wide consensus, which I
  don't believe we can emulate, as our communities appear to have many
  specialists.  Perhaps I am being pessimistic.

  I also keep entertaining the idea of emergent contributorship, using
  something similar to the three level trust metric as designed and
  implemented at advogato.org.  If the certificates expired, then we
  have the contributor timeouts Al and others have mentioned.

> I think the key is delegation of authority.  In a sense, we can compare 
> the structure I'm envisioning as similar to a traditional organizational 
> entity such as a country or corperation.  The OGB acts as a federal 
> government, communities act as states, and projects as counties/cities.  

  (Look at 

  http://en.wikipedia.org/wiki/Political_subdivisions_of_New_York_State

  if you want to see what scares me about analogies to real-world
  governmental forms.)

> In such a case, its the community that oversee most matters, using power 
> granted by the OGB and constitution.  They select their own membership 
> since they have a better understanding of who and what they are doing.  

  Agree, although how a community or group of communities complains
  about OGB actions (or, more likely, the actions of an OGB-authorized
  subcommittee) seems like an interesting problem.

> The only trick is to avoid turning the whole thing into a big bureaucracy.
 
  (Too late?)

> > Should the existing communities to be able to block the creation of
> > new communities?
> >
> No.  I think that only the OGB should have the authority to block a new 
> community, and even then, the process should be initiated by someone 
> outside of the OGB, namely a leader from the disputing community.
 
  Ok.  Perhaps lack of consensus/obviousness as embodied in the current
  process is sufficient.

> Maybe some of these ideas are good, maybe not, but its important that we 
> get discussions under way and keep this effort moving.

  You bet.

  Cheers
  Stephen

-- 
Stephen Hahn, PhD  Solaris Kernel Development, Sun Microsystems
stephen.hahn at sun.com  http://blogs.sun.com/sch/


From sch at eng.sun.com  Thu Mar  9 10:08:26 2006
From: sch at eng.sun.com (Stephen Hahn)
Date: Thu, 9 Mar 2006 10:08:26 -0800
Subject: [cab-discuss] Community demotion process thoughts
Message-ID: <20060309180826.GB170429@eng.sun.com>


  A couple of people have mentioned to me how many communities there
  are, and Ben's initial mail reminded me of this aspect as well.  I
  feel I need to borrow the "vastly, hugely, mind-bogglingly big" phrase
  from the Developer's Reference:  the number of technical specialities
  and areas of investigation in OpenSolaris is big, vastly big, etc.
  Nevertheless, there are some communities that appear to be very much
  inactive, and shouldn't really have participatory capabilities in the
  recognition of contributors, etc.

  We probably need a process to demote communities to projects.  I'll
  make sure that we can redirect the old URLs as part of the
  implementation of the demotion, but I'm more concerned about having a
  process.   

  One approach, that is accommodating (in that the previous consensus to
  create the community is respected) would be:

  1.  opensolaris member or OGB or subcommittee thereof ("community
      evaluation committee"?) sends notice to cab-discuss of possibly
      defunct community.  Defunctness means no active discussion, no
      document or other content creation, no endorsement, no leadership
      change...

  2.  OGB moves to act on defunct community notice, by initiating a
      community health evaluation.

  3.  If motion passes, notice is sent to community leaders via primary
      community alias with some timeout for response.

  4.  If no response, notice sent to opensolaris-discuss with some
      timeout.

  5.  If no response, OGB asks infrastructure to demote community to
      project.  Contributorship grants from that community go on timer.
 
  At any received response, the OGB (or its community evaluation
  subcommittee) can directly consider whether the response received is
  sufficient to treat the community as resuscitated, and can treat the
  notice as resolved.

  (If you look at 

  http://www.opensolaris.org/jive/index.jspa?categoryID=1

  you can get some hints about communities that appear to be at risk of
  being assessed defunct.)

  Thoughts?

  - Stephen

-- 
Stephen Hahn, PhD  Solaris Kernel Development, Sun Microsystems
stephen.hahn at sun.com  http://blogs.sun.com/sch/


From justin at erenkrantz.com  Thu Mar  9 11:00:31 2006
From: justin at erenkrantz.com (Justin Erenkrantz)
Date: Thu, 9 Mar 2006 11:00:31 -0800
Subject: [cab-discuss] The Constitution and Organizational Structure
In-Reply-To: <440FF1D3.2020606@cuddletech.com>
References: <440EA31A.5030802@cuddletech.com>
	<20060308180707.GB158700@eng.sun.com>
	<440FF1D3.2020606@cuddletech.com>
Message-ID: <20060309190031.GJ9098@scotch.ics.uci.edu>

On Thu, Mar 09, 2006 at 01:13:55AM -0800, Ben Rockwood wrote:
> I think the key is delegation of authority.  In a sense, we can compare 
> the structure I'm envisioning as similar to a traditional organizational 
> entity such as a country or corperation.  The OGB acts as a federal 
> government, communities act as states, and projects as counties/cities.  
> In such a case, its the community that oversee most matters, using power 
> granted by the OGB and constitution.  They select their own membership 
> since they have a better understanding of who and what they are doing.  
> The only trick is to avoid turning the whole thing into a big bureaucracy.

I would be cautious of confusing delegation of authority with oversight.

The OGB needs to ensure that it is properly overseeing all of the
sub-communities.  Otherwise, bad things'll inevitably happen.

In Apache, we created the Jakarta project and our Board mainly left it
alone.  So, Jakarta decided to model itself after the Board and spun off a
bunch of 'children' projects and similarly left them alone.  In the end,
this became a big uncontrollable mess as no one was actively watching the
individual projects and they collectively veered off-course.  We're still
trying to de-entangle ourselves from that mistake.

Now, the ASF Board mandates quarterly reports from each PMC (AIUI,
'community' in the OpenSolaris parlance).  In turn, if a PMC has
'sub-projects', they too must submit their portion of the report with the
community's report.  If a PMC has an issue they want the Board to address,
they are free to raise them at any time as well.

During our monthly con-calls, the ASF Board reviews each month's collection
of PMC reports.  It's our single most important activity and typically
takes the bulk of our con-call time.  We now have one Director randomly
delegated to 'shepherd' a project's report through the meeting.  If there
are any questions raised, the shepherd is responsible for contacting the
PMC with our concerns and report back for next month's meeting.  (Each
Director is still asked to review all reports before the meeting begins.)

You can take a look at the types of reports we get on our minutes page:

http://www.apache.org/foundation/records/minutes/2005/board_minutes_2005_12_21.txt

HTH.  -- justin


From justin at erenkrantz.com  Thu Mar  9 11:07:36 2006
From: justin at erenkrantz.com (Justin Erenkrantz)
Date: Thu, 9 Mar 2006 11:07:36 -0800
Subject: [cab-discuss] The Constitution and Organizational Structure
In-Reply-To: <20060309175303.GA170429@eng.sun.com>
References: <440EA31A.5030802@cuddletech.com>
	<20060308180707.GB158700@eng.sun.com>
	<440FF1D3.2020606@cuddletech.com>
	<20060309175303.GA170429@eng.sun.com>
Message-ID: <20060309190736.GK9098@scotch.ics.uci.edu>

On Thu, Mar 09, 2006 at 09:53:04AM -0800, Stephen Hahn wrote:
>   I think that the leadership might seed the initial contributors, but I
>   believe that the community itself needs to participate in the proposal
>   and agreement on contributorship.  The notion of an "ASF member" seems
>   pretty close:
> 
>   http://apache.org/foundation/how-it-works.html#asf-members
> 
>   although that role appears to require ASF-wide consensus, which I
>   don't believe we can emulate, as our communities appear to have many
>   specialists.  Perhaps I am being pessimistic.

In the ASF, we have lots of members across all of our projects - with the
'right' initial seeding, I doubt that specialization will be a serious
issue.  The key is to want to add people - not to find reasons to exclude.
I know nothing about Tomcat, Maven, etc; but the member who puts forth the
nomination statement usually adds a explanation of how this person is an
asset to that community, etc.  Other members who may have interacted with
that person then chime in agreement or disagreement.

The general question for ASF membership is usually along the lines of,
"Does this person merit a vote as to how the foundation should operate?"
Each member, of course, has a different take on what their precise criteria
is - but if someone has participated in a particular PMC and people they
already know vouches for them, that's usually enough to gain a majority
vote.

HTH.  -- justin


From webmink at sun.com  Fri Mar 10 10:51:56 2006
From: webmink at sun.com (Simon Phipps)
Date: Fri, 10 Mar 2006 12:51:56 -0600
Subject: [cab-discuss] Community demotion process thoughts
In-Reply-To: <20060309180826.GB170429@eng.sun.com>
References: <20060309180826.GB170429@eng.sun.com>
Message-ID: <DBE07D27-844D-461B-95D9-A865091182E3@sun.com>

+1

On Mar 9, 2006, at 12:08, Stephen Hahn wrote:

>
>   A couple of people have mentioned to me how many communities there
>   are, and Ben's initial mail reminded me of this aspect as well.  I
>   feel I need to borrow the "vastly, hugely, mind-bogglingly big"  
> phrase
>   from the Developer's Reference:  the number of technical  
> specialities
>   and areas of investigation in OpenSolaris is big, vastly big, etc.
>   Nevertheless, there are some communities that appear to be very much
>   inactive, and shouldn't really have participatory capabilities in  
> the
>   recognition of contributors, etc.
>
>   We probably need a process to demote communities to projects.  I'll
>   make sure that we can redirect the old URLs as part of the
>   implementation of the demotion, but I'm more concerned about  
> having a
>   process.
>
>   One approach, that is accommodating (in that the previous  
> consensus to
>   create the community is respected) would be:
>
>   1.  opensolaris member or OGB or subcommittee thereof ("community
>       evaluation committee"?) sends notice to cab-discuss of possibly
>       defunct community.  Defunctness means no active discussion, no
>       document or other content creation, no endorsement, no  
> leadership
>       change...
>
>   2.  OGB moves to act on defunct community notice, by initiating a
>       community health evaluation.
>
>   3.  If motion passes, notice is sent to community leaders via  
> primary
>       community alias with some timeout for response.
>
>   4.  If no response, notice sent to opensolaris-discuss with some
>       timeout.
>
>   5.  If no response, OGB asks infrastructure to demote community to
>       project.  Contributorship grants from that community go on  
> timer.
>
>   At any received response, the OGB (or its community evaluation
>   subcommittee) can directly consider whether the response received is
>   sufficient to treat the community as resuscitated, and can treat the
>   notice as resolved.
>
>   (If you look at
>
>   http://www.opensolaris.org/jive/index.jspa?categoryID=1
>
>   you can get some hints about communities that appear to be at  
> risk of
>   being assessed defunct.)
>
>   Thoughts?
>
>   - Stephen
>
> -- 
> Stephen Hahn, PhD  Solaris Kernel Development, Sun Microsystems
> stephen.hahn at sun.com  http://blogs.sun.com/sch/
> _______________________________________________
> cab-discuss mailing list
> cab-discuss at opensolaris.org



From Eric.Lowe at Sun.COM  Sat Mar 18 07:43:05 2006
From: Eric.Lowe at Sun.COM (Eric Lowe)
Date: Sat, 18 Mar 2006 07:43:05 PST
Subject: [cab-discuss] Re: Community demotion process thoughts
In-Reply-To: <20060309180826.GB170429@eng.sun.com>
Message-ID: <5352931.1142696615818.JavaMail.suncom@oss1>

Hi,

> feel I need to borrow the "vastly, hugely,
> y, mind-bogglingly big" phrase
> from the Developer's Reference:  the number of
> of technical specialities
> and areas of investigation in OpenSolaris is big,
> g, vastly big, etc.

More than quanity, I'd be concerned about quantity -- if there are a squillion, very active, independent communities, that's not a bad thing. However, as you point out:

> Nevertheless, there are some communities that
> at appear to be very much
> inactive, and shouldn't really have participatory
> ry capabilities in the
>   recognition of contributors, etc.

Agreed. Moreover, the more communities there are, the harder it is to propose new communities which don't have significant overlap or charter conflicts with existing communities (something I'm currently struggling with in trying to propose my own community with Nils).

> We probably need a process to demote communities to
> to projects.  I'll\

I see a possible, complimenting alternative to demoting communities to projects where the community isn't defunct but isn't overly effective either.

I like Jim Carlson's idea regarding "threshold of pain"; i.e. when it comes to mailing lists and communities, start broad, and split up only when folks start to complain that the community is too active or too diverse to function effectively. If there is a broader-reaching area which could use a community which has overlap with existing, lesser-active communities, we could "fold in" these less-active communities into the larger community, rather than demoting them to projects.

This also seems to overlap a bit with Ben's earlier post.

Take i18n for instance. It apperars that a single i18n community could stand just fine on its own, removing some of the proliferation there.

OTOH if we had DTrace and the other tools folded into Observability community
I think DTrace would still warrant its own project.

> 1.  opensolaris member or OGB or subcommittee
> ee thereof ("community
> evaluation committee"?) sends notice to
> ice to cab-discuss of possibly
> defunct community.  Defunctness means no active
> active discussion, no
> document or other content creation, no
> on, no endorsement, no leadership
>       change...
> 
> 2.  OGB moves to act on defunct community notice,
> e, by initiating a
>       community health evaluation.

Or, a proposed alternative "broader base" community is proposed which would fold in the communitie(s).
 
> 3.  If motion passes, notice is sent to community
> ty leaders via primary
>       community alias with some timeout for response.
> 
> 4.  If no response, notice sent to
> to opensolaris-discuss with some
>       timeout.
> 
> 5.  If no response, OGB asks infrastructure to
> to demote community to
> project.  Contributorship grants from that
> m that community go on timer.

Or fold the community into the new, broader community.

>   Thoughts?

Make the process straightforward and flexible. If folks in the community feel the process is not flexible they will be disinclined to invoke it out of fear of political retribution.

- Eric


From Eric.Lowe at Sun.COM  Sat Mar 18 07:44:57 2006
From: Eric.Lowe at Sun.COM (Eric Lowe)
Date: Sat, 18 Mar 2006 07:44:57 PST
Subject: [cab-discuss] Re: Community demotion process thoughts
In-Reply-To: <5352931.1142696615818.JavaMail.suncom@oss1>
Message-ID: <13610309.1142696727648.JavaMail.suncom@oss1>

Dangit, one letter makes a big difference
 
> More than quanity, I'd be concerned about quantity --

I meant QUALITY.

:)
- Eric


From Eric.Lowe at Sun.COM  Sat Mar 18 08:04:03 2006
From: Eric.Lowe at Sun.COM (Eric Lowe)
Date: Sat, 18 Mar 2006 08:04:03 PST
Subject: [cab-discuss] Re:  The Constitution and Organizational Structure
In-Reply-To: <20060308180707.GB158700@eng.sun.com>
Message-ID: <25130887.1142697873797.JavaMail.suncom@oss1>

> > It would seem to me that the consensus is to
> reorganize OpenSolaris as a 
> > small number of high-level "communities" (such as
> Storage, Networking, 
> > Evangelism), beneath which would be a variety of
> "projects" (such as 
> > ZFS, SMF, Dtrace, SVM).  This model is effectively
> already in place but 
> > isn't enforced and a large amount of consolidation
> can be done with the 
> > existing 39 communities.

This is my personal opinion and seems to be reinforced by the responses I've gotten to the long thread regarding creating a broad reaching OS community.

We need a model which is
  - inviting to all
  - minimal to no overlap between communities in terms of scope

The current model is neither.

> I think it's a valid way to approach the problem,
> m, although I don't
> agree that there is consensus on restricting the
> he number ("small") or
> nature ("high-level") of the communities.  In fact,
> t, a
> contributor-oriented membership would not
> ot necessarily lead to high
>   level communities like the examples you mention.  
> 
> As an example, if we restrict the communities, then
> en we end up
> restricting the types of contributor we are willing
> ng to recognize.

I have a concrete example of how the current model is being overly restrictive. I've gotten several e-mails from folks who are interested in learning about and working on virtual memory projects, but there is no community yet, so they feel they CAN'T contribute. When I started asking around I discovered there is significant resistance to creating a virtual memory community because of the overlap with file systems and I/O -- the concensus seems to be we need to build a kernel community instead. However the kernel community would have an unclear scope, conflicting with networking, file systems, drivers, and probably half of the other communities out there from zones to Xen.

There are two ways to address this:
1) Proliferation. Create communities per-subsystem or per-feature as is done now, and hope they don't flounder due to too small of a scope (as we've seen this doesn't appear to be working well).
2) Start over with a better structure.

> Another way to look at that is that wide definition
> on communities, like
> Storage, need to be able to identify many kinds of
> of contributor
> (Storage driver developer, Storage management
> nt software developer,
> Storage best practice author, Storage helpful
> ul sysadmin, Storage
> visionary, ...).  Whether such distinct roles would
> ld want to be in a
> single community--they go to different
> nt conferences--may be too severe
>   a constraint.

I don't see how this is a problem. In fact I think it's an *advantage*. Within Sun our developer model has been too fragmented, which has its costs. The docs folks aren't engaged with engineering, the engineering folks aren't fully engaged with services. Marketing isn't engaged with services so they know what the customer wants but not the pain the field is going through. Etc. By virtue of having one community to cover all these contributor roles, we've removed the organizational constraints that block information flow.

If you're worried about having a single -discuss within each community, have -developers, -admin, -users, etc discussion lists. But again the "start broad and narrow as needed" seems prudent, since it prevents a bunch of dead-on-arrival subgroups from appearing.

- Eric


From sch at eng.sun.com  Thu Mar 23 11:25:52 2006
From: sch at eng.sun.com (Stephen Hahn)
Date: Thu, 23 Mar 2006 11:25:52 -0800
Subject: [cab-discuss] Re: Community demotion process thoughts
In-Reply-To: <5352931.1142696615818.JavaMail.suncom@oss1>
References: <20060309180826.GB170429@eng.sun.com>
	<5352931.1142696615818.JavaMail.suncom@oss1>
Message-ID: <20060323192552.GA116400@eng.sun.com>

* Eric Lowe <Eric.Lowe at Sun.COM> [2006-03-18 07:43]:
> Hi,
> 
> > feel I need to borrow the "vastly, hugely,
> > y, mind-bogglingly big" phrase
> > from the Developer's Reference:  the number of
> > of technical specialities
> > and areas of investigation in OpenSolaris is big,
> > g, vastly big, etc.
> 
> More than quanity, I'd be concerned about quantity -- if there are a
> squillion, very active, independent communities, that's not a bad
> thing. However, as you point out:
> 
> > Nevertheless, there are some communities that
> > at appear to be very much
> > inactive, and shouldn't really have participatory
> > ry capabilities in the
> >   recognition of contributors, etc.
> 
> Agreed. Moreover, the more communities there are, the harder it is to
> propose new communities which don't have significant overlap or
> charter conflicts with existing communities (something I'm currently
> struggling with in trying to propose my own community with Nils).
 
  Perhaps I'm too subtext-sensitive, but I have issues with the phrase
  "my own community".  It makes me question whether the criticism is
  general, or stems from a specific experience.

> > We probably need a process to demote communities to
> > to projects.  I'll\
> 
> I see a possible, complimenting alternative to demoting communities to
> projects where the community isn't defunct but isn't overly effective
> either.
> 
> I like Jim Carlson's idea regarding "threshold of pain"; i.e. when it
> comes to mailing lists and communities, start broad, and split up only
> when folks start to complain that the community is too active or too
> diverse to function effectively. If there is a broader-reaching area
> which could use a community which has overlap with existing,
> lesser-active communities, we could "fold in" these less-active
> communities into the larger community, rather than demoting them to
> projects.
 
  Okay.  The notion of a successor community seems reasonable; my
  initial proposal was focussed on getting existing communities back to
  health, if possible, but I will amend it to include your/Ben's ideas.

> This also seems to overlap a bit with Ben's earlier post.
> 
> Take i18n for instance. It apperars that a single i18n community could
> stand just fine on its own, removing some of the proliferation there.
 
  Are the I18N community members complaining about their current
  organization?

> OTOH if we had DTrace and the other tools folded into Observability community
> I think DTrace would still warrant its own project.

  DTrace community leads, when I have mentioned this before, made an
  argument for independence that I couldn't counter:  DTrace is often
  the first reason people come to opensolaris.org at all, and this
  significance justifies its top-level existence.

> >   Thoughts?
> 
> Make the process straightforward and flexible. If folks in the
> community feel the process is not flexible they will be disinclined to
> invoke it out of fear of political retribution.

  It's difficult for me to respond to this paragraph, as I don't see how
  the current process is opaque or inflexible:  in its current form, it
  is little more than "assemble your thoughts, publish to the forum, seek
  consensus".

  - Stephen

-- 
Stephen Hahn, PhD  Solaris Kernel Development, Sun Microsystems
stephen.hahn at sun.com  http://blogs.sun.com/sch/


From sch at eng.sun.com  Thu Mar 23 11:49:04 2006
From: sch at eng.sun.com (Stephen Hahn)
Date: Thu, 23 Mar 2006 11:49:04 -0800
Subject: [cab-discuss] Re:  The Constitution and Organizational Structure
In-Reply-To: <25130887.1142697873797.JavaMail.suncom@oss1>
References: <20060308180707.GB158700@eng.sun.com>
	<25130887.1142697873797.JavaMail.suncom@oss1>
Message-ID: <20060323194904.GB116400@eng.sun.com>

* Eric Lowe <Eric.Lowe at Sun.COM> [2006-03-18 08:04]:
> > > It would seem to me that the consensus is to reorganize
> > > OpenSolaris as a small number of high-level "communities" (such as
> > > Storage, Networking, Evangelism), beneath which would be a variety
> > > of "projects" (such as ZFS, SMF, Dtrace, SVM).  This model is
> > > effectively already in place but isn't enforced and a large amount
> > > of consolidation can be done with the existing 39 communities.
> 
> This is my personal opinion and seems to be reinforced by the
> responses I've gotten to the long thread regarding creating a broad
> reaching OS community.
> 
> We need a model which is
>   - inviting to all
>   - minimal to no overlap between communities in terms of scope
> 
> The current model is neither.
 
  The projects are "inviting to all", although the current process asks
  for a seconder, so that there is an aspect of consensus.  The primary
  reason for a seconder was to make sure that the currently manual
  processes around project/community creation would not be overwhelmed.
  
  Communities, in the draft constitution, have governance duties.  They
  are not meant to be reflective of only a few people's opinions about
  what is important to the entire membership.  

  The real problem is that the earliest form of the site grandfathered
  in a bunch of communities before their leads understood that having a
  community requires time investments:  creating content, developing
  discussions, finding fellow travellers, etc.

> > I think it's a valid way to approach the problem, m, although I
> > don't agree that there is consensus on restricting the he number
> > ("small") or nature ("high-level") of the communities.  In fact, t,
> > a contributor-oriented membership would not ot necessarily lead to
> > high level communities like the examples you mention.  
> > 
> > As an example, if we restrict the communities, then en we end up
> > restricting the types of contributor we are willing ng to recognize.
> 
> I have a concrete example of how the current model is being overly
> restrictive. I've gotten several e-mails from folks who are interested
> in learning about and working on virtual memory projects, but there is
> no community yet, so they feel they CAN'T contribute. When I started
> asking around I discovered there is significant resistance to creating
> a virtual memory community because of the overlap with file systems
> and I/O -- the concensus seems to be we need to build a kernel
> community instead. However the kernel community would have an unclear
> scope, conflicting with networking, file systems, drivers, and
> probably half of the other communities out there from zones to Xen.

  You can start a virtual memory project for such discussions _today_.
  (Resource management is pursuing this path.)

  It would be reasonable to ask the OGB to develop a "project promotion"
  process (or refine the community proposal process) to handle the case
  when the virtual memory project has demonstrated some level of
  sustained participation comparable to a community.

> There are two ways to address this:
> 1) Proliferation. Create communities per-subsystem or per-feature as
> is done now, and hope they don't flounder due to too small of a scope
> (as we've seen this doesn't appear to be working well).

  Actually, in

  http://www.opensolaris.org/jive/message.jspa?messageID=17630&tstart=0

  I asked the then-CAB-now-OGB to bias against new community proposals
  in favour of projects, so that new technical efforts start as
  projects.

> 2) Start over with a better structure.
 
  A bit open ended.  We have a couple of processes in place, and a pair
  of group options to try to keep in contact with the original
  governance draft.  A number of the communities have gone through these
  processes, and achieved some membership-wide consensus about their
  expression of a meaningful aspect of OpenSolaris-as-a-whole.

  Do you have a proposal (or a germ thereof) that can influence the
  actual constitutional drafting that is underway? 

> > Another way to look at that is that wide definition on communities,
> > like Storage, need to be able to identify many kinds of of
> > contributor (Storage driver developer, Storage management 
> > software developer, Storage best practice author, Storage helpful 
> > sysadmin, Storage visionary, ...).  Whether such distinct roles
> > would want to be in a single community--they go to different 
> > conferences--may be too severe a constraint.
> 
> I don't see how this is a problem. In fact I think it's an
> *advantage*. Within Sun our developer model has been too fragmented,
> which has its costs. The docs folks aren't engaged with engineering,
> the engineering folks aren't fully engaged with services. Marketing
> isn't engaged with services so they know what the customer wants but
> not the pain the field is going through. Etc. By virtue of having one
> community to cover all these contributor roles, we've removed the
> organizational constraints that block information flow.
 
  Whether or not you believe the OpenSolaris community structure is
  responsible in any way to resolve Sun's organizational issues, my
  point is that a community can have too wide a scope to form a coherent
  "community".
  
> If you're worried about having a single -discuss within each
> community, have -developers, -admin, -users, etc discussion lists. But
> again the "start broad and narrow as needed" seems prudent, since it
> prevents a bunch of dead-on-arrival subgroups from appearing.

  As far as I know (and I don't watch all the groups), only one
  community approved via the community process has had trouble starting,
  due to overcommitment of the lead, and that a subsequent community
  member has offered to take over as initial lead.  The communities that
  need to be pruned are mostly grandfathered from the pilot or the
  initial launch.

  - Stephen

-- 
Stephen Hahn, PhD  Solaris Kernel Development, Sun Microsystems
stephen.hahn at sun.com  http://blogs.sun.com/sch/


From sch at eng.sun.com  Thu Mar 23 12:01:49 2006
From: sch at eng.sun.com (Stephen Hahn)
Date: Thu, 23 Mar 2006 12:01:49 -0800
Subject: [cab-discuss] Community demotion process thoughts
In-Reply-To: <20060309180826.GB170429@eng.sun.com>
References: <20060309180826.GB170429@eng.sun.com>
Message-ID: <20060323200149.GC116400@eng.sun.com>


  Based on feedback, I've added some specific timeouts, and added the
  notion of communities proposing their own subsumption (although I
  don't believe zombie communities are a helpful notion, so mostly
  subsumption is specifying how the top level URL is redirected and how
  assignments made by the community are transferred).

  Comments welcomed.  If this is sufficient, then perhaps the OGB could
  move to adopt and we could await the first incoming notice.

  - Stephen

----

  OPENSOLARIS COMMUNITY DEMOTION PROCESS, v1 [DRAFT]

  1.  opensolaris member or OGB or subcommittee thereof sends notice to
      cab-discuss at opensolaris.org of possibly defunct community.
      Defunctness means no active discussion, no document or other
      content creation, no endorsement, no leadership change...
 
  2.  OGB moves to act on defunct community notice, by initiating a
      community health evaluation.
 
  3.  If motion passes, notice is sent to community leaders via primary
      community alias with a three week timer for response.  At any
      received response, the OGB (or its designated subcommittee) can
      directly consider whether the response received proposes
      sufficient corrective action to treat the community as
      resuscitated, and can treat the notice as resolved.  Beyond
      proposing community restoration, responses may also accept the
      demotion or may accept the demotion and additionally propose that
      the community be subsumed by an existing community.  That
      community should not also be under health evaluation.

  4.  If no response, notice sent to opensolaris-discuss at opensolaris.org
      with a three week timer for response.  

  5.  If no response or demotion was accepted in steps 3 or 4, OGB asks
      infrastructure operators to demote community to project.
      Contributorship grants, or other constitutional assignments, by
      that community go on a six month timer.
  

-- 
Stephen Hahn, PhD  Solaris Kernel Development, Sun Microsystems
stephen.hahn at sun.com  http://blogs.sun.com/sch/


From sch at eng.sun.com  Thu Mar 23 12:09:18 2006
From: sch at eng.sun.com (Stephen Hahn)
Date: Thu, 23 Mar 2006 12:09:18 -0800
Subject: [cab-discuss] "opensolaris-" in alias, project, and community names
Message-ID: <20060323200918.GD116400@eng.sun.com>


   Since I was asked to look at how to close out the
   opensolaris-{bugs,code,rfe} aliases over time, I spent a little time
   looking at existing names on the system, to see what other naming
   issues exist.  There are a couple that use "solaris" and
   "opensolaris" in their long title that I don't really believe are
   sensible or sustainable uses.  (In that the terms are not used
   properly as their trademark use would require, nor do they reflect an
   effort of the membership as a whole, or of the OGB on the
   membership's behalf.)

   I would like to suggest that the use of the terms "opensolaris" and
   "OpenSolaris" in a alias, project, or community name be restricted to
   entities that the OGB itself proposes.  (The bare terms "solaris" and
   "Solaris" are not to be used at all.)

   - Stephen

-- 
Stephen Hahn, PhD  Solaris Kernel Development, Sun Microsystems
stephen.hahn at sun.com  http://blogs.sun.com/sch/


From Eric.Lowe at Sun.COM  Thu Mar 23 11:52:20 2006
From: Eric.Lowe at Sun.COM (Eric Lowe)
Date: Thu, 23 Mar 2006 13:52:20 -0600
Subject: [cab-discuss] Re: Community demotion process thoughts
In-Reply-To: <20060323192552.GA116400@eng.sun.com>
References: <20060309180826.GB170429@eng.sun.com>
	<5352931.1142696615818.JavaMail.suncom@oss1>
	<20060323192552.GA116400@eng.sun.com>
Message-ID: <4422FC74.2020409@Sun.COM>

Hi,

>> Agreed. Moreover, the more communities there are, the harder it is to
>> propose new communities which don't have significant overlap or
>> charter conflicts with existing communities (something I'm currently
>> struggling with in trying to propose my own community with Nils).
>  
>   Perhaps I'm too subtext-sensitive, but I have issues with the phrase
>   "my own community".  It makes me question whether the criticism is
>   general, or stems from a specific experience.

I'm just pointing out that this stems from personal experience. If I've 
run into this problem of community scope and potential conflicts, I'm sure 
that others will in the future when they try to propose new communities.

>> I like Jim Carlson's idea regarding "threshold of pain"; i.e. when it
>> comes to mailing lists and communities, start broad, and split up only
>> when folks start to complain that the community is too active or too
>> diverse to function effectively. If there is a broader-reaching area
>> which could use a community which has overlap with existing,
>> lesser-active communities, we could "fold in" these less-active
>> communities into the larger community, rather than demoting them to
>> projects.
>  
>   Okay.  The notion of a successor community seems reasonable; my
>   initial proposal was focussed on getting existing communities back to
>   health, if possible, but I will amend it to include your/Ben's ideas.

Great, much appreciated.

>> Take i18n for instance. It apperars that a single i18n community could
>> stand just fine on its own, removing some of the proliferation there.
>  
>   Are the I18N community members complaining about their current
>   organization?

I don't know; I haven't even asked them. My observation was following on 
your initial post, where you pointed out that many of the mailing lists 
have little or no traffic.

>   DTrace community leads, when I have mentioned this before, made an
>   argument for independence that I couldn't counter:  DTrace is often
>   the first reason people come to opensolaris.org at all, and this
>   significance justifies its top-level existence.

Makes sense.

Since OpenSolaris is an established community I'm assuming that any 
top-down reorganization would be completely concensus-oriented, so 
individual communities would reserve the right to veto annexation.

Ideally some of it would even be bottom-up, grass-roots. For instance, I 
have suggested to some of the filesystem community leaders that they may 
want to consider merging their communities together to provide a common 
umbrella for new filesystem porting projects. The idea was well received.

I'm more interested in the ends than the means, so personally I don't care 
how we get there.

>> Make the process straightforward and flexible. If folks in the
>> community feel the process is not flexible they will be disinclined to
>> invoke it out of fear of political retribution.
> 
>   It's difficult for me to respond to this paragraph, as I don't see how
>   the current process is opaque or inflexible:  in its current form, it
>   is little more than "assemble your thoughts, publish to the forum, seek
>   consensus".

Clearly it's not right now. If anything it's lacking structure. :)

- Eric


From Eric.Lowe at Sun.COM  Thu Mar 23 12:51:28 2006
From: Eric.Lowe at Sun.COM (Eric Lowe)
Date: Thu, 23 Mar 2006 14:51:28 -0600
Subject: [cab-discuss] Re:  The Constitution and Organizational Structure
In-Reply-To: <20060323194904.GB116400@eng.sun.com>
References: <20060308180707.GB158700@eng.sun.com>
	<25130887.1142697873797.JavaMail.suncom@oss1>
	<20060323194904.GB116400@eng.sun.com>
Message-ID: <44230A50.6010804@Sun.COM>

Stephen Hahn wrote:
>> This is my personal opinion and seems to be reinforced by the
>> responses I've gotten to the long thread regarding creating a broad
>> reaching OS community.
>>
>> We need a model which is
>>   - inviting to all
>>   - minimal to no overlap between communities in terms of scope
>>
>> The current model is neither.
>  
>   The projects are "inviting to all", although the current process asks
>   for a seconder, so that there is an aspect of consensus.  The primary
>   reason for a seconder was to make sure that the currently manual
>   processes around project/community creation would not be overwhelmed.

I agree that the project process is awesome -- I don't see any reason to 
change it at all, and I don't think anyone else does either. More is 
clearly more.

>   Communities, in the draft constitution, have governance duties.  They
>   are not meant to be reflective of only a few people's opinions about
>   what is important to the entire membership.  

This is a good thing.

>   The real problem is that the earliest form of the site grandfathered
>   in a bunch of communities before their leads understood that having a
>   community requires time investments:  creating content, developing
>   discussions, finding fellow travellers, etc.

Yes! This reinforces my thinking in a nutshell: communities are a 
high-stakes game; usually, less is more. The fewer the communities, the 
greater the chances of success for each, since there is a much greater 
likelihood that the leaders will have the time to commit, and that the 
contributors will contribute.

The loose federation of disjoint, sometimes inactive communities is 
disheartening because it doesn't reflect a lack of focus or commitment to 
the bigger picture.

>>> I think it's a valid way to approach the problem, m, although I
>>> don't agree that there is consensus on restricting the he number
>>> ("small") or nature ("high-level") of the communities.  In fact, t,
>>> a contributor-oriented membership would not ot necessarily lead to
>>> high level communities like the examples you mention.  
>>>
>>> As an example, if we restrict the communities, then en we end up
>>> restricting the types of contributor we are willing ng to recognize.
>> I have a concrete example of how the current model is being overly
>> restrictive. I've gotten several e-mails from folks who are interested
>> in learning about and working on virtual memory projects, but there is
>> no community yet, so they feel they CAN'T contribute. When I started
>> asking around I discovered there is significant resistance to creating
>> a virtual memory community because of the overlap with file systems
>> and I/O -- the concensus seems to be we need to build a kernel
>> community instead. However the kernel community would have an unclear
>> scope, conflicting with networking, file systems, drivers, and
>> probably half of the other communities out there from zones to Xen.
> 
>   You can start a virtual memory project for such discussions _today_.
>   (Resource management is pursuing this path.)

Ugh. It's so hard to articulate such a complex thought process in a piece 
of email, but I'll try.

IMO, projects should deal with tactical efforts, and have specific 
deliverables. Communities should deal with bigger picture issues, 
strategies, and roadmaps. Communities should sponsor and provide guidance 
to projects. Communities have specific *responsibilities* within OpenSolaris.

Anybody can be a project lead. A community lead should be a contributor 
who is recognized as an experienced technical leader of strategic 
importance to OpenSolaris as a whole.

Because communities have specific responsibilities which are important to 
the success of the overall OpenSolaris community, they cannot overlap, or 
disaster will ensue due to conflicts in jurisdiction.

E.g., "The ARC community says to do this, but the BrandZ community says to 
do that, and the XYZ community wants me to do something else!" This will 
ultimately result in death of the project, the contributor, or worse.

In Sun-ese, I think of projects as I-teams, and communities as ARCs or 
SWGs or P-teams. It's not a perfect mapping, but it's close. Each has its 
clear set of rules and responsibilities. Sometimes there is inevitable 
overlap or conflicts, in which case there is an appeals process (through 
SAC or management), but most of the time it works very well.

For those of you outside of Sun, you should still be able to see the line 
between implementation versus strategy, roadmap, and architecture. The 
division of labor is clear between them.

Furthermore, I believe the union of communities should cover all of the 
reaches of OpenSolaris as a whole, since the whole is truly the sum of its 
individual parts. If there are big gaps in the community structure, that 
means we've left big gaps in the strategy, big gaps in the OpenSolaris 
roadmap, and big gaps in the OpenSolaris architecture, under the inferred 
presumption that Sun will somehow fill them. That's bad, because it means 
we'll grow weaker in those areas, and won't have effective contributions 
from the community.

To help clarify my thinking I'll give some concrete examples --

BrandZ is rightly a community because it provides a framework. lx-brand is 
a project within the BrandZ community. It implements a common 
specification which is owned by the community -- the brand. There is a 
roadmap for BrandZ, and a clear strategy. It's recognized as an integral 
part of Solaris and one of the features which gives Solaris an edge.

DTrace is also rightly a community because it provides a framework. fbt, 
java, and the other providers are projects within the DTrace are projects 
which implement a common specification owned by the community -- the 
DTrace framework.

mdb is, but is not rightly, a community. Thinking more, neither would 
debugging. It's not really a project, because currently the mdb 
"community" isn't working on any mdb extensions. It isn't a community 
because it doesn't have a roadmap or strategy (though it does provide an 
architecture). On the other hand, if we looked at RAS, under which 
debugging fits (and which is only partially covered by FMA), RAS is a 
reasonable community. It would qualify in my thinking because it has 
strategic importance to Solaris, it has a roadmap, and it defines 
architecture. (FMA already has its own community so it would not fall 
under RAS, but that's OK as long as there is still a clear division of 
responsibility between them -- if it's RAS and it's not FMA it belongs in 
RAS otherwise it belongs in FMA ;))

.. Repeat thought process for the other communities ..

I'll post my collective thoughts to my blog, if someone really wants to 
use them as a strawman. Since I've come this far, I might as well jump off 
of the pier. ;)

To hit close to home:

 >   It would be reasonable to ask the OGB to develop a "project promotion"
 >   process (or refine the community proposal process) to handle the case
 >   when the virtual memory project has demonstrated some level of
 >   sustained participation comparable to a community.

Virtual memory is not a project. It's too broad; too far-reaching. It has 
implications and architecture that cross subsystem boundaries. It has a 
long-term roadmap. It has many active and future development projects. Its 
advancement is strategically important to Sun and to Solaris. Within Sun 
it has two appointed leaders who are responsible for an overall roadmap, 
for architecture, for reviewing designs and for sponsoring code changes.

In OpenSolaris virtual memory should have a roadmap, a strategy, and 
recognized community leaders. It should define the architecture, and work 
with other communities (filesystems being a key one) to improve it.

To address your points specifically, this is exactly why I would prefer to 
have a Kernel community of which virtual memory would be a part. The 
reason for this is because of your observation that it is expected that 
each community have a sustained participation and not stagnate (since it 
is important to OpenSolaris as a whole). Having a broader reaching 
community means that we have a better chance of reaching critical mass and 
getting to the tipping point where we can later split up the community 
into more than one community and still have a sustainable level of activity.

>> There are two ways to address this:
>> 1) Proliferation. Create communities per-subsystem or per-feature as
>> is done now, and hope they don't flounder due to too small of a scope
>> (as we've seen this doesn't appear to be working well).
> 
>   Actually, in
> 
>   http://www.opensolaris.org/jive/message.jspa?messageID=17630&tstart=0
> 
>   I asked the then-CAB-now-OGB to bias against new community proposals
>   in favour of projects, so that new technical efforts start as
>   projects.

This is IMO a good start to address barrier-to-entry, but it doesn't 
address my overall concerns I've tried to articulate above around who will 
own the strategy and roadmaps of which these technical efforts are 
necessarily a part.

Having projects which are not under the guidance of a community seems to 
indicate an unspoken presumption that the strategy and roadmap are 
controlled by some external organization (e.g. Sun!). That's IMO not the 
right thing to do, because it relinquishes control of the eventual destiny 
of the technology to a body other than the OpenSolaris community itself, 
which deserves the stake.

If you're bringing your project here, You don't own it, Sun doesn't own 
it. Some University somewhere doesn't own it. *The community owns it*. 
Unless I've badly mistaken the intent of communities, this implies that 
every project _should_ have a community. There is no community around 
opensolaris-discuss so if it doesn't have a community to govern it there 
is no one to hold the project accountable to community standards.

>> 2) Start over with a better structure.
>  
>   A bit open ended.  We have a couple of processes in place, and a pair
>   of group options to try to keep in contact with the original
>   governance draft.  A number of the communities have gone through these
>   processes, and achieved some membership-wide consensus about their
>   expression of a meaningful aspect of OpenSolaris-as-a-whole.
> 
>   Do you have a proposal (or a germ thereof) that can influence the
>   actual constitutional drafting that is underway? 

I'm completely ignorant here. Perhaps I need to go off and read 
documentation about the governance, constitution, etc. to understand what 
you're asking. I'm merely trying to share my opinions and observations in 
the hopes that others will find them useful in driving toward a common 
goal of making the community better for everyone.

I might be right on, or I might be out to lunch. I don't know enough to 
know yet. :)

>> not the pain the field is going through. Etc. By virtue of having one
>> community to cover all these contributor roles, we've removed the
>> organizational constraints that block information flow.
>  
>   Whether or not you believe the OpenSolaris community structure is
>   responsible in any way to resolve Sun's organizational issues, my
>   point is that a community can have too wide a scope to form a coherent
>   "community".

Absolutely. There has to be some give-and-take.

>   As far as I know (and I don't watch all the groups), only one
>   community approved via the community process has had trouble starting,
>   due to overcommitment of the lead, and that a subsequent community
>   member has offered to take over as initial lead.  The communities that
>   need to be pruned are mostly grandfathered from the pilot or the
>   initial launch.

Pointers to more background here so I can go educate myself would be quite 
useful. I see now that I'm walking into this blindfolded.

- Eric


From Glynn.Foster at Sun.COM  Sun Mar 26 14:25:17 2006
From: Glynn.Foster at Sun.COM (Glynn Foster)
Date: Mon, 27 Mar 2006 10:25:17 +1200
Subject: [cab-discuss] "opensolaris-" in alias, project,
	and community	names
In-Reply-To: <20060323200918.GD116400@eng.sun.com>
References: <20060323200918.GD116400@eng.sun.com>
Message-ID: <1143411917.15303.2.camel@localhost>

Hi,

On Thu, 2006-03-23 at 12:09 -0800, Stephen Hahn wrote:
>    Since I was asked to look at how to close out the
>    opensolaris-{bugs,code,rfe} aliases over time, I spent a little time
>    looking at existing names on the system, to see what other naming
>    issues exist.  There are a couple that use "solaris" and
>    "opensolaris" in their long title that I don't really believe are
>    sensible or sustainable uses.  (In that the terms are not used
>    properly as their trademark use would require, nor do they reflect an
>    effort of the membership as a whole, or of the OGB on the
>    membership's behalf.)

+1.

Is there a proposal to tackle some of these issues and put forward a
migration plan for the mailing lists that break these rules?


Glynn



From stefanparvu14 at yahoo.com  Tue Mar 28 22:43:05 2006
From: stefanparvu14 at yahoo.com (Stefan Parvu)
Date: Tue, 28 Mar 2006 22:43:05 PST
Subject: [cab-discuss] question about mirroring OpenSolaris, Solaris,
	SE iso images
Message-ID: <10669387.1143614738599.JavaMail.suncom@oss1>

Hey,

I would like to get some advice about mirroring iso images for Solaris, Solaris Express and OpenSolaris source code. This question was asked in Romanian OpenSolaris User Group forum.

In short: can anyone download and mirror the following items:

 - Solaris 10 iso images (I think no)
 - Solaris Express images (I think no)
 - OpenSolaris source code (I think yes)

For future it would be nice to have setup local mirrors where people would be able to fetch the needed iso images. This including Solaris and some other software stack SMI produces: JES, Studio etc. Would this be possible ? 

Any ideas ?

Thanks,
Stefan
 
 
This message posted from opensolaris.org


From benr at cuddletech.com  Tue Mar 28 23:38:51 2006
From: benr at cuddletech.com (Ben Rockwood)
Date: Tue, 28 Mar 2006 23:38:51 -0800
Subject: [cab-discuss] question about mirroring OpenSolaris, Solaris,
	SE iso images
In-Reply-To: <10669387.1143614738599.JavaMail.suncom@oss1>
References: <10669387.1143614738599.JavaMail.suncom@oss1>
Message-ID: <442A398B.4000900@cuddletech.com>

Stefan Parvu wrote:

>Hey,
>
>I would like to get some advice about mirroring iso images for Solaris, Solaris Express and OpenSolaris source code. This question was asked in Romanian OpenSolaris User Group forum.
>
>In short: can anyone download and mirror the following items:
>
> - Solaris 10 iso images (I think no)
> - Solaris Express images (I think no)
> - OpenSolaris source code (I think yes)
>
>For future it would be nice to have setup local mirrors where people would be able to fetch the needed iso images. This including Solaris and some other software stack SMI produces: JES, Studio etc. Would this be possible ? 
>
>Any ideas ?
>  
>
CAB Discuss isn't the appropriate place to discuss such a thing, this is 
a question better suited for OS-Discuss or OS-Help.

That said, your assumptions are correct.  Solaris 10 and Solaris Express 
are closed licensed distributions.  In order to download either of these 
you must A) agree to Sun's End User License Agreement (EULA), and B) 
register with Sun.  These are required to ensure proper protection to 
Sun legally, as well as to allow Sun to keep track of how many users are 
downloading/running Solaris.  Sun can't claim 12 million downloads if 
its mirrored in places they can't control.

The OpenSolaris code, however, is licensed under the CDDL.  Section 2.2 
of the CDDL grants you the right to distribute CDDL licensed works 
however you wish.  It is because of this that you find the OpenSolaris 
code mirrored on sites like Genunix.org. 

Based on this, you can see that while JES and Sun Studio are currently 
no-cost/free, you can not mirror or distribute them for the same reasons 
that you can't distribute Solaris 10 or Express.  When the code for 
these is release, assuming it too is licensed CDDL, you'll be able to 
distribute the code for them in any way that you wish, however you still 
will not be able to mirror the binary builds themselves.  This is an 
important clause in the CDDL, section 3.5 "Distribution of Executable 
Versions", which allows you to distribute executable binary builds of a 
program under a different license (like an EULA) than the CDDL.

The closest Linux equivalent to this is Red Hat Enterprise Linux.  The 
Source RPMs are GPL licensed and therefore can be distributed, however 
the distribution as a whole is not.  Therefore you can create a new 
distribution from the source and distribute that (CentOS) but you can 
not distribute the official RHEL binary ISO's themselves.


I hope that clears things up.   If you reply, please do it privately or 
CC the discussion to the OS-Discuss or OS-Help lists instead of this one.

benr.


From Patrick.Finch at Sun.COM  Fri Mar 31 06:33:08 2006
From: Patrick.Finch at Sun.COM (patrick finch)
Date: Fri, 31 Mar 2006 16:33:08 +0200
Subject: [cab-discuss] Solaris University Challenge - CAB member to judge?
Message-ID: <442D3DA4.2020601@holland.sun.com>

All,

The Solaris University Challenge
(http://www.sun.com/software/solaris/contest/univ_challenge.jsp) closes
in June, and entries will be judged in July.  Judy Zimbleman has been
running the project and is looking for judges, and we agreed that one or
more members of the OpenSolaris CAB would be very appropriate as part of
the judges panel.

There are around 150 entries so far, but they will be screened down to a
top 10 or 20 for the judges.  The decision process has about a month
allocated to it, when all the entries will be hosted on a server in
California.

So, I've got two questions:

-Would any of the CAB members be interested and have the time to
allocate to being a judge in July?

-Are there any other suggestions for good arbiters?


regards

Patrick