Re: [boost] [logo] Boost logo variants for use in unofficial or unreleased boost documentation - was C++ Networking Library Release 0.5

Subject: Re: [boost] [logo] Boost logo variants for use in unofficial or unreleased boost documentation - was C++ Networking Library Release 0.5
From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2010-02-01 15:42:46

I appreciate the contribution by Bjoern Roald and Patrick Horgan
and I am going to use Bjoern's variant of the "proposed by" logo
for the next updates of my own library docs.

As with boost libraries as a whole, I think we should strive to
foster a consistent style, simplicity and elegance. This implies
to have
(1) as few additional logos as possible and
(2) logos that try to seamlessly and artistically integrate into
  the typographical style that is currently used in boost and
  boost quickbook.

Because of (2) I think that the red colored additions of
Patrick's logo are less suitable because they add a new
(and a very strong) color to the logo and to the color family
of the whole quickbook style.

2010/2/1 Thomas Klimpel <Thomas.Klimpel_at_[hidden]>:
> Patrick Horgan wrote:
>> LOL!  I can't imagine anyone would proudly proclaim "my software was
>> rejected by boost!"
>
> Well, not exactly "proudly proclaim". But the library author might take a "time off"
[...]
> it would be used rarely anyway.
>
>> If they are rejected by boost though, they have no
>> business showing a boost logo associated with their software
>
> It's not so easy. That they were rejected during a formal
> boost review doesn't necessarily mean that they are no
> longer associated with boost. The current agreement is
> to limit the number of different logos, especially no special
> logo for rejected libraries.

I agree with both points. My suggestion is this:

* Only two additional logos
  (1) proposed for boost
  (2) compliant to boost

Libraries that have been proposed on the list and generated
interest can use logo (1). In order to be acceptable for a formal
review, the library has to become boost compliant.
* Boost centric directory structure
* Implementation of various boost conventions
* Portability
* Dependent on std and boost libs only
* Sufficient documentation.
* Sufficient tests ...
to mention only the most important ones.

A library that is not boost compliant will not reach a formal
review because the review manager should check and reject
any non boost compliant submission.

The process from the first RFC to the formal review
implies already a great amount of work and an evolutionary
process that greatly improves the libraries quality. This is
(1) first of all an achievement of the library author,
(2) an achievement of other developers through discussion and
(3) an achievement of the boost community that produces
   standards and guidelines.

So a library that reaches the state of formal review, even
if rejected has gained quality and usefulness by the process
of becoming boost compliant.

A library that has been rejected in a formal review can
stay "proposed for boost" if there is a chance for resubmission
that the author wants to pursue or can be labeled "boost
compliant", a state reached by committing the library to the
boost review process. An accepted library simply carries the
original boost logo.

Cheers
Joachim