Re: [boost] Formalising the review process into a well specified workflow (was: Re: [Boost-announce] [metaparse] Review period star

Subject: Re: [boost] Formalising the review process into a well specified workflow (was: Re: [Boost-announce] [metaparse] Review period star
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-06-03 08:51:11

On Wed, Jun 3, 2015 at 1:04 PM, Niall Douglas <s_sourceforge_at_[hidden]> wrote:
> On 3 Jun 2015 at 5:07, Rob Stewart wrote:
>
>> At this point, everyone is agreed to proceed, so this will be a lesson
>> for future library submitters and review managers.
>
> I think that is exactly the wrong conclusion to draw, and the past
> drawing of that conclusion had led to us repeating, yet again, an
> unpleasant and inefficient review compared to what it should have
> been. No wonder the review pipeline ground to a halt in the past,
> everyone just gets put off.
>
>
> A much better conclusion to draw is this:
>
> 1. There is more than one kind of library peer review:
>
>   a. "I'm working on this new library, I would like to hear comments
> on it"
>
>   b. "I have this preexisting mature library which I would like to
> add to Boost, is Boost interested in it?"
>
>   c. "I have an idea for a new library, would Boost be interested in
> it?"
>
>   d. "I have finished this library and I believe it is ready to enter
> Boost"
>
>   Also:
>
>   e. "I have substantially refactored an existing Boost library into
> a breaking change which affects other Boost libraries"
>
>
> 2. Different types of library review have different procedures, so
> essentially:
>
>   a => Incubator
>   b => Formal Review, no Review Manager
>   c => boost-dev mailing list
>   d => Formal Review, needs Review Manager
>   e => Whatever the maintainer thinks best

I think you're mixing reviews and interest polls and discussions. Of
all above items, (d) seems the closest to the formal proposal for a
review. Well, maybe (e) also, if the author wants the refactored
library to be formally reviewed. The proposal, as well as requirements
to the library and review process are already formalized on the
website.

The rest are informal discussions that cannot result in a library
inclusion but may serve development. I don't see why we would need to
formalize such communications.

> 3. Different kind of library review should have detailed, step by
> step, "tick box" formalised procedures (formal workflow) to take the
> (prospective) library author from where they begin to a successfully
> completed conclusion with a minimum of inefficiency.
>
>
> 4. There is no shortage of free web tooling which can automate the
> ticking of those boxes and walk library authors through the
> formalised procedure. Indeed, Boost already is on Google Apps, and
> Google Forms is one of the best free web tooling for forms. Unlike
> most other Boost infrastructure needs (hint - is my volunteering to
> upgrade Trac approved? If so, a ball needs to start rolling) where
> our infrastructure requirements simply aren't there yet, for Forms
> and workflow programming we are ready to go.
>
>
> 5. Ideally in the future a review manager would have their own form
> with boxes to tick, and part of their form would be to check the form
> the library author filled in i.e. the forms themselves feed into one
> another as part of the programmed workflow.
>
>
> If the community likes this idea, I can spec it up into another grant
> proposal and submit that to the steering committee.

If I'm not mistaken, you already proposed an automated review process,
like a checklist or something. I'm strongly opposed to any automated
review scheme where expert opinions are not involved or required. I
believe human review is the cornerstone of the whole review process
and not any formal checks like directory layout, test coverage, VCS
and build system used an so on. I'm not opposed to automating such
checks but only to help the review manager and the author to assess
whether the library is ready for inclusion (whether such assessment is
done before or after the review).