From sch at eng.sun.com Mon May 1 15:10:41 2006 From: sch at eng.sun.com (Stephen Hahn) Date: Mon, 1 May 2006 15:10:41 -0700 Subject: [cab-discuss] AI 2: Example bylaws/constitutions Message-ID: <20060501221041.GA124583@eng.sun.com> Below, I've included a typical outline of an organization's bylaws. Other examples from various parliamentary authorities can be found at http://www.paulmcclintock.com/bylawarticles.htm (I like the one below because it's very complete.) Some formal examples that follow the typical model bylaws are: http://www.lib.berkeley.edu/~skoskine/bylaws-nc.html http://www.cccsaa.org/documents/Bylaws.pdf for two California non-profit organizations. From the open source community, there are a few more: http://apache.org/foundation/how-it-works.html http://www.debian.org/devel/constitution http://www.jini.org/jdp/Constitution.html The Jini community's is very formal, with a separate constitution, by-laws, definitions, etc.; the others are less so. - Stephen ---- Suggested Bylaw Provisions For an Organization ARTICLE I. Name ARTICLE II. Purpose (If the purposes are stated in a charter, they need not be repeated in the bylaws.) ARTICLE III. Membership A. Classes of membership B. Requirements C. Procedure for application ARTICLE IV. Officers A. List of officers of organization B. Method of selection C. Duties of each officer D. Method of filling vacancies E. Removal of officers ARTICLE V. Board of directors A. Membership B. Officers of board C. Duties and responsibilities of board D. Executive committee of board 1. Membership 2. Duties E. Meetings of board F. Reports of board and executive committee ARTICLE VI. Meetings A. Annual: notice, business to be conducted, order of business B. Regular: notice, usual order of business C. Special: how called, notice ARTICLE VII. Committees A. Standing committees: list, membership, selection, duties, powers, meetings, reports B. Special committees: provisions for selection ARTICLE VIII. Finances A. Budget preparation and adoption B. Dues C. Auditor D. Surety bond for officers and employees ARTICLE IX. Terms of office ARTICLE X. Elections ARTICLE XI. Quorum A. Meetings of organization B. Meetings of board ARTICLE XII. Discipline and expulsion of members ARTICLE XIII. Parliamentary authority ARTICLE XIV. Policies A. Provisions for adoption B. Vote required for adoption and amendment ARTICLE XV. Amendments to bylaws ARTICLE XVI. Dissolution -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems stephen.hahn at sun.com http://blogs.sun.com/sch/ From fielding at gbiv.com Tue May 2 03:08:30 2006 From: fielding at gbiv.com (Roy T. Fielding) Date: Tue, 2 May 2006 03:08:30 -0700 Subject: [cab-discuss] AI 2: Example bylaws/constitutions In-Reply-To: <20060501221041.GA124583@eng.sun.com> References: <20060501221041.GA124583@eng.sun.com> Message-ID: <22839952-BE9E-451D-8F10-A978862BCF78@gbiv.com> Having an outline is good, though it is also important to note that most corporate bylaws are distinct from the actual operational procedures that were the goal of the governance document. For example, the Apache bylaws are its contract with Delaware as constrained by state law http://www.apache.org/foundation/bylaws.html and are almost entirely separate from the project guidelines that determine how the projects are run and the precedent board decisions that determine how projects are started, overseen, and terminated. In other words, don't be surprised if the OpenSolaris governance document does not look like an example bylaws document, particularly since our audience consists of engineers, not lawyers. Nevertheless, it is useful to work from a simple outline and make sure all the bases are covered. ....Roy From benr at cuddletech.com Tue May 2 11:50:50 2006 From: benr at cuddletech.com (Ben Rockwood) Date: Tue, 02 May 2006 11:50:50 -0700 Subject: [cab-discuss] AI 2: Example bylaws/constitutions In-Reply-To: <22839952-BE9E-451D-8F10-A978862BCF78@gbiv.com> References: <20060501221041.GA124583@eng.sun.com> <22839952-BE9E-451D-8F10-A978862BCF78@gbiv.com> Message-ID: <4457AA0A.90004@cuddletech.com> Roy T. Fielding wrote: > Having an outline is good, though it is also important to note > that most corporate bylaws are distinct from the actual operational > procedures that were the goal of the governance document. > For example, the Apache bylaws are its contract with Delaware > as constrained by state law > > http://www.apache.org/foundation/bylaws.html > > and are almost entirely separate from the project guidelines > that determine how the projects are run and the precedent > board decisions that determine how projects are started, > overseen, and terminated. > > In other words, don't be surprised if the OpenSolaris governance > document does not look like an example bylaws document, > particularly since our audience consists of engineers, not lawyers. > > Nevertheless, it is useful to work from a simple outline and > make sure all the bases are covered. Last night I was studying a variety of diffrent forms of governance and compiled a large list of interesting examples to look at, in addition to the Apache Foundation Bylaws, I'd point to the following: -> Apache Foundation: http://apache.org/foundation/records/ -> GNOME Foundation: http://foundation.gnome.org/about/ -> KDE e.V.: http://ev.kde.org/corporate/ -> FreeBSD Foundation: http://www.freebsdfoundation.org/documents/ -> WikiMedia Foundation: http://wikimediafoundation.org/wiki/Home -> http://www.openoffice.org/dev_docs/guidelines.html The chief difference between OpenOffice and the rest, (us and the rest for that matter), is that the other bylaws also serve as the basis of their not-for-profit incorporation. Never the less, they serve as a very useful guideline. I'm looking at the existing OpenSolaris Governance Draft in a different light now. The model I find most interesting to this point is OpenOffices. Its not perfect for us, but a much more suitable setting, I think, than used for Apache. Namely, the fact that becoming an empowered voting member in the OpenOffice project is very straight forward and open for anyone to obtain if they desire, whereas the Apache model is much more exclusive in nature. Both for the sake of management as well as openness I think thats the way to go. benr. From Sara.Dornsife at Sun.COM Tue May 2 13:11:51 2006 From: Sara.Dornsife at Sun.COM (Sara Dornsife) Date: Tue, 02 May 2006 15:11:51 -0500 Subject: [cab-discuss] OpenSolaris Anniversary activities Message-ID: <4457BD07.4020301@sun.com> I'd like to start weekly meetings for those interested in working on the one year anniversary celebration team for OpenSolaris. We've had some emails going around and some things have been proposed. It's time to prioritize those ideas and start working on them. There is a lot on this list and we may not be able to do all of it, but with volunteers, we can do more. I've included the lists and people who shown an interest in these activities. I've listed out what has been proposed so far. If you can't participate in the meetings, but would like to participate in email, you can do that. We'll keep this conversation going on the marketing alias. If you haven't subscribed, you should. Below is the initial list of things to be discussed. These are in no particular order. Proposed ideas: - banner ads on sun.com We've got these, so let's use them. Idea that has gotten the most traction so far is: C-O-D-E OpenSolaris is a 4-letter word We have the ability to do another one as well. These need to be prioritized and someone needs to drive the activity. - Worldwide user group meeting Have all of the existing (and any new ones that want to start up to participate) hold a meeting on June 14th. All attendees will receive a gift (t-shirt, stickers, laptop stickers, car electrostatic clings) and a webcast with "celebrity" will be created to be seen at those meetings. - DVDs vs CDs Create DVDs (or should it be CDs need to decide) of one or all of the distributions to send out to anyone who requests one for a period of time around the anniversary. Also make them available for shows, events, meetings, user groups, etc. - Pre-printed DVD/CDs We can make blank DVD/CDs that are pre-printed that can be sent out for anyone who wants them to distribute. Need to decide what these say on them (if we want to do them)? NOTE: Solaris Express is not redistributable, so can only be available through Sun. Need to know of any restrictions on the other distros. - T-shirts First anniversary t-shirts. Proposed design attached. We can send these to the user groups. Sending them out individually is cost prohibitive, but maybe we can figure out a way to make them available - our yahoo store or cafepress? How long are they relevant? Would we want to give them out at OSCon in August for example? - laptop stickers These have been requested in the past and I know that there are plenty of people who would like to stick an OpenSolaris sticker on their laptop. We could send these to the user groups as part of the gift pack and we can make them available on the store. I would recommend that these be more generic and not specifically one year. - Electostatic clings In case you are unfamiliar, these are non-stickers that cling to the inside of your car window and peal off easily. You can show your enthusiasm while you drive around in traffic. - Install guides We've talked about creating easy to use install guides for newbies and getting them out on the site and linked to from blogs. Maybe the install guides could include a screencast to help people get there more quickly. - Blogs So many people blogged on Opening Day. If people would also blog on the anniversary and talk about their experiences this first year, it would be great for the project. - Web site update The tshirt art is available and could be used on the web site if people like it (that goes for the shirt too). We've also been working on updating content like the FAQs. I'm sure there are other things as well. We'd need a rep from the web team to join us in our calls. Other activities: - Update of our field communications (explain) This is a very Sun focused activity aimed at our sales force, but you can have input on the content if you want. - Single slide showing one year snapshot (available on site) We have some pretty impressive stats about this community as you know. Well we need to provide people at Sun with a slide that they can insert into a deck that shows that. That slide can be made available on the site for anyone who wants to add that data to their deck. - PR outreach Possible stories include "switch stories" from those that have switched to Solaris because of OpenSolaris and reinforcement of open source messages - we are open source you morons. Meeting times: To accommodate our disparate locations, these are all morning slots. I'll send around dial-in information and agenda when we a time. We'll start meeting next week. Proposed days and times: 9am PT Tuesdays 7am PT Thursdays 9am PT Fridays From Bonnie.Corwin at Sun.COM Tue May 2 14:11:28 2006 From: Bonnie.Corwin at Sun.COM (Bonnie Corwin) Date: Tue, 02 May 2006 15:11:28 -0600 Subject: [cab-discuss] Re: OpenSolaris Anniversary activities In-Reply-To: <4457BD07.4020301@sun.com> References: <4457BD07.4020301@sun.com> Message-ID: <4457CB00.30308@Sun.COM> > Meeting times: > To accommodate our disparate locations, these are all morning slots. > I'll send around dial-in information and agenda when we a time. We'll > start meeting next week. > > Proposed days and times: > 9am PT Tuesdays > 7am PT Thursdays > 9am PT Fridays > Thu and Fri work in general. Thanks. Bonnie From Sara.Dornsife at Sun.COM Tue May 2 14:09:30 2006 From: Sara.Dornsife at Sun.COM (Sara Dornsife) Date: Tue, 02 May 2006 16:09:30 -0500 Subject: [cab-discuss] Re: [osol-mktg] OpenSolaris Anniversary activities In-Reply-To: <4457BD07.4020301@sun.com> References: <4457BD07.4020301@sun.com> Message-ID: <4457CA8A.5050700@sun.com> Proposed shirt art attached. Sorry. This would go (in my opinion) on either a black or a blue shirt (like the blue in the wordmark). Sara Sara Dornsife wrote: > I'd like to start weekly meetings for those interested in working on > the one year anniversary celebration team for OpenSolaris. We've had > some emails going around and some things have been proposed. It's time > to prioritize those ideas and start working on them. There is a lot on > this list and we may not be able to do all of it, but with volunteers, > we can do more. > > I've included the lists and people who shown an interest in these > activities. > > I've listed out what has been proposed so far. If you can't > participate in the meetings, but would like to participate in email, > you can do that. We'll keep this conversation going on the marketing > alias. If you haven't subscribed, you should. > > Below is the initial list of things to be discussed. These are in no > particular order. > > Proposed ideas: > - banner ads on sun.com > We've got these, so let's use them. Idea that has gotten the most > traction so far is: > > C-O-D-E > OpenSolaris is a 4-letter word > > We have the ability to do another one as well. These need to be > prioritized and someone needs to drive the activity. > > - Worldwide user group meeting > Have all of the existing (and any new ones that want to start up to > participate) hold a meeting on June 14th. All attendees will receive a > gift (t-shirt, stickers, laptop stickers, car electrostatic clings) > and a webcast with "celebrity" will be created to be seen at those > meetings. > > - DVDs vs CDs Create DVDs (or should it be CDs need to decide) of one > or all of the distributions to send out to anyone who requests one for > a period of time around the anniversary. Also make them available for > shows, events, meetings, user groups, etc. > > - Pre-printed DVD/CDs > We can make blank DVD/CDs that are pre-printed that can be sent out > for anyone who wants them to distribute. Need to decide what these say > on them (if we want to do them)? > > NOTE: Solaris Express is not redistributable, so can only be available > through Sun. Need to know of any restrictions on the other distros. > > - T-shirts > First anniversary t-shirts. Proposed design attached. We can send > these to the user groups. Sending them out individually is cost > prohibitive, but maybe we can figure out a way to make them available > - our yahoo store or cafepress? How long are they relevant? Would we > want to give them out at OSCon in August for example? > > - laptop stickers > These have been requested in the past and I know that there are plenty > of people who would like to stick an OpenSolaris sticker on their > laptop. We could send these to the user groups as part of the gift > pack and we can make them available on the store. I would recommend > that these be more generic and not specifically one year. > > - Electostatic clings > In case you are unfamiliar, these are non-stickers that cling to the > inside of your car window and peal off easily. You can show your > enthusiasm while you drive around in traffic. > > - Install guides > We've talked about creating easy to use install guides for newbies and > getting them out on the site and linked to from blogs. Maybe the > install guides could include a screencast to help people get there > more quickly. > > - Blogs > So many people blogged on Opening Day. If people would also blog on > the anniversary and talk about their experiences this first year, it > would be great for the project. > > - Web site update > The tshirt art is available and could be used on the web site if > people like it (that goes for the shirt too). We've also been working > on updating content like the FAQs. I'm sure there are other things as > well. We'd need a rep from the web team to join us in our calls. > > Other activities: > - Update of our field communications (explain) > This is a very Sun focused activity aimed at our sales force, but you > can have input on the content if you want. > > - Single slide showing one year snapshot (available on site) > We have some pretty impressive stats about this community as you know. > Well we need to provide people at Sun with a slide that they can > insert into a deck that shows that. That slide can be made available > on the site for anyone who wants to add that data to their deck. > > - PR outreach > Possible stories include "switch stories" from those that have > switched to Solaris because of OpenSolaris and reinforcement of open > source messages - we are open source you morons. > > Meeting times: > To accommodate our disparate locations, these are all morning slots. > I'll send around dial-in information and agenda when we a time. We'll > start meeting next week. > > Proposed days and times: > 9am PT Tuesdays > 7am PT Thursdays > 9am PT Fridays > > _______________________________________________ > opensolaris-mktg mailing list > opensolaris-mktg at opensolaris.org -------------- next part -------------- A non-text attachment was scrubbed... Name: OS_Birthday_Shirt.jpg Type: image/jpeg Size: 261475 bytes Desc: not available URL: From benr at cuddletech.com Tue May 2 15:14:39 2006 From: benr at cuddletech.com (Ben Rockwood) Date: Tue, 02 May 2006 15:14:39 -0700 Subject: [cab-discuss] Considering Membership Message-ID: <4457D9CF.10702@cuddletech.com> Sorry for lagging on the "5 Membership Questions" list. I'm not so sure its as simple as just a shot list which is why I've struggled with it. But here are some ideas based on research I was doing last night. - I'm curious if we should write the constitution with the possibility of it one day being the bylaw's by which to incorporate a Foundation. I'm personally opposed to doing so, but being prepared might not be a bad idea. - Of the models I've looked at, the one that I like the best is OpenOffice. By this model anyone that wants to be a voting member can do so by simply registering and becoming an "Observer" of a given project. If we use the OO.org model[1], my adapted hierarchy looks like this: - User/Anyone (This level is currently in the Governance Draft but I think is obvious and doesn't need to be explicitly noted) - Community Member: A registered user who is the observer of one or more OpenSolaris Communities. Observers may cast one vote per in each community for local issues, but only a single vote in OpenSolaris wide matters (eg: OGB Election) - Contributer/Developer: A contributing acknowledged contributer to a given OpenSolaris Community, by whatever means is considered acceptable within that community (ie: evangelism for OS-Marketing, writting/editing for OS-Docs, code-contribution for code communities, etc) Contributers/Devs are to be named by the leaders of that community by way of a documented vote, to be reported to the OGB. The OGB reserves the right to intervene in such decisions, but is encouraged to stay out of local politics. [All members at this level must submit a SCA.] - Core Contrib/Developer (aka: leaders): Core Developers are also leaders of their given OpenSolaris Community. These persons are given the right to decide matters and call votes within their community, to oversee and manage various sub-projects, etc. - Project Lead: Each community must elect one Core Dev to act as the Project Lead. This single person is responsible for that community and ensuring that responsibilities are met. This person is, by default, to act as a liaison to both the OGB and any other comities (eg; arc) but has the ability to delegate such duties to some other Core Dev within that given community if they choose, never the less the project lead is still responsible for that persons actions. - Governing Board Member: Person who is elected by the whole community to represent the project and its interests as a whole. To be elegable for election the person needs only to be a community member. Being a member of the OGB does NOT entitle you to the rights of any higher membership level than you have on your own merits (ie: OGB members don't automatically get the right to dictate within a community nor commit rights). So, the loose hiararchy is: O G B / / \ \ Community Leads / / / | | \ \ Core Developers / "Leaders" / | | | | | | \ Contributers/Developers & "Observers" / Members <-- Voting Persons | || | | || | || ||| || | Users and anyone who wants to be kool. What do you think? Its not 5 questions, but I'm thinking a lot about the problem. I need to re-write this list and formalize it, but its sufficient at this point for discussion. benr. [1]: The model is actually hobbled together based on Roy's Draft governance, the Apache Bylaws, OO.org Constitution, and a composite from the governance/bylaws of KDE, GNOME, and MediaWiki. I believe this is, imho, "the best of all worlds" as it applies to our future constitution. From dp at eng.sun.com Tue May 2 15:20:22 2006 From: dp at eng.sun.com (Dan Price) Date: Tue, 2 May 2006 15:20:22 -0700 Subject: [cab-discuss] Re: [website-discuss] Re: [osol-mktg] OpenSolaris Anniversary activities In-Reply-To: <4457D3BC.6000800@sun.com> References: <4457BD07.4020301@sun.com> <4457CA8A.5050700@sun.com> <4457D1B1.8070903@sun.com> <4457D3BC.6000800@sun.com> Message-ID: <20060502222022.GC16759@eng.sun.com> On Tue 02 May 2006 at 04:48PM, Sara Dornsife wrote: > Derek Cicero wrote: > >Sara Dornsife wrote: > > > >>Proposed shirt art attached. Sorry. This would go (in my opinion) on > >>either a black or a blue shirt (like the blue in the wordmark). > > > >I like the design, but the wordmark you are using is different from > >the one I have. The font is bolder and the blue looks darker. Is there > >a new version? > No, it's not different. Or, not supposed to be. I assumed it was a > screen difference. I'll check with the designer. Any other comments on > it? Like do you like the ? Yes, I like it (and agree with Derek that the wordmark needs fixing). I hazily recall someone noting that it was time to pick some new code for the background of these things? -dp -- Daniel Price - Solaris Kernel Engineering - dp at eng.sun.com - blogs.sun.com/dp From dp at eng.sun.com Tue May 2 15:23:45 2006 From: dp at eng.sun.com (Dan Price) Date: Tue, 2 May 2006 15:23:45 -0700 Subject: [cab-discuss] Re: [website-discuss] Re: [osol-mktg] OpenSolaris Anniversary activities In-Reply-To: <20060502222022.GC16759@eng.sun.com> References: <4457BD07.4020301@sun.com> <4457CA8A.5050700@sun.com> <4457D1B1.8070903@sun.com> <4457D3BC.6000800@sun.com> <20060502222022.GC16759@eng.sun.com> Message-ID: <20060502222345.GA27455@eng.sun.com> On Tue 02 May 2006 at 03:20PM, Dan Price wrote: > On Tue 02 May 2006 at 04:48PM, Sara Dornsife wrote: > > Derek Cicero wrote: > > >Sara Dornsife wrote: > > > > > >>Proposed shirt art attached. Sorry. This would go (in my opinion) on > > >>either a black or a blue shirt (like the blue in the wordmark). > > > > > >I like the design, but the wordmark you are using is different from > > >the one I have. The font is bolder and the blue looks darker. Is there > > >a new version? > > No, it's not different. Or, not supposed to be. I assumed it was a > > screen difference. I'll check with the designer. Any other comments on > > it? Like do you like the ? > > Yes, I like it (and agree with Derek that the wordmark needs fixing). > > I hazily recall someone noting that it was time to pick some new code > for the background of these things? Looking at it some more-- it would be nice to see what it would look like on a black shirt. I wonder if the code should form the "1" without any other deliniation? A minor nit is that the 1 looks a little chunky. (The vertical seems a little thick to me). -dp -- Daniel Price - Solaris Kernel Engineering - dp at eng.sun.com - blogs.sun.com/dp From dp at eng.sun.com Tue May 2 15:40:34 2006 From: dp at eng.sun.com (Dan Price) Date: Tue, 2 May 2006 15:40:34 -0700 Subject: [cab-discuss] Re: [website-discuss] Re: [osol-mktg] OpenSolaris Anniversary activities In-Reply-To: <4457DD37.9030406@sun.com> References: <4457BD07.4020301@sun.com> <4457CA8A.5050700@sun.com> <4457D1B1.8070903@sun.com> <4457D3BC.6000800@sun.com> <20060502222022.GC16759@eng.sun.com> <4457DD37.9030406@sun.com> Message-ID: <20060502224033.GD16759@eng.sun.com> On Tue 02 May 2006 at 05:29PM, Sara Dornsife wrote: > Dan Price wrote: > > On Tue 02 May 2006 at 04:48PM, Sara Dornsife wrote: > > I checked with the designer that changed it for me. He said that he had to > change the sizing slightly to fit in the new shape, but there are no color > changes or anything else. I don't think I was clear enough-- what precisely will the Tshirt look like if it is on a black background? How will the "1" be delineated? It's clearly not the right wordmark. In our wordmark, the i doesn't have a "dot" in it and the "l" doesn't ascend. Just do a visual comparison and you will see. > What code should it be? Changing it would change all of the buttons.... I don't see why everything has to have the same snippet of code? -dp -- Daniel Price - Solaris Kernel Engineering - dp at eng.sun.com - blogs.sun.com/dp From Sara.Dornsife at Sun.COM Tue May 2 14:48:44 2006 From: Sara.Dornsife at Sun.COM (Sara Dornsife) Date: Tue, 02 May 2006 16:48:44 -0500 Subject: [cab-discuss] Re: [website-discuss] Re: [osol-mktg] OpenSolaris Anniversary activities In-Reply-To: <4457D1B1.8070903@sun.com> References: <4457BD07.4020301@sun.com> <4457CA8A.5050700@sun.com> <4457D1B1.8070903@sun.com> Message-ID: <4457D3BC.6000800@sun.com> Derek Cicero wrote: > Sara Dornsife wrote: > >> Proposed shirt art attached. Sorry. This would go (in my opinion) on >> either a black or a blue shirt (like the blue in the wordmark). > > I like the design, but the wordmark you are using is different from > the one I have. The font is bolder and the blue looks darker. Is there > a new version? No, it's not different. Or, not supposed to be. I assumed it was a screen difference. I'll check with the designer. Any other comments on it? Like do you like the ? > > Derek > > >> Sara >> >> >> Sara Dornsife wrote: >> >>> I'd like to start weekly meetings for those interested in working on >>> the one year anniversary celebration team for OpenSolaris. We've had >>> some emails going around and some things have been proposed. It's >>> time to prioritize those ideas and start working on them. There is a >>> lot on this list and we may not be able to do all of it, but with >>> volunteers, we can do more. >>> >>> I've included the lists and people who shown an interest in these >>> activities. >>> >>> I've listed out what has been proposed so far. If you can't >>> participate in the meetings, but would like to participate in email, >>> you can do that. We'll keep this conversation going on the marketing >>> alias. If you haven't subscribed, you should. >>> >>> Below is the initial list of things to be discussed. These are in no >>> particular order. >>> >>> Proposed ideas: >>> - banner ads on sun.com >>> We've got these, so let's use them. Idea that has gotten the most >>> traction so far is: >>> >>> C-O-D-E >>> OpenSolaris is a 4-letter word >>> >>> We have the ability to do another one as well. These need to be >>> prioritized and someone needs to drive the activity. >>> >>> - Worldwide user group meeting >>> Have all of the existing (and any new ones that want to start up to >>> participate) hold a meeting on June 14th. All attendees will receive >>> a gift (t-shirt, stickers, laptop stickers, car electrostatic >>> clings) and a webcast with "celebrity" will be created to be seen at >>> those meetings. >>> >>> - DVDs vs CDs Create DVDs (or should it be CDs need to decide) of >>> one or all of the distributions to send out to anyone who requests >>> one for a period of time around the anniversary. Also make them >>> available for shows, events, meetings, user groups, etc. >>> >>> - Pre-printed DVD/CDs >>> We can make blank DVD/CDs that are pre-printed that can be sent out >>> for anyone who wants them to distribute. Need to decide what these >>> say on them (if we want to do them)? >>> >>> NOTE: Solaris Express is not redistributable, so can only be >>> available through Sun. Need to know of any restrictions on the other >>> distros. >>> >>> - T-shirts >>> First anniversary t-shirts. Proposed design attached. We can send >>> these to the user groups. Sending them out individually is cost >>> prohibitive, but maybe we can figure out a way to make them >>> available - our yahoo store or cafepress? How long are they >>> relevant? Would we want to give them out at OSCon in August for >>> example? >>> >>> - laptop stickers >>> These have been requested in the past and I know that there are >>> plenty of people who would like to stick an OpenSolaris sticker on >>> their laptop. We could send these to the user groups as part of the >>> gift pack and we can make them available on the store. I would >>> recommend that these be more generic and not specifically one year. >>> >>> - Electostatic clings >>> In case you are unfamiliar, these are non-stickers that cling to the >>> inside of your car window and peal off easily. You can show your >>> enthusiasm while you drive around in traffic. >>> >>> - Install guides >>> We've talked about creating easy to use install guides for newbies >>> and getting them out on the site and linked to from blogs. Maybe the >>> install guides could include a screencast to help people get there >>> more quickly. >>> >>> - Blogs >>> So many people blogged on Opening Day. If people would also blog on >>> the anniversary and talk about their experiences this first year, it >>> would be great for the project. >>> >>> - Web site update >>> The tshirt art is available and could be used on the web site if >>> people like it (that goes for the shirt too). We've also been >>> working on updating content like the FAQs. I'm sure there are other >>> things as well. We'd need a rep from the web team to join us in our >>> calls. >>> >>> Other activities: >>> - Update of our field communications (explain) >>> This is a very Sun focused activity aimed at our sales force, but >>> you can have input on the content if you want. >>> >>> - Single slide showing one year snapshot (available on site) >>> We have some pretty impressive stats about this community as you >>> know. Well we need to provide people at Sun with a slide that they >>> can insert into a deck that shows that. That slide can be made >>> available on the site for anyone who wants to add that data to their >>> deck. >>> >>> - PR outreach >>> Possible stories include "switch stories" from those that have >>> switched to Solaris because of OpenSolaris and reinforcement of open >>> source messages - we are open source you morons. >>> >>> Meeting times: >>> To accommodate our disparate locations, these are all morning slots. >>> I'll send around dial-in information and agenda when we a time. >>> We'll start meeting next week. >>> >>> Proposed days and times: >>> 9am PT Tuesdays >>> 7am PT Thursdays >>> 9am PT Fridays >>> >>> _______________________________________________ >>> opensolaris-mktg mailing list >>> opensolaris-mktg at opensolaris.org >> >> >> >> ------------------------------------------------------------------------ >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> website-discuss mailing list >> website-discuss at opensolaris.org > > > > From stevel at sun.com Tue May 2 14:47:38 2006 From: stevel at sun.com (Stephen Lau) Date: Tue, 02 May 2006 14:47:38 -0700 Subject: [cab-discuss] Re: OpenSolaris Anniversary activities In-Reply-To: <4457BD07.4020301@sun.com> References: <4457BD07.4020301@sun.com> Message-ID: <4457D37A.1030102@sun.com> Sara Dornsife wrote: > Meeting times: > To accommodate our disparate locations, these are all morning slots. > I'll send around dial-in information and agenda when we a time. We'll > start meeting next week. > > Proposed days and times: > 9am PT Tuesdays > 7am PT Thursdays > 9am PT Fridays can't do 9am Tues. 7a Thurs or 9am Fri works for me. -- stephen lau // stevel at sun.com | 650.786.0845 | http://whacked.net opensolaris // solaris kernel development From rich.teer at rite-group.com Tue May 2 14:53:57 2006 From: rich.teer at rite-group.com (Rich Teer) Date: Tue, 02 May 2006 14:53:57 -0700 (PDT) Subject: [cab-discuss] Re: [osol-mktg] OpenSolaris Anniversary activities In-Reply-To: <4457CA8A.5050700@sun.com> References: <4457BD07.4020301@sun.com> <4457CA8A.5050700@sun.com> Message-ID: On Tue, 2 May 2006, Sara Dornsife wrote: > Proposed shirt art attached. Sorry. This would go (in my opinion) on either a > black or a blue shirt (like the blue in the wordmark). I love it! -- Rich Teer, SCNA, SCSA, OpenSolaris CAB member President, Rite Online Inc. Voice: +1 (250) 979-1638 URL: http://www.rite-group.com/rich -------------- next part -------------- A non-text attachment was scrubbed... Name: OS_Birthday_Shirt.jpg Type: image/jpeg Size: 261475 bytes Desc: URL: -------------- next part -------------- _______________________________________________ opensolaris-mktg mailing list opensolaris-mktg at opensolaris.org From Sara.Dornsife at Sun.COM Tue May 2 15:29:11 2006 From: Sara.Dornsife at Sun.COM (Sara Dornsife) Date: Tue, 02 May 2006 17:29:11 -0500 Subject: [cab-discuss] Re: [website-discuss] Re: [osol-mktg] OpenSolaris Anniversary activities In-Reply-To: <20060502222022.GC16759@eng.sun.com> References: <4457BD07.4020301@sun.com> <4457CA8A.5050700@sun.com> <4457D1B1.8070903@sun.com> <4457D3BC.6000800@sun.com> <20060502222022.GC16759@eng.sun.com> Message-ID: <4457DD37.9030406@sun.com> Dan Price wrote: > On Tue 02 May 2006 at 04:48PM, Sara Dornsife wrote: > >> Derek Cicero wrote: >> >>> Sara Dornsife wrote: >>> >>> >>>> Proposed shirt art attached. Sorry. This would go (in my opinion) on >>>> either a black or a blue shirt (like the blue in the wordmark). >>>> >>> I like the design, but the wordmark you are using is different from >>> the one I have. The font is bolder and the blue looks darker. Is there >>> a new version? >>> >> No, it's not different. Or, not supposed to be. I assumed it was a >> screen difference. I'll check with the designer. Any other comments on >> it? Like do you like the ? >> > > Yes, I like it (and agree with Derek that the wordmark needs fixing). > > I hazily recall someone noting that it was time to pick some new code > for the background of these things? > I checked with the designer that changed it for me. He said that he had to change the sizing slightly to fit in the new shape, but there are no color changes or anything else. What code should it be? Changing it would change all of the buttons.... > -dp > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sara.Dornsife at Sun.COM Tue May 2 15:44:53 2006 From: Sara.Dornsife at Sun.COM (Sara Dornsife) Date: Tue, 02 May 2006 17:44:53 -0500 Subject: [cab-discuss] Re: [website-discuss] Re: [osol-mktg] OpenSolaris Anniversary activities In-Reply-To: <20060502224033.GD16759@eng.sun.com> References: <4457BD07.4020301@sun.com> <4457CA8A.5050700@sun.com> <4457D1B1.8070903@sun.com> <4457D3BC.6000800@sun.com> <20060502222022.GC16759@eng.sun.com> <4457DD37.9030406@sun.com> <20060502224033.GD16759@eng.sun.com> Message-ID: <4457E0E5.3060205@sun.com> Dan Price wrote: > On Tue 02 May 2006 at 05:29PM, Sara Dornsife wrote: > >> Dan Price wrote: >> >> On Tue 02 May 2006 at 04:48PM, Sara Dornsife wrote: >> >> I checked with the designer that changed it for me. He said that he had to >> change the sizing slightly to fit in the new shape, but there are no color >> changes or anything else. >> > > I don't think I was clear enough-- what precisely will the Tshirt > look like if it is on a black background? How will the "1" be > delineated? > > It's clearly not the right wordmark. In our wordmark, the i doesn't > have a "dot" in it and the "l" doesn't ascend. Just do a visual > comparison and you will see. > He's sending me the art on black. It will look a lot like the black tshirts we did at launch, but in the shape of a 1. I've resent the wordmark for him to replace. > >> What code should it be? Changing it would change all of the buttons.... >> > > I don't see why everything has to have the same snippet of code? > It doesn't. What do you have in mind? I haven't written any code that work :). > -dp > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dp at eng.sun.com Tue May 2 15:53:04 2006 From: dp at eng.sun.com (Dan Price) Date: Tue, 2 May 2006 15:53:04 -0700 Subject: [cab-discuss] Re: [website-discuss] Re: [osol-mktg] OpenSolaris Anniversary activities In-Reply-To: <4457E0E5.3060205@sun.com> References: <4457BD07.4020301@sun.com> <4457CA8A.5050700@sun.com> <4457D1B1.8070903@sun.com> <4457D3BC.6000800@sun.com> <20060502222022.GC16759@eng.sun.com> <4457DD37.9030406@sun.com> <20060502224033.GD16759@eng.sun.com> <4457E0E5.3060205@sun.com> Message-ID: <20060502225304.GF16759@eng.sun.com> > > It doesn't. What do you have in mind? I haven't written any code that work :). ZFS is probably the biggest project to putback in the past year. How about something from it? http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/fs/zfs/vdev_raidz.c#405 It'd be a good quickie contest for os-discuss-- post your favorite snippet. -dp -- Daniel Price - Solaris Kernel Engineering - dp at eng.sun.com - blogs.sun.com/dp From Laura.Ramsey at Sun.COM Tue May 2 16:00:27 2006 From: Laura.Ramsey at Sun.COM (Laura Ramsey) Date: Tue, 02 May 2006 19:00:27 -0400 Subject: [cab-discuss] Re: [website-discuss] Re: [osol-mktg] OpenSolaris Anniversary activities In-Reply-To: <20060502222022.GC16759@eng.sun.com> References: <4457BD07.4020301@sun.com> <4457CA8A.5050700@sun.com> <4457D1B1.8070903@sun.com> <4457D3BC.6000800@sun.com> <20060502222022.GC16759@eng.sun.com> Message-ID: <4457E48B.1080108@sun.com> Does it have to be code? could it be a line-on-line listing of user IDs of community members? The names are mostly general enough that you can tell there's a person associated, but privacy wouldn't be blown because there's not an email address associated... Just thought it would be cool to promote the community. LKR Dan Price wrote: >On Tue 02 May 2006 at 04:48PM, Sara Dornsife wrote: > > >>Derek Cicero wrote: >> >> >>>Sara Dornsife wrote: >>> >>> >>> >>>>Proposed shirt art attached. Sorry. This would go (in my opinion) on >>>>either a black or a blue shirt (like the blue in the wordmark). >>>> >>>> >>>I like the design, but the wordmark you are using is different from >>>the one I have. The font is bolder and the blue looks darker. Is there >>>a new version? >>> >>> >>No, it's not different. Or, not supposed to be. I assumed it was a >>screen difference. I'll check with the designer. Any other comments on >>it? Like do you like the ? >> >> > >Yes, I like it (and agree with Derek that the wordmark needs fixing). > >I hazily recall someone noting that it was time to pick some new code >for the background of these things? > > -dp > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From moazam at unixville.com Tue May 2 16:17:20 2006 From: moazam at unixville.com (Moazam Raja) Date: Tue, 2 May 2006 16:17:20 -0700 Subject: [cab-discuss] Re: [osol-mktg] OpenSolaris Anniversary activities In-Reply-To: <4457CA8A.5050700@sun.com> References: <4457BD07.4020301@sun.com> <4457CA8A.5050700@sun.com> Message-ID: <9E1F09CD-F2A6-4E18-AB52-0D50DC50841B@unixville.com> Whatever logo is used, can we please *not* choose the 'ringer' type of t-shirt: http://us.st11.yimg.com/store1.yimg.com/I/ yhst-40238304033850_1893_420295 The ringer areas make the t-shirt look a bit poofy and pulled (weird, I know, but it's hard to describe) at the same time. This type of shirt, white or black, fits a lot better and holds up better in the long run. These are probably cheaper to produce also. http://photos1.blogger.com/blogger/6728/425/1600/hpim1269.jpg http://www.spreadshirt.net/image.php? type=image&partner_id=217313&product_id=1674147&img_id=1&size=huge&bgcol or_images=white -Moazam unixville.com On May 2, 2006, at 2:09 PM, Sara Dornsife wrote: > Proposed shirt art attached. Sorry. This would go (in my opinion) > on either a black or a blue shirt (like the blue in the wordmark). > Sara > > > Sara Dornsife wrote: >> I'd like to start weekly meetings for those interested in working >> on the one year anniversary celebration team for OpenSolaris. >> We've had some emails going around and some things have been >> proposed. It's time to prioritize those ideas and start working on >> them. There is a lot on this list and we may not be able to do all >> of it, but with volunteers, we can do more. >> >> I've included the lists and people who shown an interest in these >> activities. >> >> I've listed out what has been proposed so far. If you can't >> participate in the meetings, but would like to participate in >> email, you can do that. We'll keep this conversation going on the >> marketing alias. If you haven't subscribed, you should. >> >> Below is the initial list of things to be discussed. These are in >> no particular order. >> >> Proposed ideas: >> - banner ads on sun.com >> We've got these, so let's use them. Idea that has gotten the most >> traction so far is: >> >> C-O-D-E >> OpenSolaris is a 4-letter word >> >> We have the ability to do another one as well. These need to be >> prioritized and someone needs to drive the activity. >> >> - Worldwide user group meeting >> Have all of the existing (and any new ones that want to start up >> to participate) hold a meeting on June 14th. All attendees will >> receive a gift (t-shirt, stickers, laptop stickers, car >> electrostatic clings) and a webcast with "celebrity" will be >> created to be seen at those meetings. >> >> - DVDs vs CDs Create DVDs (or should it be CDs need to decide) of >> one or all of the distributions to send out to anyone who requests >> one for a period of time around the anniversary. Also make them >> available for shows, events, meetings, user groups, etc. >> >> - Pre-printed DVD/CDs >> We can make blank DVD/CDs that are pre-printed that can be sent >> out for anyone who wants them to distribute. Need to decide what >> these say on them (if we want to do them)? >> >> NOTE: Solaris Express is not redistributable, so can only be >> available through Sun. Need to know of any restrictions on the >> other distros. >> >> - T-shirts >> First anniversary t-shirts. Proposed design attached. We can send >> these to the user groups. Sending them out individually is cost >> prohibitive, but maybe we can figure out a way to make them >> available - our yahoo store or cafepress? How long are they >> relevant? Would we want to give them out at OSCon in August for >> example? >> >> - laptop stickers >> These have been requested in the past and I know that there are >> plenty of people who would like to stick an OpenSolaris sticker on >> their laptop. We could send these to the user groups as part of >> the gift pack and we can make them available on the store. I would >> recommend that these be more generic and not specifically one year. >> >> - Electostatic clings >> In case you are unfamiliar, these are non-stickers that cling to >> the inside of your car window and peal off easily. You can show >> your enthusiasm while you drive around in traffic. >> >> - Install guides >> We've talked about creating easy to use install guides for newbies >> and getting them out on the site and linked to from blogs. Maybe >> the install guides could include a screencast to help people get >> there more quickly. >> >> - Blogs >> So many people blogged on Opening Day. If people would also blog >> on the anniversary and talk about their experiences this first >> year, it would be great for the project. >> >> - Web site update >> The tshirt art is available and could be used on the web site if >> people like it (that goes for the shirt too). We've also been >> working on updating content like the FAQs. I'm sure there are >> other things as well. We'd need a rep from the web team to join us >> in our calls. >> >> Other activities: >> - Update of our field communications (explain) >> This is a very Sun focused activity aimed at our sales force, but >> you can have input on the content if you want. >> >> - Single slide showing one year snapshot (available on site) >> We have some pretty impressive stats about this community as you >> know. Well we need to provide people at Sun with a slide that they >> can insert into a deck that shows that. That slide can be made >> available on the site for anyone who wants to add that data to >> their deck. >> >> - PR outreach >> Possible stories include "switch stories" from those that have >> switched to Solaris because of OpenSolaris and reinforcement of >> open source messages - we are open source you morons. >> >> Meeting times: >> To accommodate our disparate locations, these are all morning >> slots. I'll send around dial-in information and agenda when we a >> time. We'll start meeting next week. >> >> Proposed days and times: >> 9am PT Tuesdays >> 7am PT Thursdays >> 9am PT Fridays >> >> _______________________________________________ >> opensolaris-mktg mailing list >> opensolaris-mktg at opensolaris.org > > From John.Plocher at Sun.Com Tue May 2 16:49:18 2006 From: John.Plocher at Sun.Com (John Plocher) Date: Tue, 02 May 2006 16:49:18 -0700 Subject: [cab-discuss] Considering Membership In-Reply-To: <4457D9CF.10702@cuddletech.com> References: <4457D9CF.10702@cuddletech.com> Message-ID: <4457EFFE.1050604@Sun.Com> Ben Rockwood wrote: > my adapted hierarchy looks like this: If it would help, the ARC community has a list of various OpenSolaris community roles along with simple operational definitions for each: http://www.opensolaris.org/os/community/arc/leaders/ > Project Lead: Each > community must elect one Core Dev to act as the Project Lead. This > single person is responsible for that community and ensuring that > responsibilities are met. This person is, by default, to act as a > liaison to both the OGB and any other comities (eg; arc) Playtesting the ARC implications of what you said: This could mean that the ON/Nevada community would only have a single ARC member/rep/liaison, who would be on equal ARC decision-making footing with (to illustrate the point) Chinese Users, Marketing and Testing. And that group of ARChitects would be responsible for understanding and approving ON's architectural evolution. This doesn't feel right to me. Maybe "one ARC liaison per Project" or "all Core Dev leaders are expected to perform ARC level duties"... I guess I'm trying to find a way to say three things: o Communities and projects are expected to be self-responsible and proactive about their own architectural evolution, o Systems Architecture is, by definition, a cross-project and cross-community activity, and o The way to manage all OpenSolaris architectural evolution (both within and between communities) is to use the ARC process. For process details, see http://www.opensolaris.org/os/community/arc/handbook/arc-dev-process/ -John From sch at eng.sun.com Tue May 2 17:00:30 2006 From: sch at eng.sun.com (Stephen Hahn) Date: Tue, 2 May 2006 17:00:30 -0700 Subject: [cab-discuss] Considering Membership In-Reply-To: <4457D9CF.10702@cuddletech.com> References: <4457D9CF.10702@cuddletech.com> Message-ID: <20060503000030.GB141739@eng.sun.com> * Ben Rockwood [2006-05-02 15:14]: > Sorry for lagging on the "5 Membership Questions" list. I'm not so sure > its as simple as just a shot list which is why I've struggled with it. > But here are some ideas based on research I was doing last night. Thanks for writing this up, Ben. > - I'm curious if we should write the constitution with the possibility > of it one day being the bylaw's by which to incorporate a Foundation. > I'm personally opposed to doing so, but being prepared might not be a > bad idea. > - Of the models I've looked at, the one that I like the best is > OpenOffice. By this model anyone that wants to be a voting member can > do so by simply registering and becoming an "Observer" of a given project. > > If we use the OO.org model[1], my adapted hierarchy looks like this: > > - User/Anyone (This level is currently in the Governance Draft but I > think is obvious and doesn't need to be explicitly noted) > - Community Member: A registered user who is the observer of one or more > OpenSolaris Communities. Observers may cast one vote per in each > community for local issues, but only a single vote in OpenSolaris wide > matters (eg: OGB Election) > - Contributer/Developer: A contributing acknowledged contributer to a > given OpenSolaris Community, by whatever means is considered acceptable > within that community (ie: evangelism for OS-Marketing, writting/editing > for OS-Docs, code-contribution for code communities, etc) > Contributers/Devs are to be named by the leaders of that community by > way of a documented vote, to be reported to the OGB. The OGB reserves > the right to intervene in such decisions, but is encouraged to stay out > of local politics. [All members at this level must submit a SCA.] So I think that I have a preference for the model the threshold is contribution, and where a community identifies its contributors: that would mean, for example, that the Marketing community would state that folks who helped out by giving booth time or writing slogans or designing banners would be contributors. I guess I am stuck on how observation makes one sufficiently involved to be able to participate in a recorded vote: the observers are unlikely to be impacted by the consequences of any particular decision, whereas the contributors most likely will be. > - Core Contrib/Developer (aka: leaders): Core Developers are also > leaders of their given OpenSolaris Community. These persons are given > the right to decide matters and call votes within their community, to > oversee and manage various sub-projects, etc. I like identifying "Community Leader" with this role. > - Project Lead: Each community must elect one Core Dev to act as the > Project Lead. This single person is responsible for that community > and ensuring that responsibilities are met. This person is, by > default, to act as a liaison to both the OGB and any other comities > (eg; arc) but has the ability to delegate such duties to some other > Core Dev within that given community if they choose, never the less > the project lead is still responsible for that persons actions. This level of specification might be too precise to balance workloads. I wonder if instead the communities should be expected to provide liaisons to the committees the constitution identifies, but not to specify how they select those liaisons. (For one thing, it is not clear that the liaisons should have to be leads...) > - Governing Board Member: Person who is elected by the whole community > to represent the project and its interests as a whole. To be elegable > for election the person needs only to be a community member. Being a > member of the OGB does NOT entitle you to the rights of any higher > membership level than you have on your own merits (ie: OGB members don't > automatically get the right to dictate within a community nor commit > rights). Sounds good. > So, the loose hiararchy is: > > O G B > / / \ \ > Community Leads > / / / | | \ \ > Core Developers / "Leaders" > / | | | | | | \ > Contributers/Developers & "Observers" / Members <-- Voting Persons > | || | | || | || ||| || | > Users and anyone who wants to be kool. > > What do you think? Its not 5 questions, but I'm thinking a lot about > the problem. I need to re-write this list and formalize it, but its > sufficient at this point for discussion. > > [1]: The model is actually hobbled together based on Roy's Draft > governance, the Apache Bylaws, OO.org Constitution, and a composite from > the governance/bylaws of KDE, GNOME, and MediaWiki. I believe this is, > imho, "the best of all worlds" as it applies to our future constitution. Again, thanks for kicking this off. I think that a large question is the degree of involvement that leads to being able to partcipate in a vote... - 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 Tue May 2 17:03:54 2006 From: sch at eng.sun.com (Stephen Hahn) Date: Tue, 2 May 2006 17:03:54 -0700 Subject: [cab-discuss] Considering Membership In-Reply-To: <4457EFFE.1050604@Sun.Com> References: <4457D9CF.10702@cuddletech.com> <4457EFFE.1050604@Sun.Com> Message-ID: <20060503000354.GC141739@eng.sun.com> * John Plocher [2006-05-02 16:44]: > [good questions elided] One thing I've been worried about is whether we have time to figure out how to represent the ARC processes in the core Constitution. It might be very appealing to leave the specifics to the future, and to get clear on how the governing board creates and oversees its various committees/specially-empowered communities (like ARC and the consolidations, perhaps) in the current effort. - Stephen From sch at eng.sun.com Tue May 2 17:26:37 2006 From: sch at eng.sun.com (Stephen Hahn) Date: Tue, 2 May 2006 17:26:37 -0700 Subject: [cab-discuss] AI 2: Example bylaws/constitutions In-Reply-To: <4457EA48.1050208@sun.com> References: <20060501221041.GA124583@eng.sun.com> <22839952-BE9E-451D-8F10-A978862BCF78@gbiv.com> <4457AA0A.90004@cuddletech.com> <4457EA48.1050208@sun.com> Message-ID: <20060503002637.GA143373@eng.sun.com> * Glynn Foster [2006-05-02 17:12]: > Hey, > > Ben Rockwood wrote: > >The model I find most interesting to this point is OpenOffices. Its not > >perfect for us, but a much more suitable setting, I think, than used for > >Apache. Namely, the fact that becoming an empowered voting member in > >the OpenOffice project is very straight forward and open for anyone to > >obtain if they desire, whereas the Apache model is much more exclusive > >in nature. Both for the sake of management as well as openness I think > >thats the way to go. > > I completely agree with Ben - I think it's absolutely vital to encourage > openness in all facets of the governance model as much as possible. > Lowering that barrier to entry of being part of the OpenSolaris > community is hugely valuable to creating something bigger IMO. Since you're a member, do you mind outlining how the GNOME Foundation membership's process works, where it's had trouble (if it has), and perhaps say what is or is not suitable for OpenSolaris to copy or emulate? - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems stephen.hahn at sun.com http://blogs.sun.com/sch/ From webmink at sun.com Tue May 2 19:24:28 2006 From: webmink at sun.com (Simon Phipps) Date: Wed, 03 May 2006 03:24:28 +0100 Subject: [cab-discuss] Considering Membership In-Reply-To: <20060503000030.GB141739@eng.sun.com> References: <4457D9CF.10702@cuddletech.com> <20060503000030.GB141739@eng.sun.com> Message-ID: On May 3, 2006, at 01:00, Stephen Hahn wrote: > * Ben Rockwood [2006-05-02 15:14]: >> Sorry for lagging on the "5 Membership Questions" list. I'm not >> so sure >> its as simple as just a shot list which is why I've struggled with >> it. >> But here are some ideas based on research I was doing last night. > > Thanks for writing this up, Ben. Likewise. We discussed this on the CAB before but it never got recorded; I'm pleased to see something written that we can work on. > >> - I'm curious if we should write the constitution with the >> possibility >> of it one day being the bylaw's by which to incorporate a Foundation. >> I'm personally opposed to doing so, but being prepared might not be a >> bad idea. I'd say not. The needs of a Foundation would be met with nylaws at the time it was created and as Roy suggested might well prove orthogonal to the rules that create an effective community of communities. >> - Of the models I've looked at, the one that I like the best is >> OpenOffice. By this model anyone that wants to be a voting member >> can >> do so by simply registering and becoming an "Observer" of a given >> project. I'm afraid I regard that as too low a threshold over at OO.o and it's something I personally believe they will have to change going forward. >> >> If we use the OO.org model[1], my adapted hierarchy looks like this: >> >> - User/Anyone (This level is currently in the Governance Draft but I >> think is obvious and doesn't need to be explicitly noted) >> - Community Member: A registered user who is the observer of one >> or more >> OpenSolaris Communities. Observers may cast one vote per in each >> community for local issues, but only a single vote in OpenSolaris >> wide >> matters (eg: OGB Election) >> - Contributer/Developer: A contributing acknowledged contributer to a >> given OpenSolaris Community, by whatever means is considered >> acceptable >> within that community (ie: evangelism for OS-Marketing, writting/ >> editing >> for OS-Docs, code-contribution for code communities, etc) >> Contributers/Devs are to be named by the leaders of that community by >> way of a documented vote, to be reported to the OGB. The OGB >> reserves >> the right to intervene in such decisions, but is encouraged to >> stay out >> of local politics. [All members at this level must submit a SCA.] > > So I think that I have a preference for the model the threshold is > contribution, and where a community identifies its contributors: > that > would mean, for example, that the Marketing community would state > that > folks who helped out by giving booth time or writing slogans or > designing banners would be contributors. > > I guess I am stuck on how observation makes one sufficiently > involved > to be able to participate in a recorded vote: the observers are > unlikely to be impacted by the consequences of any particular > decision, whereas the contributors most likely will be. I agree with this. I have always promoted the idea that those who contribute, vote (but see below, "scope"). Once "scope" is allowed for I'd suggest that voting at the various levels be reserved to those recognised as contributors. > >> - Core Contrib/Developer (aka: leaders): Core Developers are also >> leaders of their given OpenSolaris Community. These persons are >> given >> the right to decide matters and call votes within their community, to >> oversee and manage various sub-projects, etc. > > I like identifying "Community Leader" with this role. > >> - Project Lead: Each community must elect one Core Dev to act as the >> Project Lead. This single person is responsible for that community >> and ensuring that responsibilities are met. This person is, by >> default, to act as a liaison to both the OGB and any other comities >> (eg; arc) but has the ability to delegate such duties to some other >> Core Dev within that given community if they choose, never the less >> the project lead is still responsible for that persons actions. > > This level of specification might be too precise to balance > workloads. > I wonder if instead the communities should be expected to provide > liaisons to the committees the constitution identifies, but not to > specify how they select those liaisons. (For one thing, it is not > clear that the liaisons should have to be leads...) > >> - Governing Board Member: Person who is elected by the whole >> community >> to represent the project and its interests as a whole. To be >> elegable >> for election the person needs only to be a community member. Being a >> member of the OGB does NOT entitle you to the rights of any higher >> membership level than you have on your own merits (ie: OGB members >> don't >> automatically get the right to dictate within a community nor commit >> rights). > > Sounds good. Not sure I agree. I suspect the OGB should be elected by recognised contributors from nominations made from the whole membership (nominated and seconded by a suitable number of general members). Further discussion below. > >> So, the loose hiararchy is: >> >> O G B >> / / \ \ >> Community Leads >> / / / | | \ \ >> Core Developers / "Leaders" >> / | | | | | | \ >> Contributers/Developers & "Observers" / Members <-- Voting Persons >> | || | | || | || ||| || | >> Users and anyone who wants to be kool. >> >> What do you think? Its not 5 questions, but I'm thinking a lot about >> the problem. I need to re-write this list and formalize it, but its >> sufficient at this point for discussion. >> >> [1]: The model is actually hobbled together based on Roy's Draft >> governance, the Apache Bylaws, OO.org Constitution, and a >> composite from >> the governance/bylaws of KDE, GNOME, and MediaWiki. I believe >> this is, >> imho, "the best of all worlds" as it applies to our future >> constitution. > > Again, thanks for kicking this off. I think that a large > question is > the degree of involvement that leads to being able to partcipate > in a > vote... Another issue to consider is the scope of voting ability. For example, someone who is contributing to the marketing community to its satisfaction should certainly be able to vote about decisions, leadership representation and whatever else is being decided in that community. However, they almost certainly should not have a vote in decisions in the Documentation community unless they have also contributed over there. It's also arguable that the "electoral college" for community-wide voting should not necessarily include everyone with a vote in every community. Decisions at the meta-community level almost certainly require a perspective on OpenSolaris that stretches beyond the scope of any single community. It's therefore arguable that voting on issues at the OGB/Community Lead level should only involve Core Developers/Leaders and above. Certainly Apache reserves voting at this level to those elected to "Member" status, which is a peer college level analogous to Ben's Core Developer/Leader level. S. From John.Plocher at Sun.COM Tue May 2 20:36:52 2006 From: John.Plocher at Sun.COM (John Plocher) Date: Tue, 02 May 2006 20:36:52 -0700 Subject: [cab-discuss] Considering Membership In-Reply-To: <20060503000354.GC141739@eng.sun.com> References: <4457D9CF.10702@cuddletech.com> <4457EFFE.1050604@Sun.Com> <20060503000354.GC141739@eng.sun.com> Message-ID: <44582554.3090405@sun.com> Stephen Hahn wrote: > * John Plocher [2006-05-02 16:44]: >>[good questions elided] > [and a good response, as well] The core of the OpenSolaris ARC process is simply the explicit intent to be proactive (instead of reactive) about changes that affect the component and systems architecture of OpenSolaris. As long as this intent makes it into the constitution, the details of how it is implemented don't belong there - we don't want to have a constitutional referendum every time we tweak the processes we use. -John From benr at cuddletech.com Wed May 3 00:17:59 2006 From: benr at cuddletech.com (Ben Rockwood) Date: Wed, 03 May 2006 00:17:59 -0700 Subject: [cab-discuss] Considering Membership In-Reply-To: References: <4457D9CF.10702@cuddletech.com> <20060503000030.GB141739@eng.sun.com> Message-ID: <44585927.8060105@cuddletech.com> Simon Phipps wrote: >>> - Of the models I've looked at, the one that I like the best is >>> OpenOffice. By this model anyone that wants to be a voting member can >>> do so by simply registering and becoming an "Observer" of a given >>> project. >> > > I'm afraid I regard that as too low a threshold over at OO.o and it's > something I personally believe they will have to change going forward. Could you please expand on this? Why is it too low? Has it caused problems? What have the demonstrated pro's and con's been? > Another issue to consider is the scope of voting ability. For > example, someone who is contributing to the marketing community to > its satisfaction should certainly be able to vote about decisions, > leadership representation and whatever else is being decided in that > community. However, they almost certainly should not have a vote in > decisions in the Documentation community unless they have also > contributed over there. This was stipulated in the proposed list. You can apply to be an observer of any community you wish, whether thats 1 or 12. As an observer you'd have the right to vote in each of those communties for community isolated votes. For example, I'd likely be an observer of the storage community, docs community, and marketing community. For votes called in those communities I'd be able to cast my ballot, however if a vote was called in the Tools community I'd only be able to sit and watch. If a OpenSolaris-wide vote (OGB election for instance) was called, reguardless of how many communties I'd was involved with I'd still only have a single vote. The major flaw that is in this model would be the ability for someone to become an observer for a community once a ballot was presented, solely for the perposes of influencing that community. This would be entirely unacceptable since they have no vested interest in that communities future (in a positive way anyway). Therefore, we would need a lock-out period, whereby any observer would need to have become so some period before the vote, say 7 days. In my view the model I'm proposing (just for discussion, not as a "vote on this now") is the most open and flexable, however its also open to abuse. How do we prevent someone from becoming an observer of all the communities? Obviously that person is a problem and up to no good. > It's also arguable that the "electoral college" for community-wide > voting should not necessarily include everyone with a vote in every > community. Decisions at the meta-community level almost certainly > require a perspective on OpenSolaris that stretches beyond the scope > of any single community. It's therefore arguable that voting on > issues at the OGB/Community Lead level should only involve Core > Developers/Leaders and above. Certainly Apache reserves voting at > this level to those elected to "Member" status, which is a peer > college level analogous to Ben's Core Developer/Leader level. I don't believe that an over reliance on this type of represenative democracy is required or wise. As I see it, we're looking at two diffrent ways of running the show: A) Effiency. The most efficient method is to have a tiered methodology that requires results in exchange for privelege. This is, as Al once put it, "the carrot" model in some sense. The more you do, the higher up the ladder you climb. All votes and decisions are made by the smallest pool of persons possible with the largest possible influence and experience. This makes votes quick, efficient, and wide reaching. The persons who cast their votes are also the persons expected to carry out the result and therefore more likely to do "the right thing"(tm). B) Openness. Giving as much power to as many people as possible and thus empowering everyone who desires the ability to be involved whether they are productive or not. Catoring to the lowest common denominator has its problems, and complicates votes due to large numbers of voters, many of which may be uninformed on what exactly they are voting on and what results will impact them in the future, etc. But "openness" is about trusting in the good nature of man and his ability to excercies his own judgement, for good or bad, wisely or unwisely. Glass half empty or half full. There is, in my opinion, no easy answer and definately the sort of problem that you just know you'll feel diffrently about down the road when you have that wonderful 20/20 vision that history provides. Thankfully we have a lot of models to rely on and gather experience from. I can't help but avoid raising a point that Keith hates so much: that of apperances. An important thing to consider as we debate these things is whether or not we're making decisions based on whats right or what looks good. Obviously we'd rather show off how many voting members we have and be able to tell every user that they are empowered by simply being interested... but thats not without its problems as I noted above. I'm trying my best to seperate the two and do the good Vulcan thing. Personally I prefer to be as open as possible, something that will undoubtadly be popular... however, if we encounter large amounts of abuse, see projects stalled or held up, and if we don't see a large interest in even becoming an observer, then I may very quickly change my opinion. I will say that in looking at projects like GNOME and KDE, I was supprised that the voting restrictions were pretty strict. Most projects seem to prefer a system by which you are nominated for membership by other members and chosen based on merit. I'd _think_ that this would be very controversial, but apparently its not. And speaking of merit... I personally believe that there is a big problem with giving voting privs to persons based on their contributions. Its nearly impossible to quantify. Look at persons like Dennis Clarke, Al Hopper, James Dickens, myself, and a dozen others... I don't think any of us have code contributions (putbacks) to our names, nor documenation contributions in any official sense. Never the less, I don't think anyone would deny us voting privs or suggest that we aren't valued and important members of the community. If we are to based privs or status based on contributions we need to have some standard by which we judge. All the existing bylaws and constitutions seem intentially vague in this reguard. Telling persons that they should just keep contributing and being involved untill "it happens" isn't right, imho, there should be some sort of goal or threshold by which people can judge. Sadly, establishing such a goal is extremely difficult, which is why we're all left with vaugery and the word "significant" rather than a specific metric. I think that the options on the table are fairly clear and the most important goal at this point in time is to decide which of the two positions above (open or effecient) we want to work from, or even to decide that there is a better way. Once we work out that, I think things will start falling into place swiftly. benr. From benr at cuddletech.com Wed May 3 00:26:55 2006 From: benr at cuddletech.com (Ben Rockwood) Date: Wed, 03 May 2006 00:26:55 -0700 Subject: [cab-discuss] Considering Membership In-Reply-To: <44582554.3090405@sun.com> References: <4457D9CF.10702@cuddletech.com> <4457EFFE.1050604@Sun.Com> <20060503000354.GC141739@eng.sun.com> <44582554.3090405@sun.com> Message-ID: <44585B3F.2050903@cuddletech.com> John Plocher wrote: > Stephen Hahn wrote: > >> * John Plocher [2006-05-02 16:44]: >> >>> [good questions elided] >> >> [and a good response, as well] > > > > The core of the OpenSolaris ARC process is simply the explicit intent > to be proactive (instead of reactive) about changes that affect the > component and systems architecture of OpenSolaris. As long as this > intent makes it into the constitution, the details of how it is > implemented don't belong there - we don't want to have a > constitutional referendum every time we tweak the processes we use. Agreed. So long as some person is responsible for ensuring the need is met, the rest can be left up to the various communities. The simplest way to enact that is to simply make it the responsibility of the community lead and to allow that person to delegate as they see fit. This allows flexibility in handling community sub-projects, where its unlikely that the single Community Lead is going to be the appropriate ARC interface. In essence, we treat communities like states. The states do as the states please, their business is their own, but should the federal government has a question, somebody better come up with a response or the governor is gonna answer for it. A simple stipulation in the constitution would be that each community provide at all times a current list of the ARC liaisons, ensuring that the ARC can find the persons they need but still leaving the flexibility for the communities to change those persons as often as they need. benr. From benr at cuddletech.com Wed May 3 01:14:59 2006 From: benr at cuddletech.com (Ben Rockwood) Date: Wed, 03 May 2006 01:14:59 -0700 Subject: [cab-discuss] Community Organization Revisited Message-ID: <44586683.6020406@cuddletech.com> In paralell to the discussion about voting, membership and rights, we need to consider how this fits together with the project organization. Early on I believed that we needed strictly outline the overall project organization, however I no longer see that as a requirement of solid goverance and have embrased a more open and flexable way of thinking. Never the less, the fact remains that we have currently 40 communities. Some are active, some are not. For review of prior discussions please review the following threads on CAB-Discuss: - The Constitution and Organizational Structure (Ben Rockwood, et al) - Community demotion process thoughts (Stephen Hahn, et al) Based on prior discussion it seems clear that pruning or re-organizing is a non-trivial thing and any efforts to do so shouldn't be based on goverance, but on the overall needs of the project, which can change over time. However, if we are to make expectations (namely, liaisons) of communities I believe we must outline which communities are pivotal and must be well oiled machines, and which are of lesser importance and therefore be less stringently managed. The following is a list of all the current 40 communities: Academic and Research Appliances Approachability * Architecture Process and Tools BrandZ Chinese Users * Community Advisory Board (CAB) DTrace Desktop Device Drivers Documentation Fault Management GNU Solaris Games on OpenSolaris Immigrants Installation and Packaging Internationalization and Localization Laptop * Marketing Modular Debugger (MDB) NFS Networking * Nevada Development Observability OpenSolaris Printing Performance PowerPC Security Service Management Facility (smf(5)) Solaris Volume Manager Storage Systems Administrators Testing * Tools Unix File Systems (UFS) User Groups X Window System Xen ZFS Zones I would move that the communities marked with a * be deemed "Core Communities", which is to say: Communities that form the eyes, ears, and limbs of the project as a whole. The major organs of OpenSolaris, if you will. I think re-organizing all of the communities would be nicer on paper but since that isn't practical, simply naming certain communities as Core solves the problem as is more flexable over time. This is really about setting expectations. The communities I've chosen above are, I believe, OpenSolaris dependancies that facilitate the function of the other communities. Expecting that all 40 communities will have a proper hierarchy of dev, core dev, lead, ARC liaison(s), etc, is unlikely I think. Furthermore, expecting that these persons will be constantly active and engaged is also unlikely. The alternative, I believe, is to revist the "demotion process" thread and using the approved hierarchy and responsablities guidelines as a basis for destroying (ie: consolidating) communities that can't, won't, or don't meet the guidelines. If this is redundant to existing discussions feel free to disreguard or consolidate the threads as needbe. benr. PS: To which community do the website folks report? If they aren't already a part of one of these core communities they should be (I assume they are "Marketing" above) so that they fit into the natural delegation of authority like the ARC, OGB, and Tools communities do. From fielding at gbiv.com Wed May 3 03:02:51 2006 From: fielding at gbiv.com (Roy T. Fielding) Date: Wed, 3 May 2006 03:02:51 -0700 Subject: [cab-discuss] Considering Membership In-Reply-To: <44585927.8060105@cuddletech.com> References: <4457D9CF.10702@cuddletech.com> <20060503000030.GB141739@eng.sun.com> <44585927.8060105@cuddletech.com> Message-ID: <9E35E222-432F-4234-B384-1AFBAE434616@gbiv.com> On May 3, 2006, at 12:17 AM, Ben Rockwood wrote: > Could you please expand on this? Why is it too low? Has it caused > problems? What have the demonstrated pro's and con's been? In any given open source project, the number of observers outnumber the actual contributors from 10:1 (an *unsuccessful* project) to 1000:1 (Apache httpd). Do you have any idea how annoying it would be to have a design vote and have the long-time contributers be outvoted by a crowd of fools? The developers would immediately cease using the voting mechanism to make decisions, actual decisions move to private conversations, and soon there is no community involvement in the actual development process. Crowds are not intelligent. In general, the more people you give the right to vote, the lower the quality of the initiatives need to be in order to satisfy the vocal minority interests. OO.org may call a lot of people members, but that is only because their votes have no binding effect. It is better to let observers "vote" within the issue tracking system and restrict governance to people actually recognized as having a vested interest in the decisions. The fact of the matter is that the number of trolls paying attention to opensolaris mailing list outnumbers the developers currently paying attention to those lists. Community is, by definition, a sense of communal effort toward a common goal. Observers are not part of the community. ....Roy From benr at cuddletech.com Wed May 3 03:19:35 2006 From: benr at cuddletech.com (Ben Rockwood) Date: Wed, 03 May 2006 03:19:35 -0700 Subject: [cab-discuss] Goverance Questions Message-ID: <445883B7.5080304@cuddletech.com> I'd like to compile an list of questions that should be addressed prior to writting the second draft of the constitution. The following is a list of questions I think should be pondered, some are new, some are old, but I'm gathering them here to streamline things: 1) Projects are currently independant of any community. Should all projects be re-organized to be parented by an existing community? 2) Should new project proposals be made and approved solely at the community level or should an additional entity (ARC?) sign off on it prior to acceptance? 3) To what extent shall the OGB have he ability to intervine in Community (in the OpenSolaris.org sense, such as the Docs Community) affairs? Does the OGB have veto powers? Does this power extend to the ARC? 4) At what level of involvement and/or contribution is a person given voting rights? What is the scope of that influence? 5) What pre-defined levels of involvement shall exist? (eg: Developer, Core Developer, etc) 6) Under what guidelines may new communities be formed? Does this need to be defined in the Constitution or left flexable? 7) To what extent much communities conform with guidelines? (ie: Liaison's, voting rights, etc) Do these guidelines need to be in the Constitution and to what extent shall they be inforced? 8) What should the future composition of the OGB be? How many? What distribution? 9) Should an OGB quorum be required for OGB/CAB Con-Calls (or any type of OGB "meeting") to be considered official? 10) What will be the accepted method of executing an election? (ie: Proposing it, Approving it, Gathering votes, Method of voting, etc) 11) To what extent will Sun Microsystems Inc have the ability to intervien in OpenSolaris matters? Will Sun have a golden veto? 12) Should SCA's be required for all community members at a certain level (ie: "Developer") reguardless of whether its strictly needed or not to provide consistancy? (eg: Should marketing "contributors" obtain SCA's?) 13) Does the "Release Manager" need to be officially recognized for each community? 14) Should certain communities be considered "Core Communities" and held to a diffrent standard than others? (eg: ARC, Tools, OGB, Website/Docs/Marketing.. Communities that are required to execute the fundamental needs of OpenSolaris.) 15) To what extent should guidelines and proceedures that may not be suitable for inclusing in the Constitution be moved into another document? An official "Amendments" doc that can more easily be augmented over time as needed or some other less official doc? 16) By what means shall contributions be quantified? Is this neccisary? 17) By what means shall persons be considered to be "promoted" to a "Developer", "Core Developer", etc? (eg: you apply? nominated/recommended by peers? etc) 18) Should time constraints or limits be placed on status? ("Emeritus Members") Are there "term limits"? Are community leaders perminant, subject to election/re-election on a regular basis, or is it left to the individual community to decide? And this isn't a complete list. Sorry to dump so much of this on the list at one time but there is a lot to consider and little time to do it. I can put this list on the Wiki or we can discuss it here and then plop the result into the existing "Constitutional Principles" wiki page. benr. From benr at cuddletech.com Wed May 3 03:28:37 2006 From: benr at cuddletech.com (Ben Rockwood) Date: Wed, 03 May 2006 03:28:37 -0700 Subject: [cab-discuss] Considering Membership In-Reply-To: <9E35E222-432F-4234-B384-1AFBAE434616@gbiv.com> References: <4457D9CF.10702@cuddletech.com> <20060503000030.GB141739@eng.sun.com> <44585927.8060105@cuddletech.com> <9E35E222-432F-4234-B384-1AFBAE434616@gbiv.com> Message-ID: <445885D5.7020305@cuddletech.com> Roy T. Fielding wrote: > On May 3, 2006, at 12:17 AM, Ben Rockwood wrote: > >> Could you please expand on this? Why is it too low? Has it caused >> problems? What have the demonstrated pro's and con's been? > > ...snip... > > The fact of the matter is that the number of trolls paying > attention to opensolaris mailing list outnumbers the developers > currently paying attention to those lists. Community is, by > definition, a sense of communal effort toward a common goal. > Observers are not part of the community. I'd agree more with "Observers aren't intrinsically part of the community", personally. I use a wider definition that in some senses perhaps isn't functionally practical, but thats unimportant to this discussion. I see your point and agree with it, however grudgingly. :) When I was reviewing various Constitutions and bylaws I was a little supprised that decision making in these projects was so limited. It makes sense, but I'd think that at some point some (or a multitude of) people would fight it was "too closed" or "too selective" or whatever. Has this ever been a problem for Apache? benr. From sommerfeld at sun.com Wed May 3 06:00:58 2006 From: sommerfeld at sun.com (Bill Sommerfeld) Date: Wed, 03 May 2006 09:00:58 -0400 Subject: [cab-discuss] Considering Membership In-Reply-To: <44582554.3090405@sun.com> References: <4457D9CF.10702@cuddletech.com> <4457EFFE.1050604@Sun.Com> <20060503000354.GC141739@eng.sun.com> <44582554.3090405@sun.com> Message-ID: <1146661257.12360.357.camel@localhost> On Tue, 2006-05-02 at 23:36, John Plocher wrote: > As long as this > intent makes it into the constitution, the details of how it is > implemented don't belong there - we don't want to have a > constitutional referendum every time we tweak the processes we use. +1 The existing arc processes, as implemented, are extremely flexible and get tweaked all the time. The overarching goal is a good engineering result. All the rules can't be written down in advance... - Bill From John.Plocher at Sun.Com Wed May 3 08:58:43 2006 From: John.Plocher at Sun.Com (John Plocher) Date: Wed, 03 May 2006 08:58:43 -0700 Subject: [cab-discuss] Considering Membership In-Reply-To: <44585927.8060105@cuddletech.com> References: <4457D9CF.10702@cuddletech.com> <20060503000030.GB141739@eng.sun.com> <44585927.8060105@cuddletech.com> Message-ID: <4458D333.1090105@Sun.Com> Ben Rockwood wrote: > The major flaw that is in this model would be the ability for someone to > become an observer for a community once a ballot was presented, solely > for the perposes of influencing that community. It seems what we are trying to legislate here is the concept of "people that are doing the work get to make the decisions" I'm not sure that it is worth the effort of nailing down each and every possible way one might violate this expectation; rather we should leverage the "we trust you community leaders to make good decisions and to self-identify and deal with bad behavior" mindset. Internal to Sun, the ARC process works this way - the ARC members who have involved themselves in the details of a particular case are the ones who are expected to vote. Others, who have not, are expected to recuse themselves. Rather than have a bunch of rules to protect against misuse, we have a simple formal rule set and fall back on a few axioms to help us deal with exceptions: Rule: The Committee must have Quorum in order to conduct official business. Quorum is defined to be "50% of the ARC's Membership + 1 Rule: The Committee Chair establishes who is eligible to vote. The default is "all ARC members who have participated in the review of a project" who are "present when the vote is called". Exceptions and additions here may include explicit inclusion of members from other ARCs, absentee votes, email voting with an explicit deadline, proxies, etc. Rule: Voting members identify themselves and the vote they are casting: o Approve o Deny o Abstain Abstention is appropriate when one is fully aware of the pros and cons of the case's architecture, but is neither willing nor unwilling to endorse the case. One can find oneself in this position when one believes that the case addresses an important problem for which a solution is desirable, yet the proposed solution is flawed, but not so badly so that the costs of the flaw outweigh the benefits of delivery. Abstention is a way of saying "I'm unwilling endorse this project, but I don't think rejecting it outright is appropriate, so I am willing to go with whatever the majority feels is right". o Not Participating Non-participation is just what its name suggests: a member who, while they were present for the review and vote, effectively did not take part in evaluating the case. It's appropriate when one is not in a position to make a meaningful assessment of the case's architecture. An Example: Each ARC has many members, all of which are as usual, overloaded. With up to 3 cases/week, sometimes it is not possible for a member to be on top of everything, so some may structure their schedule such that they "pay attention" to some cases more than they do others. In this example, a member has chosen to pick "2 out of 3" to dive into. Of those 3 cases, then, this member would vote one of [ Approve, Deny, or Abstain ] on the two they spent time on, and [ Not Participating ] on the other one, even though they may have been present (but not mentally engaged) for its review. Rule: Approval is by simple majority: The number of Approve's are greater than the number of Deny's. Abstain's and Not Presents only count towards quorum, and do not influence approval or rejection. Rule: Ties are broken explicitly by the Chair, who gets to issue an additional tie-breaking vote. (that vote is usually, but not always, the same as the one the Chair cast earlier...) -------------------------------------------------- Axiom: Since we are trusting the participants to use their best judgment in all the other areas of their job, there is no reason to not do so here. Self selection of "did I participate enough to have a say in the outcome?" is sufficient. Axiom: The company/community has other mechanisms for identifying and dealing with participants who don't exhibit good judgment. They include negative feedback to managers during reviews, exclusion from the ARC's membership and, at an extreme, discontinued participation in the biweekly paycheck program. Axiom: The cost/risk/effect of someone "breaking the rules" is lower and more manageable than crafting a complex set of rules to catch the worst case "what if" of bad behavior. I hope this perspective is of some use in this discussion. -John From John.Plocher at Sun.Com Wed May 3 09:18:13 2006 From: John.Plocher at Sun.Com (John Plocher) Date: Wed, 03 May 2006 09:18:13 -0700 Subject: [cab-discuss] Considering Membership In-Reply-To: <44585B3F.2050903@cuddletech.com> References: <4457D9CF.10702@cuddletech.com> <4457EFFE.1050604@Sun.Com> <20060503000354.GC141739@eng.sun.com> <44582554.3090405@sun.com> <44585B3F.2050903@cuddletech.com> Message-ID: <4458D7C5.8090505@Sun.Com> Ben Rockwood wrote: > [good stuff] >In essence, we treat communities like states. The states do as the > states please, their business is their own, [nit] The tension in the architecture world is between "what is good for the micro-focused project" -vs- "what is good for the macro-focused systems that have dependencies on the project". At Sun, we have used the courts (case law, opinions...) and the building permit system (release taxonomy (zoning), consolidations) as models for what the ARCs do; I'm not sure how well a distributed/federated model captures that intent. A state's rights model implies (to me) that architectural micro- optimization is normative and macro-architectural systems engineering is the exception. Instead, I am trying to ensure that we have two cooperating peer architectural roles - one focused on the micro level and another on the macro level. There needs to be significant overlap of people in those two roles, otherwise it becomes an Us-vs-Them stalemate, where everyone loses. For me, State-vs-Federal brings up too many of the Us-vs-Them images :-( > A simple stipulation in the > constitution would be that each community provide at all times a current > list of the ARC liaisons, ensuring that the ARC can find the persons > they need but still leaving the flexibility for the communities to > change those persons as often as they need. +1 -John From sch at eng.sun.com Wed May 3 09:30:39 2006 From: sch at eng.sun.com (Stephen Hahn) Date: Wed, 3 May 2006 09:30:39 -0700 Subject: [cab-discuss] Considering Membership In-Reply-To: <44585927.8060105@cuddletech.com> References: <4457D9CF.10702@cuddletech.com> <20060503000030.GB141739@eng.sun.com> <44585927.8060105@cuddletech.com> Message-ID: <20060503163039.GC145897@eng.sun.com> * Ben Rockwood [2006-05-03 00:18]: > I personally believe that there is a big problem with giving voting > privs to persons based on their contributions. Its nearly impossible to > quantify. Look at persons like Dennis Clarke, Al Hopper, James Dickens, > myself, and a dozen others... I don't think any of us have code > contributions (putbacks) to our names, nor documenation contributions in > any official sense. Never the less, I don't think anyone would deny us > voting privs or suggest that we aren't valued and important members of > the community. If we are to based privs or status based on > contributions we need to have some standard by which we judge. All the > existing bylaws and constitutions seem intentially vague in this > reguard. Telling persons that they should just keep contributing and > being involved untill "it happens" isn't right, imho, there should be > some sort of goal or threshold by which people can judge. Sadly, > establishing such a goal is extremely difficult, which is why we're all > left with vaugery and the word "significant" rather than a specific metric. I'll reply to this message in full, but I want to emphasize that I simply disagree with the assertion of impossibility embedded in this paragraph. We have a Marketing community, a Sysadmin community, a User Groups community, and the OGB itself that should be able to represent non-code/non-documentation contributions. I think each of the people in your list have made one or more investments of time and energy that would make them viable as documented contributors from one of these communities, or perhaps one or more of the more product oriented communities. If you believe we need a specific threshold, then we should actually try to establish that threshold. Thresholds that might work: - leaders of a community - commit rights on a consolidation - two or more sponsored integrations to a consolidation - leaders of an endorsed project - author, editor, or provider of one or more documents/sites/blogs deemed "notable" by a community, - identified by a community as an "exceptional forum participant", - represented OpenSolaris or community thereof at one or more conferences/shows/industry meetings, - publisher or participant in a distribution viewed as "cooperating" by the OGB, where each of these could be for a finite period of time. If we use a scheme like this, who's left out that shouldn't be? - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems stephen.hahn at sun.com http://blogs.sun.com/sch/ From John.Plocher at Sun.Com Wed May 3 09:42:43 2006 From: John.Plocher at Sun.Com (John Plocher) Date: Wed, 03 May 2006 09:42:43 -0700 Subject: [cab-discuss] Goverance Questions In-Reply-To: <445883B7.5080304@cuddletech.com> References: <445883B7.5080304@cuddletech.com> Message-ID: <4458DD83.6030907@Sun.Com> Ben Rockwood wrote: > 2) Should new project proposals be made and approved solely at the > community level or should an additional entity (ARC?) sign off on it > prior to acceptance? In my view, starting a project is simply the beginning of a prototyping effort. That effort has two possible outcomes - either it succeeds or it fails. If it fails, it hasn't bothered anyone, hasn't used scarce "core resources", etc. No big deal, especially since we have avoided the "if it is hard to 'try, and then fail', we end up with nobody ever 'trying'" trap. If a project is successful in its prototyping (i.e., answering its core unknowns), that success can be demonstrated by a proposal: "This project intends to do in way." That *proposal* is what the community and the ARC should evaluate and run with. Community sign-off means "yes we want this to happen and are willing to let it integrate when it is complete". ARC sign-off means "the changes this project makes to the community architecture, and the effect of those changes on the systems that depend on the community, are understood and acceptable". > 3) To what extent shall the OGB have he ability to intervine in > Community (in the OpenSolaris.org sense, such as the Docs Community) > affairs? Does the OGB have veto powers? Does this power extend to the > ARC? If a project proposes something that violates the architectural expectations that have been set (at a micro-community or at a macro-systems level), the ARC needs to be able to say NO, and have it stick. If there are no teeth, the ARC process is a waste of time, will be a source of frustration, and will ultimately fail. > 7) To what extent must communities conform with guidelines? (ie: > Liaison's, voting rights, etc) Do these guidelines need to be in the > Constitution and to what extent shall they be inforced? They should not be enumerated in the constitution, but such a list should be referenced from it. The list should be able to evolve without reinvoking a constitutional crisis. Enforcement should be tied to benefits - in order for your community to have a say in , you must conform with these guidelines... > 14) Should certain communities be considered "Core Communities" and held > to a diffrent standard than others? (eg: ARC, Tools, OGB, > Website/Docs/Marketing.. Communities that are required to execute the > fundamental needs of OpenSolaris.) I like this idea, but as you say, it needs more thought. > > 15) To what extent should guidelines and proceedures that may not be > suitable for inclusing in the Constitution be moved into another > document? An official "Amendments" doc that can more easily be > augmented over time as needed or some other less official doc? The constitution needs to be the "architecture" of this organization; the "design" and "implementation" need to be distinct; more than one implementation should be possible and still meet the architectural requirements. (what else did you expect me to say :-) -John From sch at eng.sun.com Wed May 3 09:52:36 2006 From: sch at eng.sun.com (Stephen Hahn) Date: Wed, 3 May 2006 09:52:36 -0700 Subject: [cab-discuss] Community Organization Revisited In-Reply-To: <44586683.6020406@cuddletech.com> References: <44586683.6020406@cuddletech.com> Message-ID: <20060503165235.GD145897@eng.sun.com> * Ben Rockwood [2006-05-03 01:15]: > PS: To which community do the website folks report? If they aren't > already a part of one of these core communities they should be (I assume > they are "Marketing" above) so that they fit into the natural delegation > of authority like the ARC, OGB, and Tools communities do. The Website community was grandfathered, but I've never let it be published. The infrastructure work answers to multiple masters; it is most closely associated with Tools and the OGB, with input from Marketing and ARC. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems stephen.hahn at sun.com http://blogs.sun.com/sch/ From webmink at sun.com Wed May 3 10:55:10 2006 From: webmink at sun.com (Simon Phipps) Date: Wed, 03 May 2006 18:55:10 +0100 Subject: [cab-discuss] Community Organization Revisited In-Reply-To: <44586683.6020406@cuddletech.com> References: <44586683.6020406@cuddletech.com> Message-ID: <252FAD71-A89A-470E-8B91-76A12E4A9B75@sun.com> On May 3, 2006, at 09:14, Ben Rockwood wrote: > > Based on prior discussion it seems clear that pruning or re- > organizing is a non-trivial thing and any efforts to do so > shouldn't be based on goverance, but on the overall needs of the > project, which can change over time. > > However, if we are to make expectations (namely, liaisons) of > communities I believe we must outline which communities are pivotal > and must be well oiled machines, and which are of lesser importance > and therefore be less stringently managed. I think this approach is sound - promote the core communities rather than demote the non-=core ones. S. From sch at eng.sun.com Wed May 3 11:06:56 2006 From: sch at eng.sun.com (Stephen Hahn) Date: Wed, 3 May 2006 11:06:56 -0700 Subject: [cab-discuss] Community Organization Revisited In-Reply-To: <252FAD71-A89A-470E-8B91-76A12E4A9B75@sun.com> References: <44586683.6020406@cuddletech.com> <252FAD71-A89A-470E-8B91-76A12E4A9B75@sun.com> Message-ID: <20060503180656.GF145897@eng.sun.com> * Simon Phipps [2006-05-03 10:55]: > On May 3, 2006, at 09:14, Ben Rockwood wrote: > > > > >Based on prior discussion it seems clear that pruning or re- > >organizing is a non-trivial thing and any efforts to do so > >shouldn't be based on goverance, but on the overall needs of the > >project, which can change over time. > > > >However, if we are to make expectations (namely, liaisons) of > >communities I believe we must outline which communities are pivotal > >and must be well oiled machines, and which are of lesser importance > >and therefore be less stringently managed. > > I think this approach is sound - promote the core communities rather > than demote the non-=core ones. I don't think I understood what a core community is, other than a community that the OGB expects to be operational, in some abstract sense. Is there more to it than that? Since I know that the DTrace and ZFS communities are primary entry points to the wider community (and at times have had more subscribers to their discussions than opensolaris-discuss), I would want to understand what constitutes "coreness", since it's apparently not significance to the membership... (I've been wandering around to various inert communities to encourage them to start proposing their self-demotion, by the way.) - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems stephen.hahn at sun.com http://blogs.sun.com/sch/ From rich.teer at rite-group.com Wed May 3 13:56:26 2006 From: rich.teer at rite-group.com (Rich Teer) Date: Wed, 03 May 2006 13:56:26 -0700 (PDT) Subject: [cab-discuss] Goverance Questions In-Reply-To: <445883B7.5080304@cuddletech.com> References: <445883B7.5080304@cuddletech.com> Message-ID: On Wed, 3 May 2006, Ben Rockwood wrote: Goo dlist of questions. Here are my opinions/answers: > 1) Projects are currently independant of any community. Should all projects > be re-organized to be parented by an existing community? Yes, at least for "official" Open Solaris projects. > 2) Should new project proposals be made and approved solely at the community > level or should an additional entity (ARC?) sign off on it prior to > acceptance? I think that the leaders of the community to which the project would belong should make this decision. The OGB could, perhaps, be used as a court of appeal. > 3) To what extent shall the OGB have he ability to intervine in Community (in > the OpenSolaris.org sense, such as the Docs Community) affairs? Does the OGB > have veto powers? Does this power extend to the ARC? I see the OGB serving two roles (as we discussed on today's con call): 1. The court of "final appeal". 2. Determoning the stratgeic direction of Open Solaris. I don't think the OGB should intervene too much in the day to day running of communities. > 6) Under what guidelines may new communities be formed? Does this need to be > defined in the Constitution or left flexable? I think communities (as opposed to projects) should be kept to a reasonably small number, so I think the barrier to creating a new community should be relatively high. > 8) What should the future composition of the OGB be? How many? What > distribution? I think we discussed this a while back. ISTR 7 being considered a good number of members. > 9) Should an OGB quorum be required for OGB/CAB Con-Calls (or any type of OGB > "meeting") to be considered official? Yes. > 11) To what extent will Sun Microsystems Inc have the ability to intervien in > OpenSolaris matters? Will Sun have a golden veto? I thbink Sun's ability should be as small as possible (as outlined in the Chgarter), and they should not have a golden veto. HOwever, what Sun does with it's distribution of OpenSolaris (i.e., Solaris) is their business and they can do with it what they will, at their sole discretion. An example of this would be the proposed reintroduction of 64-bit UltraSPARC-I support. Sun has good business reasons for not wantong this (support costs and the like), but that's not a reason the OpenSOlaris project to not support US-I. > 12) Should SCA's be required for all community members at a certain level (ie: > "Developer") reguardless of whether its strictly needed or not to provide > consistancy? (eg: Should marketing "contributors" obtain SCA's?) DUnno. SOunds like a leagal issue to me. > 13) Does the "Release Manager" need to be officially recognized for each > community? It probably wouldn';t be a bad idea. > 14) Should certain communities be considered "Core Communities" and held to a > diffrent standard than others? (eg: ARC, Tools, OGB, Website/Docs/Marketing.. > Communities that are required to execute the fundamental needs of > OpenSolaris.) Good question. WHile I thonk that there will naturally be communities that are percieved as being more "core" than others, I think all communities should be held to the same standards. > 16) By what means shall contributions be quantified? Is this neccisary? I don't think quatification is necessary; community peers have a pretty good knack of recognizing contributions (most of the tme). > 17) By what means shall persons be considered to be "promoted" to a > "Developer", "Core Developer", etc? (eg: you apply? nominated/recommended by > peers? etc) I like the idea of being able to "apply" or being nominated. Bootstrapping issues aside, I'd say that one's peers would be a good judgment of whether such an applicatpon would be successful. > 18) Should time constraints or limits be placed on status? ("Emeritus > Members") Are there "term limits"? Are community leaders perminant, subject > to election/re-election on a regular basis, or is it left to the individual > community to decide? Good questiopn. I think some descision can be left to the community level, but others might need a wider polling scope. Sorry for any bad typoing: I have new contact lenses in, so I can't see too clearly! -- Rich Teer, SCNA, SCSA, OpenSolaris CAB member President, Rite Online Inc. Voice: +1 (250) 979-1638 URL: http://www.rite-group.com/rich From benr at cuddletech.com Thu May 4 00:08:53 2006 From: benr at cuddletech.com (Ben Rockwood) Date: Thu, 04 May 2006 00:08:53 -0700 Subject: [cab-discuss] Community Organization Revisited In-Reply-To: <44593C66.1080002@sun.com> References: <44586683.6020406@cuddletech.com> <44593C66.1080002@sun.com> Message-ID: <4459A885.2050204@cuddletech.com> Glynn Foster wrote: > Hi, > > Ben Rockwood wrote: > >> Based on prior discussion it seems clear that pruning or >> re-organizing is a non-trivial thing and any efforts to do so >> shouldn't be based on goverance, but on the overall needs of the >> project, which can change over time. > > > Yeah, I think we entirely became far too structured before we really > thought out the consequences. I don't think re-organizing is too big a > deal - however, I do think we'd absolutely have to get it 100% correct > if we were to do this. > >> * Nevada Development > > > I disagree with this one. Nevada currently doesn't reflect a community > that will be around while the OpenSolaris project is alive - it's a > project name for Solaris 11, of limited timeframe. > >> * Tools > > > Why Tools and not others? I'm not sure I grok this one. > >> I would move that the communities marked with a * be deemed "Core >> Communities", which is to say: Communities that form the eyes, ears, >> and limbs of the project as a whole. The major organs of >> OpenSolaris, if you will. > > > I'd probably just have the CAB in that category - others are just > teams, projects or processes. I put Nevada on the "core list" because its the central focus of the project, OpenSolaris's core. Obviously a better more perminant name for that community is actually needed, but untill such time as a new community name is chosen or migrated to, Nevada would be the one. I put Tools on the list because the SCM and tools that provide access to the stuff we're building together as a community is central to the operation of OpenSolaris. Again, these communities are deemed "Core" in my view because if I were on the OGB I'd expect that these communities would be expected to live up to a higher standard than the others. If the Xen community is idle for 3 months its not a problem, but if ARC, Tools, Marketing, or OGB go limp we have a seriuos problem.... imho. benr. From benr at cuddletech.com Thu May 4 01:31:07 2006 From: benr at cuddletech.com (Ben Rockwood) Date: Thu, 04 May 2006 01:31:07 -0700 Subject: [cab-discuss] Governance SkratchPad Message-ID: <4459BBCB.9010707@cuddletech.com> I've created a SkratchPad to facilitate our discussion. (http://www.genunix.org/wiki/index.php/OpenSolaris_Governing_Board_SketchPad) I've put up a proposal for membership and organization, named "Proposal A", see it here: http://www.genunix.org/wiki/index.php/Roles_and_Responsibilities_Discussion Please note that this proposal is one possible scenerio and certainly not my ownly possible proposal. Please edit/comment/hack on it as you see fit. benr. From Simon.Phipps at Sun.COM Thu May 4 03:08:49 2006 From: Simon.Phipps at Sun.COM (Simon Phipps) Date: Thu, 04 May 2006 11:08:49 +0100 Subject: [cab-discuss] Governance SkratchPad In-Reply-To: <4459BBCB.9010707@cuddletech.com> References: <4459BBCB.9010707@cuddletech.com> Message-ID: <75EB54AE-AA01-4D6B-B9D8-916BBC5C8FBC@Sun.COM> On May 4, 2006, at 09:31, Ben Rockwood wrote: > I've created a SkratchPad to facilitate our discussion. (http:// > www.genunix.org/wiki/index.php/OpenSolaris_Governing_Board_SketchPad) > > I've put up a proposal for membership and organization, named > "Proposal A", see it here: > http://www.genunix.org/wiki/index.php/ > Roles_and_Responsibilities_Discussion > > Please note that this proposal is one possible scenerio and > certainly not my ownly possible proposal. Please edit/comment/hack > on it as you see fit. Thanks Ben, looks interesting. I've tinkered with it a little: * adding subsections to make editing easier, * I added to the OGB responsibilities liaison with other entities outside OpenSolaris * I reformatted the OGB elections section & clarified in places * I believe nominations should be seconded, just to discourage frivolous nominations * I added a mechanism to resolve the situation where more than 2/3 of an elected OGB are Sun employees I'm not wedded to any of these changes in detail. I also think we need: * a duration after which Contributor status needs to be renewed (18 months?) * a preferred mechanism for Contributors to be recognised & gain that status (peer election?) rather than just "any means" - communities should be able to vary it but should start with something. * a duration after which a Core Contributor status needs to be renewed I'll take a stab at writing some words once others have commented, if necessary. S. From Glynn.Foster at Sun.COM Wed May 3 16:27:34 2006 From: Glynn.Foster at Sun.COM (Glynn Foster) Date: Thu, 04 May 2006 11:27:34 +1200 Subject: [cab-discuss] Community Organization Revisited In-Reply-To: <44586683.6020406@cuddletech.com> References: <44586683.6020406@cuddletech.com> Message-ID: <44593C66.1080002@sun.com> Hi, Ben Rockwood wrote: > Based on prior discussion it seems clear that pruning or re-organizing > is a non-trivial thing and any efforts to do so shouldn't be based on > goverance, but on the overall needs of the project, which can change > over time. Yeah, I think we entirely became far too structured before we really thought out the consequences. I don't think re-organizing is too big a deal - however, I do think we'd absolutely have to get it 100% correct if we were to do this. > * Nevada Development I disagree with this one. Nevada currently doesn't reflect a community that will be around while the OpenSolaris project is alive - it's a project name for Solaris 11, of limited timeframe. > * Tools Why Tools and not others? I'm not sure I grok this one. > I would move that the communities marked with a * be deemed "Core > Communities", which is to say: Communities that form the eyes, ears, and > limbs of the project as a whole. The major organs of OpenSolaris, if > you will. I'd probably just have the CAB in that category - others are just teams, projects or processes. Glynn From Glynn.Foster at Sun.COM Wed May 3 16:31:34 2006 From: Glynn.Foster at Sun.COM (Glynn Foster) Date: Thu, 04 May 2006 11:31:34 +1200 Subject: [cab-discuss] Goverance Questions In-Reply-To: References: <445883B7.5080304@cuddletech.com> Message-ID: <44593D56.6040605@sun.com> Hi, Rich Teer wrote: > > I see the OGB serving two roles (as we discussed on today's con call): > > 1. The court of "final appeal". > > 2. Determoning the stratgeic direction of Open Solaris. > > I don't think the OGB should intervene too much in the day to day running > of communities. +1 The OGB is a board set up to make sure that the OpenSolaris project has all the resources it needs to be a successful project. It is a non-technical body, and probably has its closest ties to the Marketing project, and User Group community. I'm not even sure it should be responsible for 2 either, FWIW. Glynn From Glynn.Foster at Sun.COM Wed May 3 16:14:15 2006 From: Glynn.Foster at Sun.COM (Glynn Foster) Date: Thu, 04 May 2006 11:14:15 +1200 Subject: [cab-discuss] Considering Membership In-Reply-To: <9E35E222-432F-4234-B384-1AFBAE434616@gbiv.com> References: <4457D9CF.10702@cuddletech.com> <20060503000030.GB141739@eng.sun.com> <44585927.8060105@cuddletech.com> <9E35E222-432F-4234-B384-1AFBAE434616@gbiv.com> Message-ID: <44593947.9000203@sun.com> Hi, Roy T. Fielding wrote: > On May 3, 2006, at 12:17 AM, Ben Rockwood wrote: > >> Could you please expand on this? Why is it too low? Has it caused >> problems? What have the demonstrated pro's and con's been? > > In any given open source project, the number of observers outnumber > the actual contributors from 10:1 (an *unsuccessful* project) to > 1000:1 (Apache httpd). Do you have any idea how annoying it > would be to have a design vote and have the long-time contributers > be outvoted by a crowd of fools? The developers would immediately > cease using the voting mechanism to make decisions, actual > decisions move to private conversations, and soon there > is no community involvement in the actual development process. I personally don't think we should encourage voting mechanisms as a regular thing in our daily development. Decisions should be made by mutual consensus, by those people doing the active development wherever possible. > Observers are not part of the community. While I agree with your arguments, I disagree with this statement. I think if we automatically exclude observers from the community, then there's less of a chance that those observers will turn developers at a later stage. Encouragement is everything. Glynn From Glynn.Foster at Sun.COM Tue May 2 18:09:54 2006 From: Glynn.Foster at Sun.COM (Glynn Foster) Date: Wed, 03 May 2006 13:09:54 +1200 Subject: [cab-discuss] AI 2: Example bylaws/constitutions In-Reply-To: <20060503002637.GA143373@eng.sun.com> References: <20060501221041.GA124583@eng.sun.com> <22839952-BE9E-451D-8F10-A978862BCF78@gbiv.com> <4457AA0A.90004@cuddletech.com> <4457EA48.1050208@sun.com> <20060503002637.GA143373@eng.sun.com> Message-ID: <445802E2.9010303@sun.com> Hi, Stephen Hahn wrote: > Since you're a member, do you mind outlining how the GNOME Foundation > membership's process works, where it's had trouble (if it has), and > perhaps say what is or is not suitable for OpenSolaris to copy or > emulate? [having problems after an edgemail server migration, so none of my mails seem to be getting through to the opensolaris lists atm...] The GNOME Foundation is pretty informal compared to groups like Apache, OpenOffice or others. In the past, we've had a membership policy where people could only be members depending on their contributions. The wording was 'non-trivial' improvement, thus encouraging submissions from those people who had continually been involved in the project either by fixing or triaging a number of bugs, providing documentation or translations or maintenance of project wide infrastructure or resources. Membership had a 2 year expiration. Having that 'non-trivial' policy caused a good deal of stress to the membership committee who would take these applications, process them and either accept or reject based on their contributions and references they provided. The membership committee is a non-technical committee, so being able to accurately process these applications was difficult at times - more so, when the application wasn't an already outstanding and visible community member. More often than not, right before the GNOME Foundation elections to elect a new board of directors, you would see a slew of people renewing their membership so they could vote. Other times, while you may have had a relatively large membership, half of the membership was dormant, so you would get an election turnout of well less than 50%. Other problems were people who were submitting membership renewals, had contributed in the past, but weren't currently active. This came to a head with a pretty large flamewar and we had to re-think where we wanted to go and who we wanted to be. Nat's mail has a good description of where we stand now - http://mail.gnome.org/archives/foundation-list/2002-October/msg00026.html Glynn From Glynn.Foster at Sun.COM Tue May 2 16:24:56 2006 From: Glynn.Foster at Sun.COM (Glynn Foster) Date: Wed, 03 May 2006 11:24:56 +1200 Subject: [cab-discuss] AI 2: Example bylaws/constitutions In-Reply-To: <4457AA0A.90004@cuddletech.com> References: <20060501221041.GA124583@eng.sun.com> <22839952-BE9E-451D-8F10-A978862BCF78@gbiv.com> <4457AA0A.90004@cuddletech.com> Message-ID: <4457EA48.1050208@sun.com> Hey, Ben Rockwood wrote: > The model I find most interesting to this point is OpenOffices. Its not > perfect for us, but a much more suitable setting, I think, than used for > Apache. Namely, the fact that becoming an empowered voting member in > the OpenOffice project is very straight forward and open for anyone to > obtain if they desire, whereas the Apache model is much more exclusive > in nature. Both for the sake of management as well as openness I think > thats the way to go. I completely agree with Ben - I think it's absolutely vital to encourage openness in all facets of the governance model as much as possible. Lowering that barrier to entry of being part of the OpenSolaris community is hugely valuable to creating something bigger IMO. Glynn From John.Plocher at Sun.Com Thu May 4 09:36:22 2006 From: John.Plocher at Sun.Com (John Plocher) Date: Thu, 04 May 2006 09:36:22 -0700 Subject: [cab-discuss] Governance SkratchPad In-Reply-To: <75EB54AE-AA01-4D6B-B9D8-916BBC5C8FBC@Sun.COM> References: <4459BBCB.9010707@cuddletech.com> <75EB54AE-AA01-4D6B-B9D8-916BBC5C8FBC@Sun.COM> Message-ID: <445A2D86.6090302@Sun.Com> Simon Phipps wrote: > Thanks Ben, looks interesting. I've tinkered with it a little: As did I: I'm not sure how far to push this, but I'm concerned about the misalignment between the organizational structures being discussed and those presumed to exist by the Development/ARC process. This misalignment is almost certainly caused by not having a set of shared operational definitions. As a step to help define things better, I added a note under the Organisation heading: [plocher] It would be good to think about how we can create a structure that reflects our procedural requirement to "develop bugfixes, rfe's and feature additions in a SCM environment that is distinct from a Project's master gate". Without such structure as a first-class concept, it becomes difficult to ensure that we proactively understand and approve all such changes, and processes such as the ARC have a difficult time fitting into the workflow. In Sun's internal nomenclature, a single source code repository is called a Consolidation. The collective noun for "the people and artifacts associated with a specific change to a consolidation" is a Project. Thus, the construction of a new version of the ON Consolidation involves the creation, execution, integration and dissolusion of hundreds of Projects. Sometimes, such as when a new feature is added (such as Zones), the effort to create, the resulting source code artifacts, and the team tasked with sustaining it are ALL called Projects; this certainly causes confusion :-) From keith.wesolowski at sun.com Thu May 4 09:50:40 2006 From: keith.wesolowski at sun.com (Keith M Wesolowski) Date: Thu, 4 May 2006 09:50:40 -0700 Subject: [cab-discuss] Considering Membership In-Reply-To: <44593947.9000203@sun.com> References: <4457D9CF.10702@cuddletech.com> <20060503000030.GB141739@eng.sun.com> <44585927.8060105@cuddletech.com> <9E35E222-432F-4234-B384-1AFBAE434616@gbiv.com> <44593947.9000203@sun.com> Message-ID: <20060504165040.GA8738@sun.com> On Thu, May 04, 2006 at 11:14:15AM +1200, Glynn Foster wrote: > I personally don't think we should encourage voting mechanisms as a > regular thing in our daily development. Decisions should be made by > mutual consensus, by those people doing the active development wherever > possible. > > > Observers are not part of the community. > > While I agree with your arguments, I disagree with this statement. I > think if we automatically exclude observers from the community, then > there's less of a chance that those observers will turn developers at a > later stage. Encouragement is everything. I'm going to disagree with Ben but for a different reason: Communities exist to inform development. Input from would-be consumers of technology is critical to its successful design and implementation; a community of people including both users and engineers centered around a particular feature set (or vertical slice of the software stack, if you will) is the model I'd like to encourage. In this model, observers absolutely are members of the community, and valued ones at that. This does not mean I am suggesting that every observer, or perhaps even any observer, be given a voting role. Those roles ought to be reserved for actual contributors - the people who do the work that makes software happen. That work absolutely includes more than just code, and other contributors within a given community are in the best position to evaluate what constitutes a contribution. We should provide the communities with guidance as to where we believe the threshold should be (and I'd like to see it be very high indeed), but ultimately the communities are free to admit as many or as few contributors as they see fit. Perhaps our greatest challenge will be the establishment of the initial contributor base. Glynn and others may wish to argue that a disenfranchised participant is no participant at all. I disagree. There is no reason to give the vote to a person with limited interest in or knowledge of the technology areas governed by a community; he or she is free to participate in the community's information of projects, to everyone's benefit, without voting on project endorsement, OGB membership, or the technical readiness of a project for integration. The openness of the source and developement process to all means that anyone is free to make both code and non-code contributions at any time, and by doing so bolster his or her case for contributorship. In no world is everyone born a king; rather, the existence of vertical mobility is paramount. -- Keith M Wesolowski "Sir, we're surrounded!" Solaris Kernel Team "Excellent; we can attack in any direction!" From sch at eng.sun.com Thu May 4 10:07:42 2006 From: sch at eng.sun.com (Stephen Hahn) Date: Thu, 4 May 2006 10:07:42 -0700 Subject: [cab-discuss] Governance SkratchPad In-Reply-To: <75EB54AE-AA01-4D6B-B9D8-916BBC5C8FBC@Sun.COM> References: <4459BBCB.9010707@cuddletech.com> <75EB54AE-AA01-4D6B-B9D8-916BBC5C8FBC@Sun.COM> Message-ID: <20060504170742.GC155305@eng.sun.com> * Simon Phipps [2006-05-04 03:09]: > > On May 4, 2006, at 09:31, Ben Rockwood wrote: > * a duration after which Contributor status needs to be renewed (18 > months?) The duration needs to be somehow related to the term of an OGB seat, the frequency of elections if those seats are staggered, and the number of elections for which a contributor is deemed eligible. If we said 7 seats, every two years, then two years would be a reasonable contributor duration. If we staggered the seats, so that 2 or 3 seats (three year term) or 3 or 4 seats (two year term) came up every year, then two years would also be a reasonable duration. If we made terms one year, then one year or 18 months or two years would all make sense. GNOME has shown that there is a non-negligible bureaucratic load with one year active membership renewals; this load may not be as severe if the decentralized model is used, but it may still be too heavy. - 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 May 4 10:45:14 2006 From: sch at eng.sun.com (Stephen Hahn) Date: Thu, 4 May 2006 10:45:14 -0700 Subject: [cab-discuss] Governance SkratchPad In-Reply-To: <445A2D86.6090302@Sun.Com> References: <4459BBCB.9010707@cuddletech.com> <75EB54AE-AA01-4D6B-B9D8-916BBC5C8FBC@Sun.COM> <445A2D86.6090302@Sun.Com> Message-ID: <20060504174514.GD155305@eng.sun.com> * John Plocher [2006-05-04 09:31]: > Simon Phipps wrote: > >Thanks Ben, looks interesting. I've tinkered with it a little: > > > As did I: > > I'm not sure how far to push this, but I'm concerned about > the misalignment between the organizational structures being > discussed and those presumed to exist by the Development/ARC > process. This misalignment is almost certainly caused by > not having a set of shared operational definitions. > > As a step to help define things better, I added a note under > the Organisation heading: > > [plocher] > > It would be good to think about how we can create a > structure that reflects our procedural requirement > to "develop bugfixes, rfe's and feature additions > in a SCM environment that is distinct from a Project's > master gate". Without such structure as a first-class > concept, it becomes difficult to ensure that we > proactively understand and approve all such changes, > and processes such as the ARC have a difficult time > fitting into the workflow. > > In Sun's internal nomenclature, a single source code > repository is called a Consolidation. The collective > noun for "the people and artifacts associated with a > specific change to a consolidation" is a Project. > Thus, the construction of a new version of the ON > Consolidation involves the creation, execution, > integration and dissolusion of hundreds of Projects. > Sometimes, such as when a new feature is added (such > as Zones), the effort to create, the resulting source > code artifacts, and the team tasked with sustaining it > are ALL called Projects; this certainly causes confusion :-) I suppose this point is one of the aspects I was interested in regarding Ben's "core communities" idea. It seemed quite reasonable for the OGB to just state that certain communities are expected to be responsible for the hosting, management, and publication of one or more consolidations. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems stephen.hahn at sun.com http://blogs.sun.com/sch/ From John.Plocher at Sun.Com Thu May 4 12:10:29 2006 From: John.Plocher at Sun.Com (John Plocher) Date: Thu, 04 May 2006 12:10:29 -0700 Subject: [cab-discuss] Governance SkratchPad - operational definition of 'Project' In-Reply-To: <20060504174514.GD155305@eng.sun.com> References: <4459BBCB.9010707@cuddletech.com> <75EB54AE-AA01-4D6B-B9D8-916BBC5C8FBC@Sun.COM> <445A2D86.6090302@Sun.Com> <20060504174514.GD155305@eng.sun.com> Message-ID: <445A51A5.4030001@Sun.Com> Stephen Hahn wrote: > I suppose this point is one of the aspects I was interested in > regarding Ben's "core communities" idea. It seemed quite reasonable > for the OGB to just state that certain communities are expected to be > responsible for the hosting, management, and publication of one or > more consolidations. How does this help us align expectations that changes to all OpenSolaris code originate from Projects and (at a relatively fine granularity) all such changes must be both Community accepted and ARC approved? At the core of my concern are the conflicting definitions of a Project that are all in use today in OpenSolaris, many of which don't align with these expectations: The OpenSolaris Project: http://www.opensolaris.org An open source community and a place for collaboration and conversation around OpenSolaris technology. ['Project' here seems to mean "long lived community of enthusiasts playing with a wide range of technologies"] OpenSolaris Projects http://www.opensolaris.org/os/projects/ OpenSolaris projects are collaborative efforts that produce objects such as code changes, documents, graphics, or collaboratively authored products. Projects will have code repositories and committers and can live within a community or independently. ['Project' here seems to mean everything from "short lived sub-community focused on a single bugfix or new feature connected to a larger community", all the way to "long lived self contained community creating and delivering products". It is this latter extreme that concerns me] Nevada Project (labeled as such on the top level OpenSolaris web site pages) http://www.opensolaris.org/os/community/onnv/ Nevada is Sun's code name for the Solaris release after Solaris 10. OpenSolaris and Nevada are built from the same source base. The focus of this community is OS/Net (ON) developers working on Nevada and OpenSolaris ['Project' here is used (possibly incorrectly) as a synonym for 'Community'] Nevada's OS Dev Process definition of Project http://www.opensolaris.org/os/community/onnv/os_dev_process/ A project is a technical effort involving one or more people that is working in an open manner; the specific outcome of a project is to produce a small number of coordinated technical artifacts. A project has one or more source repositories, each of which is intended to in some way be published. A project may choose that its primary form of publication is through one or more consolidations, although this is not necessary. A project has at least one distinction between those actively working on the project (contributors) as opposed to people merely interested in the project's progress (members). [This 'Project' is closest to what I'd expect (from an ARC perspective, though the phrase "A project may choose that its primary form of publication is through one or more consolidations, although this is not necessary" gives it a lot of wiggle room] -John From Glynn.Foster at Sun.COM Thu May 4 13:29:10 2006 From: Glynn.Foster at Sun.COM (Glynn Foster) Date: Fri, 05 May 2006 08:29:10 +1200 Subject: [cab-discuss] Governance SkratchPad In-Reply-To: <20060504170742.GC155305@eng.sun.com> References: <4459BBCB.9010707@cuddletech.com> <75EB54AE-AA01-4D6B-B9D8-916BBC5C8FBC@Sun.COM> <20060504170742.GC155305@eng.sun.com> Message-ID: <445A6416.5080306@sun.com> Hey, Stephen Hahn wrote: > The duration needs to be somehow related to the term of an OGB seat, > the frequency of elections if those seats are staggered, and the > number of elections for which a contributor is deemed eligible. > > If we said 7 seats, every two years, then two years would be a > reasonable contributor duration. And a significant commitment for most people - I personally believe that it's hard to maintain focus and enthusiasm for such a role for a 2 year term. Obviously the other argument is providing consistency, and a stable board. > If we staggered the seats, so that 2 or 3 seats (three year term) or 3 > or 4 seats (two year term) came up every year, > then two years would also be a reasonable duration. How would you decide the 2 year positions? Otherwise I think there's definitely some merit in that. > If we made terms one year, then one year or 18 months or two years > would all make sense. GNOME has shown that there is a non-negligible > bureaucratic load with one year active membership renewals; this load > may not be as severe if the decentralized model is used, but it may > still be too heavy. If you take the 'membership is for life' mantra, then a lot of it can be automated, assuming that it would be a membership renewal rather than a new application. The load usually increases when it comes up to the elections though when a lot of new contributors finally decide to join the GNOME foundation - there's not a huge amount of point joining other than to take part in the annual elections, other than pride of being part of something larger. Glynn From sch at eng.sun.com Thu May 4 13:32:23 2006 From: sch at eng.sun.com (Stephen Hahn) Date: Thu, 4 May 2006 13:32:23 -0700 Subject: [cab-discuss] Governance SkratchPad In-Reply-To: <445A6416.5080306@sun.com> References: <4459BBCB.9010707@cuddletech.com> <75EB54AE-AA01-4D6B-B9D8-916BBC5C8FBC@Sun.COM> <20060504170742.GC155305@eng.sun.com> <445A6416.5080306@sun.com> Message-ID: <20060504203223.GH155305@eng.sun.com> * Glynn Foster [2006-05-04 13:26]: > > If we staggered the seats, so that 2 or 3 seats (three year term) or 3 > > or 4 seats (two year term) came up every year, > > then two years would also be a reasonable duration. > > How would you decide the 2 year positions? Otherwise I think there's > definitely some merit in that. My sentence was unclear. If there were two year terms, then the seats would come up three one year, then four the next. If there were three year terms, then the seats would come up two, two, and three. The non-profit that my wife and I share a board seat on has twelve seats, mixed between three year and one year terms. It has 9 3-years and 3 1-years, meaning every year there are six positions available. The highest three ballot getters receive the three year seats. - Stephen From sch at eng.sun.com Thu May 4 13:42:59 2006 From: sch at eng.sun.com (Stephen Hahn) Date: Thu, 4 May 2006 13:42:59 -0700 Subject: [cab-discuss] Governance SkratchPad - operational definition of 'Project' In-Reply-To: <445A51A5.4030001@Sun.Com> References: <4459BBCB.9010707@cuddletech.com> <75EB54AE-AA01-4D6B-B9D8-916BBC5C8FBC@Sun.COM> <445A2D86.6090302@Sun.Com> <20060504174514.GD155305@eng.sun.com> <445A51A5.4030001@Sun.Com> Message-ID: <20060504204258.GI155305@eng.sun.com> * John Plocher [2006-05-04 12:05]: > Stephen Hahn wrote: > > I suppose this point is one of the aspects I was interested in > > regarding Ben's "core communities" idea. It seemed quite reasonable > > for the OGB to just state that certain communities are expected to be > > responsible for the hosting, management, and publication of one or > > more consolidations. > > How does this help us align expectations that > changes to all OpenSolaris code originate from > Projects and (at a relatively fine granularity) > all such changes must be both Community accepted > and ARC approved? > > At the core of my concern are the conflicting > definitions of a Project that are all in use > today in OpenSolaris, many of which don't align > with these expectations: > > The OpenSolaris Project: > http://www.opensolaris.org > An open source community and a place for > collaboration and conversation around > OpenSolaris technology. > > ['Project' here seems to mean "long lived > community of enthusiasts playing with > a wide range of technologies"] Agreed, this use of project is not consistent with any definition. The OGB should probably suggest a new noun, possibly "Effort". (Or, dare I say, "Community"? :) ) > Nevada Project (labeled as such on the top level > OpenSolaris web site pages) > http://www.opensolaris.org/os/community/onnv/ > Nevada is Sun's code name for the Solaris > release after Solaris 10. OpenSolaris and > Nevada are built from the same source base. > The focus of this community is OS/Net (ON) > developers working on Nevada and OpenSolaris > > ['Project' here is used (possibly incorrectly) > as a synonym for 'Community'] Agreed, this use of project is also problematic. There needs to be an ON community, and an ONNV project. > OpenSolaris Projects > http://www.opensolaris.org/os/projects/ > OpenSolaris projects are collaborative > efforts that produce objects such as code > changes, documents, graphics, or collaboratively > authored products. Projects will have code > repositories and committers and can live > within a community or independently. > > ['Project' here seems to mean everything > from "short lived sub-community focused > on a single bugfix or new feature connected > to a larger community", all the way to > "long lived self contained community > creating and delivering products". It > is this latter extreme that concerns me > > Nevada's OS Dev Process definition of Project > http://www.opensolaris.org/os/community/onnv/os_dev_process/ > A project is a technical effort involving one or > more people that is working in an open manner; the > specific outcome of a project is to produce a small > number of coordinated technical artifacts. A project > has one or more source repositories, each of which > is intended to in some way be published. A project > may choose that its primary form of publication is > through one or more consolidations, although this > is not necessary. A project has at least one > distinction between those actively working on the > project (contributors) as opposed to people merely > interested in the project's progress (members). > > [This 'Project' is closest to what I'd expect > (from an ARC perspective, though the phrase > "A project may choose that its primary form of > publication is through one or more consolidations, > although this is not necessary" gives it a lot > of wiggle room] I guess that I don't see these latter two as in deep conflict. If a particular collaborative effort is long-lived, yet never seeks to follow the formalities required to be published by a consolidation, what problem arises? As a concrete example, I would be fine if the various KDE experts created a "KDE on Solaris" project on opensolaris.org, that provided documentation and packages (and source patches), but never sought to find or form a consolidation to make them responsible for a particular distribution's reported problems. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems stephen.hahn at sun.com http://blogs.sun.com/sch/ From Glynn.Foster at Sun.COM Thu May 4 13:59:48 2006 From: Glynn.Foster at Sun.COM (Glynn Foster) Date: Fri, 05 May 2006 08:59:48 +1200 Subject: [cab-discuss] Considering Membership In-Reply-To: <20060504165040.GA8738@sun.com> References: <4457D9CF.10702@cuddletech.com> <20060503000030.GB141739@eng.sun.com> <44585927.8060105@cuddletech.com> <9E35E222-432F-4234-B384-1AFBAE434616@gbiv.com> <44593947.9000203@sun.com> <20060504165040.GA8738@sun.com> Message-ID: <445A6B44.3050706@sun.com> Hi, Keith M Wesolowski wrote: > Glynn and others may wish to argue that a disenfranchised participant > is no participant at all. I disagree. There is no reason to give the > vote to a person with limited interest in or knowledge of the > technology areas governed by a community; he or she is free to > participate in the community's information of projects, to everyone's > benefit, without voting on project endorsement, OGB membership, or the > technical readiness of a project for integration. The openness of the > source and developement process to all means that anyone is free to > make both code and non-code contributions at any time, and by doing so > bolster his or her case for contributorship. In no world is everyone > born a king; rather, the existence of vertical mobility is paramount. No, I agree with that. My concerns were more about the wording of things - making sure that *every* possible level is a 'valued community member'. It's absolutely important for members to develop their own profile and build a circle of trust based on their contributions to the project. Glynn From webmink at sun.com Thu May 4 14:01:57 2006 From: webmink at sun.com (Simon Phipps) Date: Thu, 04 May 2006 22:01:57 +0100 Subject: [cab-discuss] Considering Membership In-Reply-To: <44593947.9000203@sun.com> References: <4457D9CF.10702@cuddletech.com> <20060503000030.GB141739@eng.sun.com> <44585927.8060105@cuddletech.com> <9E35E222-432F-4234-B384-1AFBAE434616@gbiv.com> <44593947.9000203@sun.com> Message-ID: <12EF334C-9403-4F81-AD40-5DFA9E2AE064@sun.com> On May 4, 2006, at 00:14, Glynn Foster wrote: > Hi, > > Roy T. Fielding wrote: >> On May 3, 2006, at 12:17 AM, Ben Rockwood wrote: >>> Could you please expand on this? Why is it too low? Has it >>> caused problems? What have the demonstrated pro's and con's been? >> In any given open source project, the number of observers outnumber >> the actual contributors from 10:1 (an *unsuccessful* project) to >> 1000:1 (Apache httpd). Do you have any idea how annoying it >> would be to have a design vote and have the long-time contributers >> be outvoted by a crowd of fools? The developers would immediately >> cease using the voting mechanism to make decisions, actual >> decisions move to private conversations, and soon there >> is no community involvement in the actual development process. > > I personally don't think we should encourage voting mechanisms as a > regular thing in our daily development. Decisions should be made by > mutual consensus, by those people doing the active development > wherever possible. The two are not mutually exclusive. Apache communities I observe use Apache-style voting as a very effective means to express consensus (as well as identify who is going to actually do the work!) S. From al at logical-approach.com Thu May 4 14:10:44 2006 From: al at logical-approach.com (Al Hopper) Date: Thu, 4 May 2006 16:10:44 -0500 (CDT) Subject: [cab-discuss] Goverance Questions In-Reply-To: <44593D56.6040605@sun.com> References: <445883B7.5080304@cuddletech.com> <44593D56.6040605@sun.com> Message-ID: On Thu, 4 May 2006, Glynn Foster wrote: > Hi, > > Rich Teer wrote: > > > > I see the OGB serving two roles (as we discussed on today's con call): > > > > 1. The court of "final appeal". > > > > 2. Determoning the stratgeic direction of Open Solaris. > > > > I don't think the OGB should intervene too much in the day to day running > > of communities. > > +1 The OGB is a board set up to make sure that the OpenSolaris project > has all the resources it needs to be a successful project. It is a > non-technical body, and probably has its closest ties to the Marketing ^^^^^^^^^^^^^^^^^^ It can't be a non-technical body - because many of the decisions on a project that involves _development_ of code, requires some reasonable level of understanding of this technical/engineering discipline. Not all the OGB members would need to be highly technical - I'll agree. And remember that the OGB may form sub-committees, or working groups etc. to help in an area(s) that might be outside of its collective expertize. In any event, the voting membership will determine the technical expertize of the OGB, by selecting the OGB members, based on their votes. Hopefully they will "choose wisely" and vote in members with varied skills and backgrounds. > project, and User Group community. > > I'm not even sure it should be responsible for 2 either, FWIW. ?? If the OGB is not responsible for the "stratgeic direction of Open Solaris" ... then who is? Al Hopper Logical Approach Inc, Plano, TX. al at logical-approach.com Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005 From John.Plocher at Sun.Com Thu May 4 14:18:03 2006 From: John.Plocher at Sun.Com (John Plocher) Date: Thu, 04 May 2006 14:18:03 -0700 Subject: [cab-discuss] Governance SkratchPad - operational definition of 'Project' In-Reply-To: <20060504204258.GI155305@eng.sun.com> References: <4459BBCB.9010707@cuddletech.com> <75EB54AE-AA01-4D6B-B9D8-916BBC5C8FBC@Sun.COM> <445A2D86.6090302@Sun.Com> <20060504174514.GD155305@eng.sun.com> <445A51A5.4030001@Sun.Com> <20060504204258.GI155305@eng.sun.com> Message-ID: <445A6F8B.2020704@Sun.Com> Stephen Hahn wrote: > I guess that I don't see these latter two as in deep conflict. If a > particular collaborative effort is long-lived, yet never seeks to > follow the formalities required to be published by a consolidation, > what problem arises? If I understand, you are suggesting that the ARC process isn't an expected OpenSolaris-wide way of doing business, but instead is only some sort of optional per-community (and possibly only the ONNV community's) formality? This is a huge -1 for me. An optional ARC process stuck on the end of a project's development cycle as a formality is worse than none at all, because no matter how much effort is expended, it is doomed to fail. We are (or at least I am) not trying to invent another "sourceforge" where we are agnostic about who plays in our sandbox; instead, we are/I am trying to create a culture that values basic "systems engineering" disciplines and uses them to create robust components and systems. If someone doesn't wish to adopt such a culture, and the processes that such a culture implies, they are free to go elsewhere. But if they are going to participate in the OpenSolaris meta-community, the ARC process needs to be integral to how we _all_ do development here. Of course, said ARC process must be natural and easy so that it does not become an impediment to the communities and developers who use it; thus my concerns that we are going down an organizational path that may force it to be unnatural and difficult... -John From Glynn.Foster at Sun.COM Thu May 4 14:39:56 2006 From: Glynn.Foster at Sun.COM (Glynn Foster) Date: Fri, 05 May 2006 09:39:56 +1200 Subject: [cab-discuss] Goverance Questions In-Reply-To: References: <445883B7.5080304@cuddletech.com> <44593D56.6040605@sun.com> Message-ID: <445A74AC.80804@sun.com> Hi, Al Hopper wrote: > It can't be a non-technical body - because many of the decisions on a > project that involves _development_ of code, requires some reasonable > level of understanding of this technical/engineering discipline. Not all > the OGB members would need to be highly technical - I'll agree. And > remember that the OGB may form sub-committees, or working groups etc. to > help in an area(s) that might be outside of its collective expertize. I'm not sure I completely agree with that. Given you experience of the last year of sitting on the CAB/OGB, have there been many heavily technical discussions? I think if technical discussion or direction was required, the OGB should set up working groups as you suggest, but that doesn't mean that the OGB has to be involved. For example, the GNOME Foundation board is a non-technical committee, and very purposely so. It is a final arbiter if and only if it is required. The GNOME Foundation board is set up to make sure that GNOME the project has all the necessary resources it needs to be successful - from fund raising, to outreach. Where required, the GNOME board delegates to working groups such as the release team, or marketing team for special tasks that are outside the scope of the foundation board so that it can concentrate on the things that are important. I'm not suggesting that OpenSolaris should necessarily adopt this approach, but just providing some examples of different communities for discussion. > In any event, the voting membership will determine the technical expertize > of the OGB, by selecting the OGB members, based on their votes. Hopefully > they will "choose wisely" and vote in members with varied skills and > backgrounds. I personally think that's unwise - I believe the OGB has a much more important role than providing technical direction for the project, and indeed, I think that separation is important. > ?? If the OGB is not responsible for the "stratgeic direction of Open > Solaris" ... then who is? The 'community' of course ;) Glynn From webmink at sun.com Thu May 4 14:56:38 2006 From: webmink at sun.com (Simon Phipps) Date: Thu, 04 May 2006 22:56:38 +0100 Subject: [cab-discuss] Goverance Questions In-Reply-To: <445A74AC.80804@sun.com> References: <445883B7.5080304@cuddletech.com> <44593D56.6040605@sun.com> <445A74AC.80804@sun.com> Message-ID: <172C3C62-DB87-41B4-9445-4787D41412ED@sun.com> On May 4, 2006, at 22:39, Glynn Foster wrote: > Hi, > > Al Hopper wrote: >> It can't be a non-technical body - because many of the decisions on a >> project that involves _development_ of code, requires some reasonable >> level of understanding of this technical/engineering discipline. >> Not all >> the OGB members would need to be highly technical - I'll agree. And >> remember that the OGB may form sub-committees, or working groups >> etc. to >> help in an area(s) that might be outside of its collective expertize. > > I'm not sure I completely agree with that. Given you experience of > the last year of sitting on the CAB/OGB, have there been many > heavily technical discussions? I think if technical discussion or > direction was required, the OGB should set up working groups as you > suggest, but that doesn't mean that the OGB has to be involved. > > For example, the GNOME Foundation board is a non-technical > committee, and very purposely so. It is a final arbiter if and only > if it is required. The GNOME Foundation board is set up to make > sure that GNOME the project has all the necessary resources it > needs to be successful - from fund raising, to outreach. Where > required, the GNOME board delegates to working groups such as the > release team, or marketing team for special tasks that are outside > the scope of the foundation board so that it can concentrate on the > things that are important. > > I'm not suggesting that OpenSolaris should necessarily adopt this > approach, but just providing some examples of different communities > for discussion. > >> In any event, the voting membership will determine the technical >> expertize >> of the OGB, by selecting the OGB members, based on their votes. >> Hopefully >> they will "choose wisely" and vote in members with varied skills and >> backgrounds. > > I personally think that's unwise - I believe the OGB has a much > more important role than providing technical direction for the > project, and indeed, I think that separation is important. > >> ?? If the OGB is not responsible for the "stratgeic direction of Open >> Solaris" ... then who is? > > The 'community' of course ;) > I completely agree with all Glynn's points. The OGB is the exception- handler. S. From rich.teer at rite-group.com Thu May 4 15:33:58 2006 From: rich.teer at rite-group.com (Rich Teer) Date: Thu, 04 May 2006 15:33:58 -0700 (PDT) Subject: [cab-discuss] Goverance Questions In-Reply-To: References: <445883B7.5080304@cuddletech.com> <44593D56.6040605@sun.com> Message-ID: On Thu, 4 May 2006, Al Hopper wrote: > ?? If the OGB is not responsible for the "stratgeic direction of Open > Solaris" ... then who is? AGreed. When I talked about the "strategic direction", I meant it in a similar sense to what Sun's management did prior to Solaris being opened. Management decided the strategic direction of Solaris, based on Sun's business needs and values. I still thinnk that that role, at least as far as Open Solaris is concerned, should pass to the OGB. (Sun's management will of course still determine the startegic dircetion of Sun's distro, Solaris.) -- Rich Teer, SCNA, SCSA, OpenSolaris CAB member President, Rite Online Inc. Voice: +1 (250) 979-1638 URL: http://www.rite-group.com/rich From Glynn.Foster at Sun.COM Thu May 4 15:48:59 2006 From: Glynn.Foster at Sun.COM (Glynn Foster) Date: Fri, 05 May 2006 10:48:59 +1200 Subject: [cab-discuss] Considering Membership In-Reply-To: <12EF334C-9403-4F81-AD40-5DFA9E2AE064@sun.com> References: <4457D9CF.10702@cuddletech.com> <20060503000030.GB141739@eng.sun.com> <44585927.8060105@cuddletech.com> <9E35E222-432F-4234-B384-1AFBAE434616@gbiv.com> <44593947.9000203@sun.com> <12EF334C-9403-4F81-AD40-5DFA9E2AE064@sun.com> Message-ID: <445A84DB.8060109@sun.com> Simon Phipps wrote: > The two are not mutually exclusive. Apache communities I observe use > Apache-style voting as a very effective means to express consensus (as > well as identify who is going to actually do the work!) Is this a common tool in their daily development, or only a last resort when there is a difference of opinion that can't be easily resolved? Are Apache the only community that use this voting mechanism? Glynn From webmink at sun.com Thu May 4 16:09:06 2006 From: webmink at sun.com (Simon Phipps) Date: Fri, 05 May 2006 00:09:06 +0100 Subject: [cab-discuss] Considering Membership In-Reply-To: <445A84DB.8060109@sun.com> References: <4457D9CF.10702@cuddletech.com> <20060503000030.GB141739@eng.sun.com> <44585927.8060105@cuddletech.com> <9E35E222-432F-4234-B384-1AFBAE434616@gbiv.com> <44593947.9000203@sun.com> <12EF334C-9403-4F81-AD40-5DFA9E2AE064@sun.com> <445A84DB.8060109@sun.com> Message-ID: <392330DA-94BB-4834-A1A3-6DACBFBEB500@sun.com> On May 4, 2006, at 23:48, Glynn Foster wrote: > > Simon Phipps wrote: >> The two are not mutually exclusive. Apache communities I observe >> use Apache-style voting as a very effective means to express >> consensus (as well as identify who is going to actually do the work!) > > Is this a common tool in their daily development, or only a last > resort when there is a difference of opinion that can't be easily > resolved? Are Apache the only community that use this voting > mechanism? > It appears to be routine, Roy can confirm or deny though. S. From al at logical-approach.com Thu May 4 18:55:00 2006 From: al at logical-approach.com (Al Hopper) Date: Thu, 4 May 2006 20:55:00 -0500 (CDT) Subject: [cab-discuss] Goverance Questions In-Reply-To: <445A74AC.80804@sun.com> References: <445883B7.5080304@cuddletech.com> <44593D56.6040605@sun.com> <445A74AC.80804@sun.com> Message-ID: On Fri, 5 May 2006, Glynn Foster wrote: > Hi, > > Al Hopper wrote: > > It can't be a non-technical body - because many of the decisions on a > > project that involves _development_ of code, requires some reasonable > > level of understanding of this technical/engineering discipline. Not all > > the OGB members would need to be highly technical - I'll agree. And > > remember that the OGB may form sub-committees, or working groups etc. to > > help in an area(s) that might be outside of its collective expertize. > > I'm not sure I completely agree with that. Given you experience of the > last year of sitting on the CAB/OGB, have there been many heavily > technical discussions? I think if technical discussion or direction was Yes. Three members of the CAB (Casper Dik, Rich Teer and I) were involved with the (formulation of) Development Process - with Casper wearing two hats: one as a Sun kernel developer intimately familiar with the existing development procedures and processes and one as a CAB member. Rich and I participated in the conf calls and discussions. Casper and I attended 3 days of face to face meetings (Rich could not free up the necessary time to attend) and later the entire CAB met with (almost) the entire Development Process team in face to face meetings in Portland. > required, the OGB should set up working groups as you suggest, but that > doesn't mean that the OGB has to be involved. In this case, we were fortunate that the technical expertize already existed within the CAB/OGB and there was no need to muddy the waters with another layer of people. > For example, the GNOME Foundation board is a non-technical committee, > and very purposely so. It is a final arbiter if and only if it is > required. The GNOME Foundation board is set up to make sure that GNOME > the project has all the necessary resources it needs to be successful - > from fund raising, to outreach. Where required, the GNOME board > delegates to working groups such as the release team, or marketing team > for special tasks that are outside the scope of the foundation board so > that it can concentrate on the things that are important. Perhaps you've just defined a weakness for _both_ the CAB/OGB and the GNOME Foundation: the CAB/OGB being too geeky and hands-on and the GNOME Foundation having too low a geek factor and being too hands off! :) > I'm not suggesting that OpenSolaris should necessarily adopt this > approach, but just providing some examples of different communities for > discussion. Understood. > > In any event, the voting membership will determine the technical expertize > > of the OGB, by selecting the OGB members, based on their votes. Hopefully > > they will "choose wisely" and vote in members with varied skills and > > backgrounds. > > I personally think that's unwise - I believe the OGB has a much more > important role than providing technical direction for the project, and > indeed, I think that separation is important. > > > ?? If the OGB is not responsible for the "stratgeic direction of Open > > Solaris" ... then who is? > > The 'community' of course ;) > > > Glynn > Al Hopper Logical Approach Inc, Plano, TX. al at logical-approach.com Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005 From Glynn.Foster at Sun.COM Thu May 4 19:28:44 2006 From: Glynn.Foster at Sun.COM (Glynn Foster) Date: Fri, 05 May 2006 14:28:44 +1200 Subject: [cab-discuss] Goverance Questions In-Reply-To: References: <445883B7.5080304@cuddletech.com> <44593D56.6040605@sun.com> <445A74AC.80804@sun.com> Message-ID: <445AB85C.9040602@sun.com> Hi, Al Hopper wrote: >>> It can't be a non-technical body - because many of the decisions on a >>> project that involves _development_ of code, requires some reasonable >>> level of understanding of this technical/engineering discipline. Not all >>> the OGB members would need to be highly technical - I'll agree. And >>> remember that the OGB may form sub-committees, or working groups etc. to >>> help in an area(s) that might be outside of its collective expertize. >> I'm not sure I completely agree with that. Given you experience of the >> last year of sitting on the CAB/OGB, have there been many heavily >> technical discussions? I think if technical discussion or direction was > > Yes. Three members of the CAB (Casper Dik, Rich Teer and I) were involved > with the (formulation of) Development Process - with Casper wearing two > hats: one as a Sun kernel developer intimately familiar with the existing > development procedures and processes and one as a CAB member. Rich and I > participated in the conf calls and discussions. Casper and I attended 3 > days of face to face meetings (Rich could not free up the necessary time > to attend) and later the entire CAB met with (almost) the entire > Development Process team in face to face meetings in Portland. Yeah, it's hard to know whether this is a good thing. In some ways this is very easy to do given that the project is relatively new, and small. Further down the track, doing these things may be more complicated and not an efficient use of the OGB's precious time. I'm probably just being devil's advocate on this one, and this is something that probably needs to be explicitly discussed as part of the constitution/charter, but I can see minefields ahead where people have misconceptions of what the OGB does, and the types of discussions that it gets involved in. It would be good to avoid those before they happen. Thanks for the reply though, it's been helpful. Glynn From Simon.Phipps at Sun.COM Fri May 5 04:02:44 2006 From: Simon.Phipps at Sun.COM (Simon Phipps) Date: Fri, 05 May 2006 12:02:44 +0100 Subject: [cab-discuss] Goverance Questions In-Reply-To: References: <445883B7.5080304@cuddletech.com> <44593D56.6040605@sun.com> <445A74AC.80804@sun.com> Message-ID: <6FA4FF0E-90BC-443D-A30D-2DB79CC19F9C@Sun.COM> On May 5, 2006, at 02:55, Al Hopper wrote: > On Fri, 5 May 2006, Glynn Foster wrote: > >> Hi, >> >> Al Hopper wrote: >>> It can't be a non-technical body - because many of the decisions >>> on a >>> project that involves _development_ of code, requires some >>> reasonable >>> level of understanding of this technical/engineering discipline. >>> Not all >>> the OGB members would need to be highly technical - I'll agree. And >>> remember that the OGB may form sub-committees, or working groups >>> etc. to >>> help in an area(s) that might be outside of its collective >>> expertize. >> >> I'm not sure I completely agree with that. Given you experience of >> the >> last year of sitting on the CAB/OGB, have there been many heavily >> technical discussions? I think if technical discussion or >> direction was > > Yes. Three members of the CAB (Casper Dik, Rich Teer and I) were > involved > with the (formulation of) Development Process - with Casper wearing > two > hats: one as a Sun kernel developer intimately familiar with the > existing > development procedures and processes and one as a CAB member. Rich > and I > participated in the conf calls and discussions. Casper and I > attended 3 > days of face to face meetings (Rich could not free up the necessary > time > to attend) and later the entire CAB met with (almost) the entire > Development Process team in face to face meetings in Portland. Actually, I see this differently. The CAB did /not/ have a technical discussion. Rather, some of the members of the CAB with the capacity to engage in the technical conversation went and joined the technical group, then came and reported back to the CAB. I continue to agree with Glynn here, the OGB is the exception handler, it is not the fount of highest wisdom. The Solaris community inside Sun is not dominated by a single individual or group, and neither should the OpenSolaris community be. S. From Eric.Boutilier at Sun.COM Fri May 5 07:02:08 2006 From: Eric.Boutilier at Sun.COM (Eric Boutilier) Date: Fri, 05 May 2006 09:02:08 -0500 Subject: [cab-discuss] Goverance Questions In-Reply-To: <6FA4FF0E-90BC-443D-A30D-2DB79CC19F9C@Sun.COM> References: <445883B7.5080304@cuddletech.com> <44593D56.6040605@sun.com> <445A74AC.80804@sun.com> <6FA4FF0E-90BC-443D-A30D-2DB79CC19F9C@Sun.COM> Message-ID: <445B5AE0.9070100@Sun.COM> Simon Phipps wrote: > > On May 5, 2006, at 02:55, Al Hopper wrote: > >> On Fri, 5 May 2006, Glynn Foster wrote: >> >>> Hi, >>> >>> Al Hopper wrote: >>> >>>> It can't be a non-technical body - because many of the decisions on a >>>> project that involves _development_ of code, requires some reasonable >>>> level of understanding of this technical/engineering discipline. >>>> Not all >>>> the OGB members would need to be highly technical - I'll agree. And >>>> remember that the OGB may form sub-committees, or working groups >>>> etc. to >>>> help in an area(s) that might be outside of its collective expertize. >>> >>> >>> I'm not sure I completely agree with that. Given you experience of the >>> last year of sitting on the CAB/OGB, have there been many heavily >>> technical discussions? I think if technical discussion or direction was >> >> >> Yes. Three members of the CAB (Casper Dik, Rich Teer and I) were >> involved >> with the (formulation of) Development Process - with Casper wearing two >> hats: one as a Sun kernel developer intimately familiar with the >> existing >> development procedures and processes and one as a CAB member. Rich and I >> participated in the conf calls and discussions. Casper and I attended 3 >> days of face to face meetings (Rich could not free up the necessary time >> to attend) and later the entire CAB met with (almost) the entire >> Development Process team in face to face meetings in Portland. > > > Actually, I see this differently. The CAB did /not/ have a technical > discussion. Rather, some of the members of the CAB with the capacity > to engage in the technical conversation went and joined the technical > group, then came and reported back to the CAB. I continue to agree > with Glynn here, the OGB is the exception handler, it is not the fount > of highest wisdom. The Solaris community inside Sun is not dominated > by a single individual or group, and neither should the OpenSolaris > community be. > +1 FWIW. From sch at eng.sun.com Fri May 5 09:41:58 2006 From: sch at eng.sun.com (Stephen Hahn) Date: Fri, 5 May 2006 09:41:58 -0700 Subject: [cab-discuss] Governance SkratchPad - operational definition of 'Project' In-Reply-To: <445A6F8B.2020704@Sun.Com> References: <4459BBCB.9010707@cuddletech.com> <75EB54AE-AA01-4D6B-B9D8-916BBC5C8FBC@Sun.COM> <445A2D86.6090302@Sun.Com> <20060504174514.GD155305@eng.sun.com> <445A51A5.4030001@Sun.Com> <20060504204258.GI155305@eng.sun.com> <445A6F8B.2020704@Sun.Com> Message-ID: <20060505164158.GA179323@eng.sun.com> * John Plocher [2006-05-04 14:13]: > Stephen Hahn wrote: > > I guess that I don't see these latter two as in deep conflict. If a > > particular collaborative effort is long-lived, yet never seeks to > > follow the formalities required to be published by a consolidation, > > what problem arises? > > If I understand, you are suggesting that the ARC process isn't > an expected OpenSolaris-wide way of doing business, but instead > is only some sort of optional per-community (and possibly only > the ONNV community's) formality? I believe that, much like the details of mapping the OpenSolaris development process to the current ARC implementation, the specifics of hosting technologies are not relevant to the constitution. The constitution is about membership (which drags in communities), the governing board (and so terms and elections), and the means used to reach decisions in a variety of scenarios. (I must comment that, if you accept that projects in the fourth sense are permitted to fail, then there is no conflict at all. Certainly we have seen projects fail at any of the four major stages in the process before; whether such projects are hosted at one site or another isn't the dominant issue. In particular, the Idea stage is hard to envision as a severely restricted portion of a project's maturation through the development process.) - Stephen From sch at eng.sun.com Tue May 9 16:08:16 2006 From: sch at eng.sun.com (Stephen Hahn) Date: Tue, 9 May 2006 16:08:16 -0700 Subject: [cab-discuss] A partially filled-in draft constitution Message-ID: <20060509230816.GA300304@eng.sun.com> I took the various comments from the past emails and the Wiki and decided to stuff something into one of the outlines I sent a couple of weeks ago. This version isn't complete, and I would say I'm still wrestling with aspects as basic as the order of presentation, but it's probably worth commenting upon. (Oh, and I invented a document numbering convention, too...) There are annotations--distinguished by deep indenting--at various points. I can insert this into the Wiki once I finish preliminary language of the later Articles. - Stephen --- The OpenSolaris Community Constitution [DRAFT] [OGB/2006/002] ARTICLE I. Name 1. This constitution governs the formation and operation of the social organization, known as "the OpenSolaris community". ARTICLE II. Purpose 1. The OpenSolaris community was founded to provide an organization capable of fostering the evolution and adoption of the OpenSolaris code base. (1) The organization is meant to flexibly respond to the changes of interest of the Membership. (2) The organization respects that these interests are diverse. 2. To this end, Sun Microsystems has chartered the creation of the OpenSolaris community, with responsibilities outlined in the OpenSolaris charter. (1) As part of that Charter, the OpenSolaris community possesses a Governing Board, empowered to manage and represent the OpenSolaris community as a whole. Reference: OGB/2006/001, "The OpenSolaris Charter". ARTICLE III. Communities 1. In order to recognize the diversity of interests, the OpenSolaris community is held to be composed of groups of members, called Communities. 2. A Community must be approved by the OpenSolaris community, via processes defined by its Governing Board. 3. Each Community has the right and responsibility to publish its contributing members, core contributing members, and alumni contributing members. From the publications of all Communities, the OpenSolaris community can identify its total contributing membership. (1) The period between such publications is set by the Governing Board, or a committee acting on its behalf. 4. The Governing Board can suspend the right of a Community to publish its contributing members, core contributing members, and alumni contributing members. In the event that the Governing Board permanently suspends this right, the Community is considered Demoted. ARTICLE IV. Membership The OpenSolaris community will attempt to publish the OpenSolaris code and the discussions concerning the development and adoption of that code in a public and equal manner, without requiring registration. However, for decision making and community governance purposes, the OpenSolaris community identifies four classes of contributor. A. Classes of membership 1. Contributing member ("Contributor"). (1) Contributors are eligible to stand for and vote in elections. Equivalently, a Contributor is a Voting Member. (2) Contributors are eligible for appointment to Board committees and Community committees. (3) Contributors have voting capabilities in Community decision making. 2. Core contributing member ("Core Contributor") (1) Core Contributors are eligible to stand for and vote in elections. Equivalently, a Core Contributor is a Voting Member. (2) Core Contributors are eligible for appointment to Board committees and Community committees. (3) Core Contributors are recognized with special voting capabilities in Community decision making. As covered in OGB/2006/003, "Recommended community decision making practices". (4) Core Contributors can represent their Community in meetings of the Governing Board or of committees created by the Governing Board. 3. Alumni contributing member ("Alumni Contributor"). (1) Alumni Contributors are not eligible to stand for elections. (2) Alumni Contributors are eligible to be appointed to Board committees, but not eligible for Community Committees. 4. Honorary Member. (1) Honorary Members are not eligible to stand for elections. (2) Honorary Members are not eligible for appointment to Board committees or Community committees. B. Requirements 1. All participating members must be registered in the OpenSolaris community database. 2. Contributors and Core Contributors must be named in at least one of the Contributor lists published by recognized Communities. 3. Core Contributors must have previously been identified as Contributors. 4. Alumni Contributors are Contributors who either no longer appear in the contribution lists published by Communities or have requested alumni status. 5. Honorary Members are named by the Governing Board. C. Procedure for application 1. A prospective Contributing member should apply to his or her Community. The Community can then approve or deny the application. 2. A prospective Core Contributor will be invited by the Core Contributors of the relevant Community. There is no petitioning process for a member to become a Core Contributor. 3. The Governing Board may grant Contributing Membership to an individual. This grant of Contributing Membership expires after a subsequent OpenSolaris election. The Contributor list from the Governing Board must be created and treated as equivalent to the Contributor lists of any other Community. ARTICLE V. Board of directors A. Membership 1. The OpenSolaris board of directors ("Governing Board") consists of seven (7) members. 2. Each Board Member must be a Contributor or Core Contributor. B. Officers of board 1. At the beginning of its term, the Governing Board must select a Chair, a Vice-Chair, and a Secretary. 2. The Chair directs the meetings of the Governing Board. In the Chair's absence, the Vice-Chair conducts the meetings. 3. The Secretary is responsible for taking minutes, revising those minutes, and publishing approved C. Duties and responsibilities of board 1. Attendance of Board meetings will be noted in the minutes. 2. [Resignations] D. Executive committee of board [Does the Board need an executive committee?] 1. Membership 2. Duties E. Meetings of board 1. The Governing Board will meet no fewer than four (4) times per year. 2. Open/Closed Sessions. F. Reports of board and executive committee 1. Annual report? ARTICLE VI. Meetings A. Annual: notice, business to be conducted, order of business 1. The Governing Board may choose to conduct an Annual Meeting. 180 days notice. B. Regular: notice, usual order of business C. Special: how called, notice ARTICLE VII. Committees A. Standing committees: list, membership, selection, duties, powers, meetings, reports The Governing Board may create additional standing committees, as outlined in OGB/2006/004, "Recommended practices for standing committees". Only the two required for conducting elections and managing the membership are defined here. 1. Elections and Membership Committee. (1) The Elections and Membership Committee ("Committee", for VII.A.1) will be chaired by a Board Member, appointed by the Governing Board. (2) The Committee Membership consists of the Chair, the remaining Board Members (ex officio), and no fewer than four (4) eligible Contributors appointed by the Governing Board. (3) The Committee may survey the Membership to determine the efficacy of current election procedures. (4) The Committee will direct and report on the results of all OpenSolaris community-wide elections. The Committee will issue an Election Report within three (3) days of the conclusion of an election. (5) The Committee will provide a printable ballot form and will provide a process for printed ballots to be submitted legitimately for all OpenSolaris community-wide elections. The primary method for ballot submission is to be electronic. (6) Unless a specific exemption is given by the Governing Board, thirty days (30) prior to any Governing Board election, the Committee will issue a Voting Membership Report. For this first election, the Governing Board is expected to compose a specific exemption that gives the Elections and Membership Committee a reduced publication lead time. (7) The Committee may request, no more than four (4) times per year, a list of Contributors and Core Contributors for each Community. (8) The Committee will archive and make available the requested lists of Contributors and Core Contributors. (9) The Committee will maintain and make available the list of Alumni Contributors. 2. Community evaluation committee. (1) The Community Evaluation Committee ("Committee", for VII.A.2) will be chaired by a Board Member, appointed by the Governing Board. (2) The Committee Membership consists of the Chair, the remaining Board Members (ex officio), and no fewer than four (4) eligible Contributors appointed by the Governing Board. (3) The Committee is responsible for the assessment of Community promotion and demotion, and the processes under which such assessments are made. (4) The Committee can recommend, via a report to the Governing Board, the promotion or demotion of a Community or the modification of the current assessment processes. Action on such recommendations is the responsibility of the Governing Board. (5) The Committee can promote or demote a Community, given a Governing Board directive to do so. (6) Unless a specific exemption is given by the Governing Board, Ninety (90) days The Committee For this first election, the Governing Board is expected to compose a specific exemption that gives the Elections and Membership Committee a reduced publication lead time. B. Special committees: provisions for selection 1. The Governing Board can create Special Committees by a specific motion. 2. Special Committees must have an identified purpose, powers, responsibilities, and lifetime. ARTICLE VIII. Terms of office 1. The term of a Board Member lasts from the 1st day of the calendar month following his or her election to the Governing Board until the 1st day of the calendar month following the subsequent Governing Board election. 2. A Board Member in his or her third (3) consecutive term of office is not eligible for the Governing Board elections held during that third consecutive term. ARTICLE IX. Elections 1. Governing Board elections are to be held annually. 2. Governing Board members are selected based on the balloting method known as "Single Transferable Vote". Reference: http://en.wikipedia.org/wiki/Single_Transferable_Vote http://accuratedemocracy.com/archive/stv/meekm.htm http://www.dia.govt.nz/diawebsite.NSF/Files/meekm/$file/meekm.pdf http://votesystem.sf.net/ http://stv.sf.net/ http://www.cix.co.uk/~rosenstiel/stvrules/ http://www.electoral-reform.org.uk/votingsystems/stvi.htm 3. Each Contributor or Core Contributor has one ballot for a Governing Board election. 4. Elections are to be held primarily using electronic means. ARTICLE XI. Quorum A. Meetings of organization [Do we need decision-making meetings for the membership as a whole? Or should we have a referenda/proposition model?] B. Meetings of board 1. A meeting of the Governing Board requires the attendance of five (5) Board Members. ARTICLE XII. Discipline and expulsion of members 1. The Governing Board may find that ARTICLE XIII. Parliamentary authority 1. The parliamentary authority for the operation of the OpenSolaris Community is A. Sturgis, The Standard Code of Parliamentary Procedure, 4th ed. ARTICLE XIV. Policies A. Provisions for adoption B. Vote required for adoption and amendment ARTICLE XV. Amendments to bylaws 1. ARTICLE XVI. Dissolution 1. The Governing Board may propose a referendum to dissolve with the passing of a motion with a supermajority consisting of two-thirds of the Board Members. 2. The OpenSolaris community, via referendum, may accept dissolution based on a two-thirds majority vote of all Voting Contributors. The Governing Board (or at least the Board Members proposing dissolution) should probably resign if the referendum result is to decline to dissolve. QQQ: Do we need a clause to this end? -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems stephen.hahn at sun.com http://blogs.sun.com/sch/ From benr at cuddletech.com Wed May 10 11:42:57 2006 From: benr at cuddletech.com (Ben Rockwood) Date: Wed, 10 May 2006 11:42:57 -0700 Subject: [cab-discuss] A partially filled-in draft constitution In-Reply-To: <20060509230816.GA300304@eng.sun.com> References: <20060509230816.GA300304@eng.sun.com> Message-ID: <44623431.4030803@cuddletech.com> Stephen Hahn wrote: > I took the various comments from the past emails and the Wiki and > decided to stuff something into one of the outlines I sent a couple > of weeks ago. > > This version isn't complete, and I would say I'm still wrestling with > aspects as basic as the order of presentation, but it's probably > worth commenting upon. (Oh, and I invented a document numbering > convention, too...) There are annotations--distinguished by deep > indenting--at various points. > > I can insert this into the Wiki once I finish preliminary language of > the later Articles. > Comments inline: > --- > > The OpenSolaris Community Constitution [DRAFT] > [OGB/2006/002] > > ARTICLE I. Name > > 1. This constitution governs the formation and operation of the > social organization, known as "the OpenSolaris community". > > ARTICLE II. Purpose > > 1. The OpenSolaris community was founded to provide an organization > capable of fostering the evolution and adoption of the OpenSolaris > code base. > > (1) The organization is meant to flexibly respond to the changes of > interest of the Membership. > > (2) The organization respects that these interests are diverse. > > 2. To this end, Sun Microsystems has chartered the creation of the > OpenSolaris community, with responsibilities outlined in the > OpenSolaris charter. > > (1) As part of that Charter, the OpenSolaris community possesses a > Governing Board, empowered to manage and represent the OpenSolaris > community as a whole. > > Reference: OGB/2006/001, "The OpenSolaris > Charter". > > ARTICLE III. Communities > > 1. In order to recognize the diversity of interests, the OpenSolaris > community is held to be composed of groups of members, called > Communities. > > 2. A Community must be approved by the OpenSolaris community, via > processes defined by its Governing Board. > > 3. Each Community has the right and responsibility to publish its > contributing members, core contributing members, and > alumni contributing members. From the publications of all > Communities, the OpenSolaris community can identify its total > contributing membership. > > (1) The period between such publications is set by the Governing > Board, or a committee acting on its behalf. > > 4. The Governing Board can suspend the right of a Community to > publish its contributing members, core contributing members, and > alumni contributing members. In the event that the Governing > Board permanently suspends this right, the Community is considered > Demoted. > Demoted? I'm unclear on this, demoted to what? Does this suggest a tiered community structure, similar to my previously suggested "Core" communities vs "Non-Core" communities? > ARTICLE IV. Membership > > The OpenSolaris community will attempt to > publish the OpenSolaris code and the discussions > concerning the development and adoption of that > code in a public and equal manner, without > requiring registration. However, for decision > making and community governance purposes, the > OpenSolaris community identifies four classes of > contributor. > > A. Classes of membership > > 1. Contributing member ("Contributor"). > > (1) Contributors are eligible to stand for and vote in elections. > Equivalently, a Contributor is a Voting Member. > > (2) Contributors are eligible for appointment to Board committees > and Community committees. > > (3) Contributors have voting capabilities in Community decision > making. > This needs to be clarified in terms of scope. As is written here it might be argued that community members with voting status could intervene in OGB votes. > 2. Core contributing member ("Core Contributor") > > (1) Core Contributors are eligible to stand for and vote in > elections. Equivalently, a Core Contributor is a Voting Member. > > (2) Core Contributors are eligible for appointment to Board > committees and Community committees. > > (3) Core Contributors are recognized with special voting > capabilities in Community decision making. > > As covered in OGB/2006/003, "Recommended > community decision making practices". > > (4) Core Contributors can represent their Community in meetings of > the Governing Board or of committees created by the Governing > Board. > Should there be an imposed limit, so that we don't have 5 core contributers in OGB matters? Restricted to 1 perhaps? > 3. Alumni contributing member ("Alumni Contributor"). > > (1) Alumni Contributors are not eligible to stand for elections. > > (2) Alumni Contributors are eligible to be appointed to Board > committees, but not eligible for Community Committees. > > 4. Honorary Member. > > (1) Honorary Members are not eligible to stand for elections. > > (2) Honorary Members are not eligible for appointment to Board > committees or Community committees. > I'd very much like to hear a rationale for allowing "honorary members". > B. Requirements > > 1. All participating members must be registered in the OpenSolaris > community database. > > 2. Contributors and Core Contributors must be named in at least one > of the Contributor lists published by recognized Communities. > > 3. Core Contributors must have previously been identified as > Contributors. > > 4. Alumni Contributors are Contributors who either no longer appear > in the contribution lists published by Communities or have > requested alumni status. > > 5. Honorary Members are named by the Governing Board. > See above. > C. Procedure for application > > 1. A prospective Contributing member should apply to his or her > Community. The Community can then approve or deny the > application. > Without an allocated singular "leader" per community this could become problematic. > 2. A prospective Core Contributor will be invited by the Core > Contributors of the relevant Community. There is no petitioning > process for a member to become a Core Contributor. > > 3. The Governing Board may grant Contributing Membership to an > individual. This grant of Contributing Membership expires after > a subsequent OpenSolaris election. The Contributor list from the > Governing Board must be created and treated as equivalent to the > Contributor lists of any other Community. > Expiration of such a member would require them to be earmarked, which would not allow them to be "treated as equiv". These members should, if allowed to remain in this constitution, be demoted to alumni based on the standard rules and durations applied to anyone else. If the OGB decides at some point (such as following election) choose to demote that member, thats a separate matter and better inline with the bylaws of this constitution. > ARTICLE V. Board of directors > > A. Membership > > 1. The OpenSolaris board of directors ("Governing Board") consists > of seven (7) members. > > 2. Each Board Member must be a Contributor or Core Contributor. > I think its more elegant to simply say "must be a voting member" or something. > B. Officers of board > > 1. At the beginning of its term, the Governing Board must select a > Chair, a Vice-Chair, and a Secretary. > I'm not so sure about the secretary. The way this works currently is pretty good, I think this needs to be discussed before enacted. > 2. The Chair directs the meetings of the Governing Board. In the > Chair's absence, the Vice-Chair conducts the meetings. > > 3. The Secretary is responsible for taking minutes, revising those > minutes, and publishing approved --- > C. Duties and responsibilities of board > > 1. Attendance of Board meetings will be noted in the minutes. > > 2. [Resignations] > > D. Executive committee of board > > [Does the Board need an executive committee?] > Please define "executive committee". > 1. Membership > 2. Duties > > E. Meetings of board > > 1. The Governing Board will meet no fewer than four (4) times per > year. > > 2. Open/Closed Sessions. > Please expand. > F. Reports of board and executive committee > > 1. Annual report? > On the surface I like the idea, however if the CAB is properly functioning (ie: open discussion and published meeting minutes) this shouldn't be needed and is simply redundant. > ARTICLE VI. Meetings > > A. Annual: notice, business to be conducted, order of business > > 1. The Governing Board may choose to conduct an Annual Meeting. > 180 days notice. > Please define the nature of this meeting as seperate from the "no fewer than 4" meetings. Will this Annual Meeting be irl? > B. Regular: notice, usual order of business > > C. Special: how called, notice > > ARTICLE VII. Committees > We need to discuss this in more depth. Preferably on todays call. > A. Standing committees: list, membership, selection, duties, powers, meetings, reports > > The Governing Board may create additional > standing committees, as outlined in > OGB/2006/004, "Recommended practices for > standing committees". Only the two required for > conducting elections and managing the membership > are defined here. > > 1. Elections and Membership Committee. > > (1) The Elections and Membership Committee ("Committee", for > VII.A.1) will be chaired by a Board Member, appointed by the > Governing Board. > > (2) The Committee Membership consists of the Chair, the remaining > Board Members (ex officio), and no fewer than four (4) eligible > Contributors appointed by the Governing Board. > > (3) The Committee may survey the Membership to determine the > efficacy of current election procedures. > > (4) The Committee will direct and report on the results of all > OpenSolaris community-wide elections. The Committee will issue > an Election Report within three (3) days of the conclusion of an > election. > > (5) The Committee will provide a printable ballot form and will > provide a process for printed ballots to be submitted legitimately > for all OpenSolaris community-wide elections. The primary method > for ballot submission is to be electronic. > > (6) Unless a specific exemption is given by the Governing Board, > thirty days (30) prior to any Governing Board election, the > Committee will issue a Voting Membership Report. > > For this first election, the Governing Board is > expected to compose a specific exemption that > gives the Elections and Membership Committee > a reduced publication lead time. > > (7) The Committee may request, no more than four (4) times per > year, a list of Contributors and Core Contributors for each > Community. > > (8) The Committee will archive and make available the requested > lists of Contributors and Core Contributors. > > (9) The Committee will maintain and make available the list of > Alumni Contributors. > > 2. Community evaluation committee. > I view this committee as redundant to the OGB. > (1) The Community Evaluation Committee ("Committee", for VII.A.2) > will be chaired by a Board Member, appointed by the Governing > Board. > > (2) The Committee Membership consists of the Chair, the remaining > Board Members (ex officio), and no fewer than four (4) eligible > Contributors appointed by the Governing Board. > > (3) The Committee is responsible for the assessment of Community > promotion and demotion, and the processes under which such > assessments are made. > > (4) The Committee can recommend, via a report to the Governing > Board, the promotion or demotion of a Community or the > modification of the current assessment processes. Action on such > recommendations is the responsibility of the Governing Board. > > (5) The Committee can promote or demote a Community, given a > Governing Board directive to do so. > > (6) Unless a specific exemption is given by the Governing Board, > Ninety (90) days The Committee > > For this first election, the Governing Board is > expected to compose a specific exemption that > gives the Elections and Membership Committee > a reduced publication lead time. > > B. Special committees: provisions for selection > > 1. The Governing Board can create Special Committees by a specific > motion. > > 2. Special Committees must have an identified purpose, powers, > responsibilities, and lifetime. > > ARTICLE VIII. Terms of office > > 1. The term of a Board Member lasts from the 1st day of the calendar > month following his or her election to the Governing Board until > the 1st day of the calendar month following the subsequent > Governing Board election. > > 2. A Board Member in his or her third (3) consecutive term of office > is not eligible for the Governing Board elections held during that > third consecutive term. > Good idea. > ARTICLE IX. Elections > > 1. Governing Board elections are to be held annually. > > 2. Governing Board members are selected based on the balloting method > known as "Single Transferable Vote". > > Reference: > http://en.wikipedia.org/wiki/Single_Transferable_Vote > http://accuratedemocracy.com/archive/stv/meekm.htm > http://www.dia.govt.nz/diawebsite.NSF/Files/meekm/$file/meekm.pdf > http://votesystem.sf.net/ > http://stv.sf.net/ > http://www.cix.co.uk/~rosenstiel/stvrules/ > http://www.electoral-reform.org.uk/votingsystems/stvi.htm > > 3. Each Contributor or Core Contributor has one ballot for a Governing > Board election. > > 4. Elections are to be held primarily using electronic means. > > ARTICLE XI. Quorum > Very good idea, I'd been thinking about this. We need a "if quorum doesn't exist" statute. > A. Meetings of organization > > [Do we need decision-making meetings for the membership as a whole? > Or should we have a referenda/proposition model?] > > B. Meetings of board > > 1. A meeting of the Governing Board requires the attendance of five > (5) Board Members. > > ARTICLE XII. Discipline and expulsion of members > > 1. The Governing Board may find that > > ARTICLE XIII. Parliamentary authority > > 1. The parliamentary authority for the operation of the OpenSolaris > Community is A. Sturgis, The Standard Code of Parliamentary > Procedure, 4th ed. > Gotta go to the library for this one. > ARTICLE XIV. Policies > > A. Provisions for adoption > > B. Vote required for adoption and amendment > > ARTICLE XV. Amendments to bylaws > > 1. > > ARTICLE XVI. Dissolution > I don't know about this. I'd leave it out, but need to do some research on it. > 1. The Governing Board may propose a referendum to dissolve with the > passing of a motion with a supermajority consisting of two-thirds > of the Board Members. > > 2. The OpenSolaris community, via referendum, may accept dissolution > based on a two-thirds majority vote of all Voting Contributors. > > The Governing Board (or at least the Board > Members proposing dissolution) should probably > resign if the referendum result is to decline to > dissolve. QQQ: Do we need a clause to this end? > > > benr. From sch at eng.sun.com Wed May 10 11:57:43 2006 From: sch at eng.sun.com (Stephen Hahn) Date: Wed, 10 May 2006 11:57:43 -0700 Subject: [cab-discuss] A partially filled-in draft constitution In-Reply-To: <44623431.4030803@cuddletech.com> References: <20060509230816.GA300304@eng.sun.com> <44623431.4030803@cuddletech.com> Message-ID: <20060510185743.GA302541@eng.sun.com> * Ben Rockwood [2006-05-10 11:43]: > Stephen Hahn wrote: > > 4. The Governing Board can suspend the right of a Community to > > publish its contributing members, core contributing members, and > > alumni contributing members. In the event that the Governing > > Board permanently suspends this right, the Community is considered > > Demoted. > > > Demoted? I'm unclear on this, demoted to what? Does this suggest a > tiered community structure, similar to my previously suggested "Core" > communities vs "Non-Core" communities? Demoted means "no longer a community". So it's more about knocking things off that aren't working, rather than promoting things that need to work. > > (3) Contributors have voting capabilities in Community decision > > making. > > > This needs to be clarified in terms of scope. As is written here it > might be argued that community members with voting status could > intervene in OGB votes. Agree. > > (4) Core Contributors can represent their Community in meetings of > > the Governing Board or of committees created by the Governing > > Board. > > > Should there be an imposed limit, so that we don't have 5 core > contributers in OGB matters? Restricted to 1 perhaps? Don't know. Overattendance is not usually a problem with the current batch, but it's a good question. > > 4. Honorary Member. > > > > (1) Honorary Members are not eligible to stand for elections. > > > > (2) Honorary Members are not eligible for appointment to Board > > committees or Community committees. > > > I'd very much like to hear a rationale for allowing "honorary members". It can be deleted. I was just working through various actions/awards an OGB might want to offer. Anything related to membership needs to be in the Constitution. > > C. Procedure for application > > > > 1. A prospective Contributing member should apply to his or her > > Community. The Community can then approve or deny the > > application. > > > Without an allocated singular "leader" per community this could become > problematic. A Community needs to have at least one Core Contributor at inception. > > 2. A prospective Core Contributor will be invited by the Core > > Contributors of the relevant Community. There is no petitioning > > process for a member to become a Core Contributor. > > > > 3. The Governing Board may grant Contributing Membership to an > > individual. This grant of Contributing Membership expires after > > a subsequent OpenSolaris election. The Contributor list from the > > Governing Board must be created and treated as equivalent to the > > Contributor lists of any other Community. > > > Expiration of such a member would require them to be earmarked, which > would not allow them to be "treated as equiv". These members should, if > allowed to remain in this constitution, be demoted to alumni based on > the standard rules and durations applied to anyone else. If the OGB > decides at some point (such as following election) choose to demote that > member, thats a separate matter and better inline with the bylaws of > this constitution. True, but the current draft doesn't talk about how a Community should maintain or expire the entries on its Contributors list (which it needs to), so I'd like to let this run a bit longer. > I think its more elegant to simply say "must be a voting member" or > something. Agree. > > B. Officers of board > > > > 1. At the beginning of its term, the Governing Board must select a > > Chair, a Vice-Chair, and a Secretary. > > > I'm not so sure about the secretary. The way this works currently is > pretty good, I think this needs to be discussed before enacted. Fine to discuss. If we want the OGB to be independent, it needs to take its own notes and proper minutes. Sun can assist, but it should be at the Secretary's request... > > D. Executive committee of board > > > > [Does the Board need an executive committee?] > > > Please define "executive committee". An executive committee is a subset of a board that generally meets more regularly to deal with operational issues. It's common when there is an executive director running day to day aspects of whatever the board governs. > > 2. Open/Closed Sessions. > > > Please expand. Will do--this portion wasn't fully drafted. > > F. Reports of board and executive committee > > > > 1. Annual report? > > > On the surface I like the idea, however if the CAB is properly > functioning (ie: open discussion and published meeting minutes) this > shouldn't be needed and is simply redundant. Perhaps. It's a chance to be very public about what's working, what's not, and what's coming--without feeling like an open letter, or getting lost in regular minutes. > >ARTICLE VI. Meetings > > > > A. Annual: notice, business to be conducted, order of business > > > > 1. The Governing Board may choose to conduct an Annual Meeting. > > 180 days notice. > > > Please define the nature of this meeting as seperate from the "no fewer > than 4" meetings. Will this Annual Meeting be irl? I'm not sure. Portion not fully drafted, but I was thinking about meetings in general. > > B. Regular: notice, usual order of business > > > > C. Special: how called, notice > > > >ARTICLE VII. Committees > > > We need to discuss this in more depth. Preferably on todays call. Cool. > > 2. Community evaluation committee. > > > I view this committee as redundant to the OGB. It's an opportunity to delegate a precise function. > > 2. A Board Member in his or her third (3) consecutive term of office > > is not eligible for the Governing Board elections held during that > > third consecutive term. > > > Good idea. Thanks. > >ARTICLE XI. Quorum > > > Very good idea, I'd been thinking about this. We need a "if quorum > doesn't exist" statute. Agree. > > 1. The parliamentary authority for the operation of the OpenSolaris > > Community is A. Sturgis, The Standard Code of Parliamentary > > Procedure, 4th ed. > > > Gotta go to the library for this one. I can buy a batch of copies and send, if people think that's helpful. > >ARTICLE XVI. Dissolution > > > I don't know about this. I'd leave it out, but need to do some research > on it. Dissolution means "return to Charter", and is likely needed for any independent foundation path. Great comments, thanks. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems stephen.hahn at sun.com http://blogs.sun.com/sch/ From fielding at gbiv.com Wed May 10 14:15:19 2006 From: fielding at gbiv.com (Roy T. Fielding) Date: Wed, 10 May 2006 14:15:19 -0700 Subject: [cab-discuss] A partially filled-in draft constitution In-Reply-To: <20060509230816.GA300304@eng.sun.com> References: <20060509230816.GA300304@eng.sun.com> Message-ID: I like the outline. I wish there was some way to avoid "the OpenSolaris community" being the name of the larger entity. I suggest that we just call it the OpenSolaris Organization. On May 9, 2006, at 4:08 PM, Stephen Hahn wrote: > ARTICLE III. Communities > > 1. In order to recognize the diversity of interests, the > OpenSolaris > community is held to be composed of groups of members, called > Communities. > > 2. A Community must be approved by the OpenSolaris community, via > processes defined by its Governing Board. > > 3. Each Community has the right and responsibility to publish its > contributing members, core contributing members, and > alumni contributing members. From the publications of all > Communities, the OpenSolaris community can identify its total > contributing membership. > > (1) The period between such publications is set by the Governing > Board, or a committee acting on its behalf. > > 4. The Governing Board can suspend the right of a Community to > publish its contributing members, core contributing members, and > alumni contributing members. In the event that the Governing > Board permanently suspends this right, the Community is > considered > Demoted. The terminology here is dancing around the issues. A community needs to be created (proposed + approved), governed, and terminated (the three states of governance that apply to all of these categories). Thus, I would have each section contain 1. Purpose of X 2. Creation of X a. nomination b. approval c. effective date 3. Governance within X a. participants b. decision mechanism c. reporting 4. Termination of X a. trigger for review b. decision c. reallocation of assets > ARTICLE IV. Membership > > The OpenSolaris community will attempt to > publish the OpenSolaris code and the > discussions > concerning the development and adoption of > that > code in a public and equal manner, without > requiring registration. However, for decision > making and community governance purposes, the > OpenSolaris community identifies four > classes of > contributor. > > A. Classes of membership As mentioned on the call, I don't like how these classes are described. I would have Community participation 1. Observers (base class = people registered on org) 2. Contributors (made contributions, but do not yet have vote) 3. Core (major contributors given community governance) 4. Emeritus (former core on vacation) Organization-wide participation 1. Observers (base class) 2. Contributors (made contributions, but do not yet have vote) 3. Citizens (major contributors given community governance) 4. Emeritus (former citizens on vacation) Note that there is one class with the vote for community decisions (core) and one class with the vote for organization decisions (citizens), and an individual may belong to zero or more core groups and yet be counted as one citizen. I would also go further and add project governance to the constitution since they will need to make decisions. I do not believe that having a "community leader" make decisions is a viable model for non-employees. I suggest that projects be placed in a federated structure so that they can overlap multiple communities and draw their decision-making authority from each community core. That is, a project consists of a list of participants drawn from participants within the sponsoring communities; the subset of whom that are core to those communities are given the vote for project decisions. In order for a project to promote one of their contributors to decision-making status, they have to promote them to core status within the sponsors. If there are less than three core participating in a given project, they must convince other core members to review and vote on decisions requiring minimal quorum. > B. Requirements > > 1. All participating members must be registered in the OpenSolaris > community database. okay. > 2. Contributors and Core Contributors must be named in at least > one > of the Contributor lists published by recognized Communities. that is a requirement on communities. > 3. Core Contributors must have previously been identified as > Contributors. not necessary. > 4. Alumni Contributors are Contributors who either no longer > appear > in the contribution lists published by Communities or have > requested alumni status. that should be Emeritus (graduation is not our goal). > 5. Honorary Members are named by the Governing Board. so can "official soft drinks". I would not include this category. > C. Procedure for application > > 1. A prospective Contributing member should apply to his or her > Community. The Community can then approve or deny the > application. > > 2. A prospective Core Contributor will be invited by the Core > Contributors of the relevant Community. There is no > petitioning > process for a member to become a Core Contributor. > > 3. The Governing Board may grant Contributing Membership to an > individual. This grant of Contributing Membership expires > after > a subsequent OpenSolaris election. The Contributor list > from the > Governing Board must be created and treated as equivalent to > the > Contributor lists of any other Community. Sounds like a great way to grow the polls just prior to a vote, and then not have to be responsible to those added. ;-) The rest is pretty good. It needs to state what roles are available for people who are not elected (e.g., there is no need for the Secretary to be a member of the OGB). Likewise, what is your (Stephen's) official role in regards to this organization? Where does it fit within the constitution, what are your powers, etc. Leaving it out is not an option. ....Roy From benr at cuddletech.com Wed May 10 17:51:55 2006 From: benr at cuddletech.com (Ben Rockwood) Date: Wed, 10 May 2006 17:51:55 -0700 Subject: [cab-discuss] Wiki Discussions Message-ID: <44628AAB.2030904@cuddletech.com> I've added a discussion to the "Roles and Responsibilities Discussion" entry as well as created a placeholder for Stephen Hahn's Draft 01 when the changes Roy proposed are integrated and Stephen is ready to post it. I've also added all governance related issues to a single category, which should make navigating between all these things more simplistic. benr. From webmink at sun.com Wed May 10 20:00:19 2006 From: webmink at sun.com (Simon Phipps) Date: Thu, 11 May 2006 04:00:19 +0100 Subject: [cab-discuss] Wiki Discussions In-Reply-To: <44628AAB.2030904@cuddletech.com> References: <44628AAB.2030904@cuddletech.com> Message-ID: <65C5944F-E5AB-4672-920D-7E02D96C998C@sun.com> Thanks, Ben, I have added a comment in the discussion! For those of you who have not used MediaWiki before: * When adding to a discussion, indent your replies by adding one or more colons at the start of the first line, one colon for each level of indent * Sign your discussion comment by adding ~~~~ to the end of it; MediaWiki will replace that with your user ID and a timestamp S. On May 11, 2006, at 01:51, Ben Rockwood wrote: > I've added a discussion to the "Roles and Responsibilities > Discussion" entry as well as created a placeholder for Stephen > Hahn's Draft 01 when the changes Roy proposed are integrated and > Stephen is ready to post it. > > I've also added all governance related issues to a single category, > which should make navigating between all these things more simplistic. > > > > benr. > _______________________________________________ > cab-discuss mailing list > cab-discuss at opensolaris.org