Hi, Sorry for being so late in responding, but I have some questions below.
> Subject: [ogb-discuss] OGB/2007/001 Project Instantiation Policy > Date: Fri, 27 Apr 2007 09:28:50 -0700 > From: Keith M Wesolowski <keith.wesolowski at sun.com> > To: ogb-discuss at opensolaris.org > > Here's the final text of the policy. It includes the following minor > changes: > > - Clarify the creation of roles to perform instantiation-related > tasks and the temporary (and open) nature of assignments. > > - Clarify that all roles may be delegated. > > - Note dependency on future policies for naming (see 2007/002 > thread) and project team responsibilities (Bonnie's note on SCAs). > > - Fix section numbering. > > ---8<--- > > This policy documents the process of OpenSolaris project creation. > The process described here applies only to those projects seeking > recognition as OpenSolaris Community-sponsored work; any work which > takes place outside the Community is not considered. > > This policy may be adopted, amended, or discontinued by the > affirmative vote of the OpenSolaris Governing Board (OGB). > > 1 Definitions > > Community Groups > > This term has the definition provided in the Constitution[0]. The > short form 'Groups' is used interchangeably in this document. > > Participants > > This term has the definition provided in the Constitution[1]. > > Project > > A collection of artifacts with a unifying purpose and > coherent structure, sufficiently large or complex as to require at > least informal organisation and collaboration. > > Project Herald > > An entity responsible for notifying interested participants of a > Project's instantiation (see 2.3). > > Project Team > > One or more Participants collaborating to achieve a common goal, > specifically the completion of a particular Project. > > Resource Administrator > > An entity responsible for managing allocation of Community-managed > resources to Project Teams (see 2.4 and 2.6). > > 2 Policy > > 2.1 Projects sponsored by one or more Community Groups, as described in > the OpenSolaris Constitution[2], are permitted to use Community-governed > resources. Examples of resources which may be provided may include > space for storing working or reference copies of Project artifacts, > access to public and/or private communication channels such as mailing > lists, and collaboration tools. Neither the OGB nor any other entity is > obligated to provide any of these resources, but the same resources must > be made available to all Project Teams as defined by this policy. > > 2.2 A Project is instantiated at the request of one or more sponsoring > Community Groups[3]. The set of Community Groups wishing to initiate > the Project shall, as a joint action, provide to the OGB all of the > following information: Who specifically sends the information to the OGB? The person who proposed the project in the first place or the community/communities that are sponsoring the project? It seems like it would make sense for the person proposing the project to do this step, but the section reads like one or more Community Groups has to send information to the OGB. If so, that implies the person proposing the project has to coordinate that effort which seems burdensome. > > - A short (one or a few words) synopsis of the Project's purpose, > and an optional shortened or decorative name (see 4.1). > > - A list of Community Groups sponsoring the Project. > > - A list of Members constituting the initial Project Team. > > - A one-paragraph description of the Project, for an audience of > Participants who may not be familiar with the area in which work > is proposed. This should contain a brief description of the > problem(s) the Project is expected to solve, and of the manner in > which it will do so. > > - A listing of related ongoing or proposed Projects, including > information about any dependencies on or by this Project and any > duplication of purpose or overlap with other ongoing work. This > listing should also include the name of the consolidation the > Project Team is targeting, if applicable. > > - Optionally, additional information which may be of interest to > prospective Project Team members and/or consumers of the Project's > output. > > 2.3 The OGB, acting as Project Herald, upon receipt of the information > described in 2.2 in acceptable form shall cause to be announced > publicly, via a channel dedicated to the purpose, the instantiation of > the Project. The announcement must include substantially all of the > information described in 2.2. This sounds like the OGB does not approve the project but simply announces its creation. Is that correct? If so, why have the OGB in the loop - couldn't the project send the information cited above to the project announce alias? What are we trying to gain by having the OGB be a gatekeeper? I wonder about overhead and turnaround time if the OGB is involved with starting every project. Can anyone on the OGB send the information on to the announce alias upon receipt? Or does the OGB first have to discuss/agree/approve something? If the former, same questions as above about having the OGB in the loop. If the latter, that implies the OGB does approve each project. If so, how does that happen - email or in the next meeting? And what happens if there isn't a meeting for a couple of weeks for whatever reason? And does it make sense for the OGB to disallow a project that one or more communities are sponsoring? I figure I must be missing something so apologies if these questions don't make sense. > > 2.4 At the same time (or as close to it as practicable) as the > instantiation announcement is made as described in 2.3, the OGB, acting > as Resource Administrator, shall provide to the Project Team members > such privileges, tokens, and other necessary and appropriate information > to allow their use of any Community-managed resources allocated to the > new Project. > > 2.5 Community Groups may choose to begin sponsoring, or cease > sponsoring, any Project at any time before or after its instantiation. > A Group shall indicate this choice to the OGB. What does it mean to begin sponsoring a project before it's created? This reads like a Community would notify the OGB that it is sponsoring a project but the section above says information is sent to the OGB that includes which Communities are sponsoring the project. Isn't that overlap? Is this section just trying to note that a Community can cease sponsoring a project? If so, perhaps just say that. Bonnie > > 2.6 Should all sponsoring Community Groups notify the OGB that they have > revoked their sponsorship of a Project, the OGB, acting as Resource > Administrator, shall revoke such privileges as may have been granted to > the Project Team's members as described in 2.4. Before doing so, the > OGB may, at its discretion, provide the Project Team a grace period > during which other Community Groups will have the opportunity to sponsor > the Project, and the Project Team be permitted to retrieve any Project > materials stored within Community-managed resources. > > 2.7 Because only Community Groups can instantiate Projects, prospective > Project Teams are required to engage with one or more appropriate > Community Groups to determine whether their proposed work is > appropriate. This is an opportunity for the team to learn about other > relevant work, solicit assistance and additional members, and better > understand the path to success. A prospective Project Team may request > the sponsorship of any Group or Groups, but is expected to seek the > sponsorship of those Groups most relevant to its proposal. Conversely, > a Group is expected to decline proposals substantially outside its area > of expertise, and to direct prospective teams to more appropriate > sponsors. Requests for sponsorship are opportunities for constructive > engagement; they are not adversarial proceedings or formal reviews. The > objective of discussion of a proposal is to achieve consensus, not to > test or try the submittor(s). > > 3 Implementation Notes (Informative) > > The contents of this section are not a part of the project instantiation > policy. They are separate actions of the OGB intended to implement the > policy described above. > > The initial implementation of this process will utilise a mailing list, > designated project-announce at opensolaris.org, to receive announcements of > new Projects. Subscription to this list shall be open to all > Participants, but posting shall be prohibited except for the > announcements described in 2.3. Discussion of the announcement should > be directed to an appropriate mailing list created for the Project's > use, if one exists. > > The OGB temporarily designates Eric Boutilier to fill the roles of > Project Herald and Resource Administrator as described in 2.3, 2.4, and > 2.6, but notes that substantial advantage would be obtained by > automating this process. The OGB invites other Participants interested > in filling one or both of these roles to offer their services. > > The OGB designates the opensolaris.org web application to track each > Community Group's sponsorship or non-sponsorship of each Project as > described in 2.5, and consents to accept notices of same from said > application. > > Community Groups are encouraged to adopt their own policies for > discussing and approving Project proposals, including timeout periods. > Groups are advised that Article VIII of the OpenSolaris Constitution > provides substantial guidance in this area. > > 4 Dependencies (Informative) > > 4.1 A Project Team may wish to use a decorative name to refer to its > work. A separate naming policy will define the circumstances in which > such names are permitted and rules governing their selection. > > 4.2 Project Team responsibilities subsequent to instantiation, including > self-government and management of artifacts, will be defined in a > separate policy. > > 5 References > > [0] http://www.opensolaris.org/os/community/ogb/governance/, Article VII. > [1] Ibid., Sec. 3.3. > [2] Ibid., Sec. 7.1. > [3] Ibid., Sec. 8.4. > >
