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@sig.com 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.