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...
> 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'
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk