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: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-02-01 16:25:06

Joachim Faulhaber wrote:
>
> 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.

I agree with both of those, but not to your application of (2).

> 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.

Without making that text stand out from the normal logo, it is too easy to miss the variant nature of the not-yet-accepted logos.  The red clearly draws attention and makes the not-yet-accepted status clear.  Whether to use red or another color or stylistic deviation is less important than to make the logos obviously distinct from the official logo.

> 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.

I disagree with your distinctions.  A proposed library can be compliant.  The important factor is whether it is on the review queue, which implies that it has undergone some level of scrutiny.

> 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.

That's a hurdle for getting onto the review queue.  It doesn't require a special logo.

> 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.

If a library hasn't been accepted, nothing can be said about it other than that it hasn't been accepted.  A library can be "compliant" and be a horrible idea.  That status doesn't help as I see it.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.