Re: [boost] Submission policy

From: Beman Dawes (beman_at_[hidden])
Date: 2000-05-07 12:19:32

At 10:07 AM 5/7/00 +0100, Paul Baxter wrote:

>1) Since we are discussing submissions, I was wondering whether
there are
>any criteria regarding the content or style of a submission that are
likely
>to affect its submission.
>
>For instance, a specialist library with excellent coding style and
content
>but with a limited audience. Does this get rejected (or not
considered)
>because it is not generally relevant?
>
>Perhaps this would work itself out if few people come forward to
review it;
>I just think it may save potential applications some time if they
knew up
>front whether acceptance were likely (it takes a while to 'Boostify'
code).

Let's assume by "specialist library" you mean a library useful only
within a fairly narrow problem domain, rather than useful across
multiple problem domains.  (Although it could be clearer in the
library guidelines, boost has always discouraged libraries that are
"specialist" in the sense of operating system specific.)

One trouble with libraries which apply only to a narrow problem
domain is what I call the valarray effect.  If there are only one or
two experts in the problem domain participating in boost, and those
experts wander off, then we are left maintaining a library most of us
neither understand nor care about.

>Perhaps a line or two in the library submission guidelines that
libraries
>should be generally applicable and this would be judged by brief
discussions
>on the mailing list before submission. (or alternatively a line
suggesting
>everything is welcome given licensing and coding style constraints.)

Agreed.  As we refine the procedures, I will update the boost library
guidelines page.  (see below)

>2) Are libraries that ONLY propose an interface (and perhaps partial
>implementation) acceptable.

Yes, IMO, but there can't be any restriction on writing
implementations based on that proposed interface.   Also I wouldn't
want any restrictions on the proposal text itself that prevented it
from being copied such as when the boost site is mirrored.

> I'm thinking here of say the graph work where
>the license in the vault is for non-commercial use only, a
restriction
>preventing the code from being submitted formally. (at present, at
least.)
>
>Something like the graph discussions were extremely valuable and
Jeremy et
>al. are to be congratulated, but what now becomes of this work?
>
>We could (I assume?) place the documentation with Boost and provide
links to
>the Notre Dame content, or we could just leave it out of Boost all
together
>and place a link to the ggcl project.
>
>Perhaps it would be better to clarify up front what the license
conditions
>for a proposal would be to avoid taking up a lot of bandwidth on
something
>that ultimately couldn't be part of Boost.

Agreed.

>Personally I gained a tremendous amount from the discussions but can
see a
>danger in future if we discuss/debug libraries that are never likely
to be
>part of Boost. Intellectually of course I want to judge on a case by
case
>basis, but my judgement and those of others on this list may not
coincide on
>the matter, what then?
>
>Note I'm happy to accept say, Beman as the 'arbiter of good sense'!

Thanks for the vote of confidence!

Let me try a quick first cut at added wording for the Boost Library
Guidelines page at http://www.boost.org/more/lib_guide.htm:

--- start wording ---

(Change page title to "Boost Library Requirements and Guidelines"

<h2>Requirements</h2>

To avoid the frustration and wasted time of having your proposed
library rejected, make sure it meets these requirements:

* Has a license that allows unrestricted use, including commercial
use.  Restricted licenses like the GPL and LGPL are not acceptable.

* Is generally useful and not restricted to a narrow problem domain.

* Is portable and not restricted to a particular compiler or
operating system.

* Comes reasonably close to meeting the Guidelines below.

* You are willing to participate in discussion on the mailing list,
and make changes in your library accordingly.

There isn't any absolute requirement that you read the mailing list
long enough before a submission to get a sense of what boost is all
about.  It has been noted, however, that submissions which being "I
just started to read this mailing list, but ..." seem to fail, often
embarrassingly.

<h2>Guidelines</h2>

(Guidelines unchanged from current text.)

--- end wording ---

Comments?

--Beman