Replies are in line (posted to bug as well): (In reply to comment #0) > Community Groups > ---------------- > * The term "community group" in the Constitution shall be interpreted as a > descriptive phrase for a class of groupings in the OpenSolaris community. It > will no longer be used on its own to describe a group. > * All existing activities in the OpenSolaris community shall be classified as > one of the following four kinds of community group: > - Project, a group of Members and others creating and/or maintaining an > identifiable unit of code > - Consolidation, a group of Members and others aggregating Projects under a > particular theme or objective [SP: Should Distributions be considered > Consolidations?] > - Special Interest Group, a group of Members and others involved in > Projects and Consolidations and sharing a common interest > - User Group, a regionally-based group having a shared interest in > OpenSolaris
I don't think this section redefine anything - they're simply setting a precedent. As-is, your proposal in this section is already in-place, it's just that it's being done via the prefix of the community group or project name :) (although some aren't marked as consolidation) > > Transitional Strategy > --------------------- > * All Community Groups formed in the restructuring shall be devised as per the > constitution but without the naming of any new Core Contributors. Instead, > existing Core Contributors will be recognised as engaged in the new community > groups. All Core Contributors who do not gain such recognition shall be > recognised as At Large members. > * Community Groups which do not secure the required 3 core contributors will > be merged with others or dissolved, at the discretion of their participants. This seems to present some logistical issues I would like to see clarified. What is the time frame for core contributors to gain recognition in new projects (looks like 2 yrs is the CC expiration)? What is the likelihood of a CC not becoming recognized into a CG? (...ie, this seems like a mute requirement) +1 on dissolving or merging communities which don't meet requirements > > Membership Committee > -------------------- > * A new OGB Committee will be formed to manage membership applications (the > "Membership Committee"). The OGB delegates its Constitutional discretion over > the confirmation of Core Contributor grants to the Membership Committee. > * Community Groups wishing to request Core Contributor grants for their > Contributors will need to ensure their own process demonstrably meets the > quality control requirements of the Membership Committee, which will defer or > decline grants in cases where substantial historic contribution is not > demonstrated. Specifically, no further grants will be made on the basis of > reputation, expected future contribution or job role. Is this something that could be done further down the road. Do you foresee the availability of bodies and their commitment create and operate this new committee? We should also be aware this will affect the people and time of existing CG-CCs, require them to create and utilize a QC process to ensure they maintain >= 3 CCs. This also doesn't consider that there will be many groups, such as those in advocacy, SIGs, and UGs, where a CC contribution will pale in comparison to the contribution of someone on say, the IPS project. So now you're stuck with JUDGING contributions. In arena "A" you have a CC who makes blog posts and attends events, and arena "B" you have a guy who's building a new filesystem but even if he got through the contributor process he doesn't get a CC grant because his CG is large and already overwhelmed by the QC process for maintaining the existing CCs. The minutia would be overwhelming and people will not walk, but RUN away! -1, -1 Although, I could be misinterpreting or taking this out of context. Can you elaborate on this Membership Committee and QC process? > > Future Strategy > --------------- > * When future community groups are formed, core contributor grants will only > be given under exceptional circumstances and ?7.4.3 will be considered to mean > that the initial core contributors of any new community group must be existing > core contributors from elsewhere in the community. This resolution will need > ?8.3 to be modified at a future date so in the interim the OGB elects to set > it aside per OGB-2008/00x. > * Per ?7.12, any new group will need to ensure it has "grown" at least three > core contributors by the time the grants of its founders expire. What does exceptional circumstances mean (+1 if it's specifically defined)? I think it would be wise to define exceptional circumstances. The definition can be amended if it doesn't work, right? If everyone can agree on the initial definition, then everyone can agree to not give CC grants upon a CG formation. > > Housekeeping > ------------ > * Where necessary, the OGB will make further resolutions to enact the > decisions made in this resolution. In the event that the necessary resolutions > interpret the Constitution in a contested way, the OGB will still enact those > resolutions but will prepare Constitutional Amendments for consideration at a > future membership meeting. > * Per ?7.8, all of the initial members of a new community group will be > granted Contributor status by the OGB. The group will then be expected over > time to "grow its own" core contributors. How much time is given to grow? -- Alex Leverington On May 14, 2008, at 8:02 PM, Simon Phipps wrote: > I just posted very rough notes providing an overview of my thinking on > restructuring how we form community groups and grant membership. > You'll find it at http://defect.opensolaris.org/bz/show_bug.cgi? > id=1937 where it's possible to comment and make counter-proposals. > After a discussion period we'll promote the resulting resolution to an > OGB agenda. > > S. > > > > _______________________________________________ > ogb-discuss mailing list > ogb-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/ogb-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/ogb-discuss/attachments/20080516/41bb9db6/attachment.html>
