Re: [boost] Respecting a projects toolchain decisions (was Re: [context] new version - support for Win64)

Subject: Re: [boost] Respecting a projects toolchain decisions (was Re: [context] new version - support for Win64)
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2010-12-28 21:56:19

On Tue, Dec 28, 2010 at 10:02 PM, Edward Diener <eldiener_at_[hidden]> wrote:
> On 12/27/2010 11:42 PM, Dean Michael Berris wrote:
>>
>> About the review process, the problem with the time limit that I see
>> is the amount of work required to throughly look at a library usually
>> doesn't fit in one week. And then the really deeper looks require
>> quite a bit of discussion to clarify points and make sure that the
>> reviewer and the library author(s) get to respond to questions and/or
>> gather feedback regarding the implementation. By making the review
>> process more of a collaborative development process instead of an "I'm
>> finished, is it good enough?" thing, you can involve more people and
>> encourage community building around your library.
>
> I agree with you that the time limit for most reviews is too narrow. It
> barely leaves time for someone to investigate a library and write a good
> review. I believe any review should last a month or more. At the same time I
> do not see why more than one review can not go on at any time. If each
> review lasted a month minimum, perhaps as long as two months, but a number
> of reviews were going on at the same time, then possible Boost libraries
> would not languish in the queue so long.
>

+1

Actually, I'd +2 if you said a review should be open until the library
gets into the main distribution. And even after that, reviewing the
quality of the library should be on-going and shouldn't stop at the
point of inclusion into Boost. ;)

> I do not however see reviews as a collaborative development process. I
> dislike your notion of software development as a community process. Software
> design is almost always an individual conception and no amount of community
> involvement is going to change that. Of course a developer can be influenced
> by the comments of others about the particulars of a software library. But I
> can never believe that a community of people can effectively design a
> software library no matter what proof you may want to try to bring from
> other environments like Linux and other open source projects.
>

Okay, it might not convince you so I won't try too hard. Two projects
come to mind: WebKit and Qt.

Also, I've been in many different situations where only the
collaborative method is the one that works to think otherwise. ;)

-- 
Dean Michael Berris
about.me/deanberris