Keith M Wesolowski writes: > 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.
I suspect that what you're trying to say here is that RFEs and bug fixes done by one person aren't projects. But what about RFEs and bug fixes that require collaboration with test developers or other projects? These things aren't uncommon, and do require organization, but they might not quite rate as "projects" in OpenSolaris. I think we should at least consider making that definition closer to the one traditionally used by the ARC. See, for example: http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ That definition is a bit broader in one dimension (what qualifies) but narrower in another (when it's complete). It simply defines a project to be a set of changes applied to the rest of the system. (It says "atomic," but we can and do bend that part frequently.) I suspect that there are several underlying issues that need to be discussed: - Most projects deliver into consolidations, and at the point that they do, I think that the project is just "done." Anything more to be done on it (the oft-neglected "phase 2") ought to be considered a new project -- something that requires a new proposal, or at _least_ a formal rechartering of the existing project. - Are there different flavors of projects? I believe that there could be. The model you're proposing here seems to be the island fiefdom, where projects live on "forever," each with its own source repository, and distributors who want that feature can just take the results when desired. This likely works for some kinds of projects (including the consolidations themselves, if they're considered to be island projects), but not for others. - How does "shrink to fit" apply? Do we need to state explicitly here that smallish RFEs don't need the overhead of this process, or should we just allow the process to take care of itself? For another model to look at, I'd recommend the IETF's working groups. The idea of a working group (except in some degenerate cases) is that it's chartered to do some specific work by some set time. It either does that work (and is then terminated), it recharters to expand or contract its goals, or it is abandoned. Working groups by design are not supposed to linger around like a bad hangover. [Yes, I'm well aware that I chair one of the degenerates.] Or: all's well that ends. > Project Team > > One or more Participants collaborating to achieve a common goal, > specifically the completion of a particular Project. What's the sound of one person collaborating? ;-} > - 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. What detail is required for "manner?" In particular, should it be necessary to note what kind of license will be used for any code or documentation produced? I think the answer is "yes," as this is the sort of choice that has a profound effect on how (and if!) project teams can collaborate and thus whether communities will be successful. For a more concrete example, if my community were to need a "libfoo," and a project to introduce that library was intending to produce one under GPLv2, then I might well have a problem if the rest of my source wasn't so licensed. Similarly, if my community consisted of a bunch of GPLv2 projects and a non-GPL one came along, I might have trouble endorsing that. GPL is a famous one, but there are certainly other instances of immiscible licenses. Similar things apply to ABI issues, such as the use of C++ or Java, or design philosophies, such as O-O. I realize that these may seem like "mere implementation issues" to some, but I think they fundamentally affect what communities can and cannot endorse if those communities are to be successful. I see no reason to leave such matters up until later, when they cannot be fixed. > - 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. The related projects information almost sounds like part of an ARC review ... > 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). It seems quite strange to have to state something like this. I'm not sure why these two sentences are present. Perhaps what's really needed here is a statement about the intended depth of the review -- it's not a design or code review, but rather a high-level examination of goals and methods in order to check for compatibility. Saying that we're necessarily achieving consensus seems a bit of a stretch; we may not. We just don't want to waste our time (in this area at least) discussing the names of object files or command line options. (also: s/submittor/submitter/g) -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
