Comments on Proposed Procedure for Maintenance of Umbrella Projects

RLH, 8/30/06:

This is a good start; the policy works for me. There are two fuzzy bits that need crisping up when/where the procedure is documented. (There are 2 CGL contributions in the queue, so your direction on the procedure is needed.)

• (1.) "..process for subprojects will be similar to those for projects except.." The fuzzy bit here is the word "similar." Do you mean the following? "The acceptance procedure for subprojects consists of the acceptance procedure for new projects with the following alterations:
  • (i) Sub-project contributions must conform to the documented specifications/standard of the umbrella project.
  • (ii) Sub-projects should have the same license as the umbrella project. Exceptions will be considered on a case-by-case basis.

FM: 9/3/06: I think that no exception can be considered since only one library is created for the umbrella-project. Accepting different licenses amounts to changing the license for the whole umbrella-project. If an author insists on a different license, he can submit his code as a new project, not to be included in the umbrella-project.

• (iii) Sub-project contributions are sent to Submissions Manager for tracking/documenting as with all projects. The Submissions Manager will send the contribution to the umbrella PM for handling.

FM: 9/3/06: It seems simpler that submission of a subproject be directed to the PM of the umbrella project: The PM decides if a subproject is accepted or not. Once a subproject has the PM approval, then paperwork to meet legal requirements for a new project should be handled by the submission manager. When the submission manager has all papers in hand, he informs the PM who takes care of updating AUTHORS, README (INSTALL if any) files, create the wiki page and include the code in the repository.

• (iii) In handling a new sub-project contributions, the umbrella PM follows the steps in the new project contribution process with one exception: sub-projects are not given stand-alone trak/wiki. Subprojects use the trak and wiki pages of the umbrella project.

FM: 9/3/06: There are other differences: mailing list is the mailing list of the umbrella-project, no INSTALL, AUTHORS, LICENSE files (these are at the level of the umbrella-project)

• (2.) "For most other purposes, the Subproject Managers will have all the rights and responsibilities of a Project Manager..." The fuzzy bit here is "for most other purposes." What rights/responsibilities are given to a PM but not given to an SM? Do you mean the following?
  • Conceptually, the SM is the PM for the subproject. As such, the SM has all the same rights and responsibilities of a PM relative to the subproject. The only distinctions are (i) the SM has the added responsibilitiy of conforming to the standard for the umbrella project set by the PM, and (ii) the SM uses the resources (e.g., wiki/trac) of the umbrella project.

Minor comments on the policy:

• The definition of "umbrella project" is C++ centric ("base class or classes"). It doesn't need to be. More general language would better serve the non-C++ audience and future instances.
• Here, a key element of an "umbrella project" is the strong relationship between the "umbrella" and the sub-projects going under it. The word "umbrella" doesn't connote the strong relation required here (e.g., we describe COIN-OR as an umbrella project). Consider a more descriptive name (e.g., "meta-project", ?)
• I appreciate concrete examples and not just fuzzy "consider" suggetions, so here's a concrete suggestion for you something like...
  • A "Meta-Project" is a project that consists of (i) a standard and (ii) a number of "Sub-Projects" that conform to the standard. Examples of meta-projects are the CGL and OSI. Meta-projects require special maintenance procedures because each sub-project may have its own manager, referred to as the "Sub-project Manager" (SM).

FM: 9/6/03: Very good definition.