2010/2/1 Stewart, Robert <Robert.Stewart@sig.com>:
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