"Paul A Bristow" <pbristow@hetp.u-net.com> wrote in message news:E1CMlP9-0001xF-00@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