Re: [boost] A Remedy for the Review Manager Starvation

Subject: Re: [boost] A Remedy for the Review Manager Starvation
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-05-17 11:16:06

Manfred Doudar wrote:
> Andrey Semashev <andrey.semashev_at_[hidden]> wrote:
> > On 05/15/2010 08:49 AM, Joachim Faulhaber wrote:
> >
> > > (1) Let's increase the standards: Let's make it more
> > > difficult for a library to be accepted into boost.
> >
> > Although I understand your motivation, I don't share the point of
> > making things harder for potential library submitters. Boost needs
> > more libraries, despite of the situation with reviews.
>
> +1
>
> I currently have a number of libraries that would prove of utility for
> Boost, and have been sitting on them for some time, in some
> cases, over
> 2 years.  Polishing them up, particularly with regard to
> documentation,
> keeps me from doing so for the mean time, not to mention the effort/
> time to go that extra mile, in-between my other priorities.
>
> So I share Andrey's view with respect to the above.  I expect any
> submission to be burdensome on my time, and making things more
> difficult, would make me think twice about bringing forward
> some rather worthwhile libraries.

Boost needs an active community.  As Joachim pointed out, those submitting libraries are the most highly motivated to be active, so siphoning some of that energy to managing reviews is not unreasonable.  If that burden is enough to thwart submission of a library, then it's reasonable to question the commitment of the author to support and maintain an accepted library.

> > The current
> > standards are already quite high - perhaps, too high - to get new
> > libraries inside, and raising the plank even higher doesn't
> > look like a good idea to me.
>
> -1
>
> I know what you are getting at Andrey, but would not want to lower the
> bar on what goes into boost.

+1

> > Also, I don't feel quite comfortable with the idea of giving the
> > steering wheel of the review process to newcomers, which
> > are probably not very experienced in Boost.
>
> +1

This is a misreading of the suggestion or its intent.

> When I think about Joachim's post, it becomes clear what the issue is,
> and offer a suggestion - maybe some will agree:
>
> To up the count of review managers, and hence facilitate the
> process of
> evaluating and libraries, and cutting down on a growing
> review-queue, a
> better approach might be that once a library is accepted into boost,
> an author must take on a role of an RMA for some library in the queue,
> and drive that forward to full review.  They'll be experienced up to a
> point, having gone through the submission process once before, but may
> need some mentoring along the way nonetheless.

I don't agree with this approach only because after a library has been accepted, the author must typically spend a good deal of time addressing review issues, merge the code into trunk, and begin the process of support and maintenance.  That will detract from interest and time to be a RM.

> And yes, I should put some time aside, and bring those libraries of
> mine forward, that can only be a good thing - and maybe Joachim might
> have his first RMA too.

Please do.

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