Boost logo

Boost :

Subject: Re: [boost] [review queue] Proposed new policy to enter the review queue
From: Deniz Bahadir (dbahadir_at_[hidden])
Date: 2017-03-17 10:10:52


Am 16.03.2017 um 22:38 schrieb Robert Ramey via Boost:
> On 3/16/17 1:47 PM, Niall Douglas via Boost wrote:
>
>> Here is my proposal:
>>
>> 2. For a library to enter the review queue in future, it requires at
>> least one (and preferably more) named members of the Boost community to
>> publicly endorse the library to enter the review queue. Their names will
>> be listed alongside the library in the review queue page at
>> http://www.boost.org/community/review_schedule.html.
>>
>> 3. Endorsing a library has NO RELATION to review managing a library.
>> Indeed if only one person endorses a library for review, they are not
>> permitted to act as review manager.
>>
>> 4. To find someone to endorse a new library for review, the library
>> author ought to ideally canvas for a library's motivation before they
>> ever begin writing or designing it, but failing that they need to
>> approach boost-dev and publicise their library seeking someone to
>> publicly endorse it for review. Other forums work too e.g. reddit/r/cpp,
>> the Incubator or anywhere else. Ideally I'd prefer if the Incubator
>> *was* the place where people endorsed a library for review and their
>> name automatically was added to the review queue page, but I appreciate
>> that's a lot of scripting.
>
> I think the scripting is already in there. I think you could just say -
> in order to be officially reviewed it has to have two reviews in the
> incubator.
>
>> I am personally highly unsure of Robert's suggestion (he claims it was
>> mine, it was not) that every author of a library entering the queue
>> needs to review manage a library first.
>
> Sorry. I thought that was your proposal. It's a worthy proposal in any
> case.
>
>> The above proposed policy effectively pushes the bottleneck higher up
>> the chain, but I think that's no bad thing. Library authors, myself
>> included, like to build cathedrals irrespective of whether anyone will
>> ever use them nor appreciate them. Currently it's too easy to build a
>> library nobody will ever use and get it into the review queue where it
>> will languish for many years because no review manager will touch it.
>> That part needs to change.
>
> All this was/is behind the design of the inclubator. The idea was that
> reviewers who downloaded a library from incubator would try it out -
> likely because they needed it - and write a review. Sort of like
> Amazon. This would
> a) decouple reviews from 10 day review period.
> b) give authors earlier feedback - which they desperately need.
> c) automatically filter out bad and/or inconsequential ideas.
> d) increase the number of reviews available
> e) thereby making the review manager's job much easier.
> f) provide a cool netflix style rating for different aspects of the
> library if a library has garnered 5 or more reviews
>
> In addition it would provide a permanent chain of comments documenting
> the history and resolved/unresolved with the library.
>
> There are some 40? libraries posted and I'm happy about that. But I'm
> disappointed it hasn't had any noticeable impact on the review
> situation. That might be helped by improving it, but I'd probably not
> be motivated without a little bit more success. And improvements WOULD
> require significant scripting - which is agony for me. I'd like to see:
>
> a) The comment mechanism transformed into a window into the developer's
> list.
> b) A method to clone a library directly from incubator. This would give
> me statistics on the number of people who have downloaded the libary. I
> could also likely capture the email address so I could automatically bug
> them to review the library. I think both of these would be helpful
>
> So that's where we are on that.
>
> Robert Ramey
>

I think, the idea behind the Boost Library Incubator is great. However,
it probably should be advertised better.
But I do not mean that Robert should tell the people more about it via
the boost-mailing list. (He is already doing a good job doing that.)
Instead, I would prefer a tighter coupling between the Boost website and
the Boost Library Incubator website.

Just looking at it from a more outside point of view I would say:
The Boost website does not look sexy.

It looks quite old-fashioned, has a lot of text, but how that is
structured is not easy to grasp by a short glimpse. And except for
finding the current download and the list of current libraries it is
quite hard to find particular information fast (if at all). (The GSOC)

For example, I just tried to find a reference to the Boost Library
Incubator from the Boost website. I did not succeed. I thought, there
must be a link somewhere (and there probably is) but I did not manage to
find it. (Even when using the search-functionality I only got references
to e-mails on boost mailing-lists that mentioned it.)
If it would be advertised more prominently on the website it might get
more attention.

Or another example is Trac. It is really ugly and leaves the impression
that not many issues are worked on. (We had this topic already in this
mail-discussion.)
(A short anecdote: When I first tried to use (= report issues to)
Boost-Trac some years ago the website's response was so slow that it
felt like being down. Luckily, these problems seem to be solved for some
time now.)

There is a reason, Github is so successful and people are using it (and
in general prefer using it) despite the fact that Git is popular:
It is easy to use _and_ it looks sexy.

Probably, it would be a good idea to use some of the money Boost has to
pay a professional web-designer to create a new, easier to use and
appealing (aka "sexy") website. And then it should probably directly
integrate the Boost Library Incubator.
And if it were possible to rate the libraries (from the Incubator) with
a simple (star-)system and allow reviews/comments directly via the
website (both similar to Amazon) it would probably gather more interest.

Just my 2 cents.
Deniz Bahadir


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk