[boost] Re: Re: FORMAL review process not working well?

From: Johan Nilsson (johan.nilsson_at_[hidden])
Date: 2004-10-29 08:09:54

"Paul A Bristow" <pbristow_at_[hidden]> wrote in message news:E1CMlP9-0001xF-00_at_he200war.uk.vianw.net...
> 
> 

[snip]

> 
> IMO review is the wrong time for radically better ideas -
> for they are often shooting from the hip, half-baked and in need of much
> more refinement.

It's not the most ideal time, but isn't it always better late than never - at least for the truly radically better ideas ;-) Apart from that there might also be people who actually missed the original discussion.

> 
> It seems wrong to me to have work which has been discussed and refined and
> tacitly used and accepted over a long time (necessarily waiting in the
> review queue) to be suddenly turned upside down at review, often by people
> who did not participate in the original discussions - a natural consquence
> of the quite rapid Boost membership turnover leading to 'Not Invented Here'
> syndrome.

Could the NIH syndrome be diminished by easier accepting more people into the actual development process for a particular library? Ok, so I'm mostly a lurker here, but even so I believe I've seen people from time to time declaring their willingness to participate in developing a new library, without getting some real response. Take them in, let them be a part of the effort, and maybe the NIH problem will be lessened.

I acknowledge that cooperating can be difficult, cooperating globally even more difficult, and that there will always be people that are in some ways "better" than other at developing software; be it due to talent, experience, intelligence, a feeling for the craft or whatever. Still I think that software developed by more than one person will generally be of better quality than the opposite (exceptions exist, of course). Reviews (formal or not) are good, but I think that it's hard to review the code to the same extension that you do while you're actually implementing the stuff.

> 

[snip good ideas]

> 
> So I foresee the process being:
> 
> 1  Asking for interest.
> 2  Floating ideas and working on code.
> 3  Getting to a point where the submitter(s) feels that he(they) has
> something worth considering.
> 4  A 'Working on a definite proposal' period - a month perhaps.
> 5  Digesting input and revising, re-grouping, or abandoning, or going back
> to the drawing board.
> 5  Final formal review (a week) and vote.

I'd like to explicitly add "Collect and document functional requirements" to the list, maybe at 1 1/2 above. 

Just my 0.02EUR.

// Johan