Process for accepting a library?

From: Beman Dawes (beman_at_[hidden])
Date: 2000-05-05 10:24:42

What process should we use for accepting a new boost library?

Currently the author posts an preliminary submission in the boost
egroups files section (formerly "vault"), posts a mailing list
message, gets feedback, makes changes, and then...

The problem is the "and then...".  There isn't any process in place
to handle "and then..."

We need a process which:

*  Is clear; who does what and when must be clearly spelled out. Has
defined start and end points.

*  Ensures that libraries get more than a cursory glance; we need to
know that a library both meets boost guidelines and does something
useful.  Users also want to know what compilers it does or doesn't
work with.

*  Results in a clear accept/reject decision in a reasonable amount
of time.  If the decision is "reject", the author deserves the
courtesy of a rationale for rejection.

*  Spreads the workload so no one becomes overloaded with review
responsibilities.

*  Adapts to both large and small libraries.

*  Is trusted.  On one hand we want open-to-all participation, but on
the other hand we want to trust from past experience whoever makes
the final accept/reject decision.

Perhaps something like this:

*  Once a library author feels an initial submission (which
presumably has been in the files/vault for a while, and has received
initial feedback) has matured enough for formal submission, the
author posts a request for formal review.

*  Someone unconnected with the submission then volunteers to be the
"Review Manager" for that library. (see below)  The review manager
posts a notice of when the review period is start, how long it lasts,
and how boost members can contribute their comments. The review
manager collects comments, chairs any discussions, and then when the
review period is over, decides if there is enough consensus to accept
the library.

There are a lot of open questions about the position of Review
Manager, but there isn't a lot of point in discussing them unless the
overall approach is accepted.

Comments?  Suggestions?  Reports of how other projects are dealing
with the problem?

--Beman