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-02 09:09:48

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

We'll have to agree to disagree then.  I think it critical to distinguish between accepted and not.

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

Do you mean, then, that a "proposed" library isn't "compliant?"  No library would be accepted for review if it weren't "compliant."  I fail to understand the distinction you wish to draw here.

> > 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 doesn't get on the review queue until that point, does it?

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

All one knows at that point is that someone thought it good enough to get a review and that Boost rejected it.  Whether the code is in the boost namespace is hardly a justification for getting a variant Boost logo.

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

Why, then, do you suggest a logo variant to distinguish the two?

> > A library can be "compliant" and be a horrible idea.
>
> this case, I think, is really rare.

Nevertheless, your approach would grant such libraries the opportunity to use a Boost logo that implies tacit approval.

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

A library that isn't part of Boost shouldn't use the boost namespace.  The rest of your "compliant" characteristics are of very little benefit for libraries not part of Boost.  Even given those characteristics, why should a library thus earn the right to display a Boost logo beyond "powered by?"

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

There are many projects of high quality that aren't even submitted to Boost.  Why does submitting a library for review and getting it rejected make it special?

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