On Thu, May 03, 2007 at 09:00:07AM -0400, James Carlson wrote:
> 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.)
It actually seems narrower in terms of what qualifies; the requirement
that the project change the contents of a product rules out an
activity such as putting on a conference that does not result in a
change to the software we offer to consumers. It's definitely broader
in that it incorporates bug fixes and RFEs with architectural impact,
and I'm not sure we want to represent small, short-lived projects in
the same way. In effect, a Project is a project that's worth creating
a Project for.
> 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.
Agreed.
> - 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.
That's not really the intent - Projects for which it makes sense to
integrate into a consolidation should be expected to be done when they
achieve that goal (or when it becomes clear that they will not).
Other Projects should still have some kind of finite objective -
especially given the likely conclusion that post-completion activity
around a Project, if sufficient, will result in the creation of a
Community Group.
The problem I'm struggling with here is that we only have three ways
to represent an orgnaisation:
- A Community Group
- An OGB committee
- A Project, sponsored by one or more Community Groups
and an implicit fourth, the consumer (which may be outside the
OpenSolaris Community and thus the OGB's scope).
Which of these do we believe is suitable for representing an
individual local User Group? That's not a finite activity, but it's
far too small to be a Community Group as we're currently thinking of
them. It could be chartered as a standing OGB committee, but it's
unclear why such an activity should be run at so high a level.
So I'm going to propose a bit of bureaucratic improvisation here.
Projects have a finite life span. As part of their inception process,
the Project Team defines the problem(s) they intend to solve, which
necessarily entails completion criteria. However, Community Groups
may, as part of their right of self-government, form committees
(standing and select) to mange ongoing activities. These are not
Projects, though Community Group committees may be chartered to
sponsor one or more Projects if appropriate.
> - 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?
If there's a better way to express the idea that a Project is any
finite activity that's worth the process it takes to create, I'd be
grateful for it. I suppose this means I'm in favour of allowing it to
resolve 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.
Sold.
> What's the sound of one person collaborating? ;-}
It's the same sound a bug makes, whatever that is.
> > - 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.
I would agree that the Project Team is obligated to provide all
relevant high-level information about their plan to solve the problem.
That would include the license terms under which they intend making
their work available, especially if those terms are unusual for the
targetted consolidation (if any) or if they present any special
architectural issues. However...
> 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.
Agreed. But I do feel that these are issues which sponsoring
Community Groups should govern. That is, it's up to the sponsoring
organisation to determine what type of information is appropriate to a
particular problem (again, think not just "adding support for a new
routing protocol" but also "hosting the 4th Annual OpenSolaris
Developer Conference") and what level of detail it needs to see in the
proposal before it will agree to sponsor the work. For the software
work we know and love, it's reasonable to expect Project Teams to
commit to, or at least express a plan for, using certain languages,
licenses, and perhaps even basic architectural details. This is not
an architectural inception review; an interesting question might be
whether that initial ARC review is a condition for approval imposed by
a sponsoring Group or a subsequent activity the Team is expected to
perform.
Our guidance to Groups should probably incorporate language to this
effect.
> > - 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 ...
The objective is more to avoid duplication of effort and ensure that
the Team is aware of related or conflicting work, not to address the
architectural details of those dependencies.
> > 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.
I was attempting to offer advice to Groups uncertain about the purpose
of the process, concerned that some would treat it as an architectural
or design review when the real purposes are to get Project Teams
connected to the knowledge repositories in the Groups and to force the
Groups to be more aware of the work they're endorsing. The intent is
not to weaken integration requirements or force a Group to sponsor a
Project it feels is ill-conceived, redundant, or staffed for failure.
> 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.
Right. I'll modify this language.
> (also: s/submittor/submitter/g)
Done.
--
Keith M Wesolowski "Sir, we're surrounded!"
FishWorks "Excellent; we can attack in any direction!"
