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 17:27:09

2010/2/1 Stewart, Robert <Robert.Stewart_at_[hidden]>:
> 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.

I see your point. But I tend to prefer style over ease of
recognition here, knowing that boost users are quite
intelligent and alert people.

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

They are not supposed to be exclusive.

> The important factor is whether it is on the review queue,
> which implies that it has undergone some level of scrutiny.

I have my doubts, if the review wizards have the time
to check every library in depth. In my experience the
crucial point is to find a review manager. He will check
more strictly before giving his name and time for a
project.

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

theoretically,

but practically I have rarely seen submitters that dare to violate
boost conventions. And if they do they won't find review managers.

> A library can be "compliant" and be a horrible idea.

this case, I think, is really rare.

> That status doesn't help as I see it.

I think it does. It enables contributors to win even if not
accepted into the core. And for boost ... there are
additional associated libs in the public domain that
witness the influential power of boost.
This could be a win-win game for people who invest
time and energy but fail finally and the boost community.

Was it a bad thing to go for it, because of label: *rejected*
Or has the project gained quality in the process: *boost compliant*

Best,
Joachim