Helping to find the usefulness of a proposal

paul.martin at gmail.com paul.martin at gmail.com
Wed Apr 15 15:54:04 PDT 2009


(In reply to "On Apr 14, 2009 2:5am, Joe Darcy <Joe.Darcy at sun.com> wrote:")

Hi,

Some of this discussion is frustrating. I think that to say that "the list  
received few serious actual proposals" is unfair, at least in terms of the  
enthusiasm of the discussions, and in terms of the criticism of the  
proposals themselves. I also don't remember seeing many requests for  
further detail in discussions about proposals, so it is unfair to criticise  
their "degree of thoroughness" after the process has closed. Further detail  
(including prototypes) could always have been provided where necessary,  
though in most cases I don't think that this was required - the extra  
detail would be most useful when taking selected proposals further on in  
the process, but that detail would not necessarily be required when making  
that selection.

Some proposals were effectively repeating RFEs, but without knowing why you  
didn't include them on your initial candidate list we cannot know whether  
raising them as proposals is actually justified (maybe you missed an  
important use case). For example my proposal on named parameters does have  
a relevant bug: 6444738 (which admittedly I did not mention, though I did  
reference another), which has an evaluation comment of "We should do this  
for 7; parameter names are also needed for keyword parameters". Named  
parameters were even on the slides at a recent (March) Sun Java  
presentation in London, but they don't now seem to be on the cards for Java  
7. My proposal was really to ask why not, but I don't think that question  
was answered.

I am also not suggesting that the selected proposals will not be useful and  
should not be chosen - they are all good choices (though they mainly ease  
syntax rather than increasing the capabilities of the language). However, I  
would like to know why other proposals were not selected, but this only  
needs to be at a high level. For example, the following categorisation  
would work for me: 'Good' (the right size, but not as good as the selected  
proposals), 'out of scope' for Coin (good, but too hard), 'rejected' (we  
won't ever do this - though a brief reason would help), and 'not  
understood'.

Much of this is probably just miscommunication and misunderstanding: after  
looking through your posts and presentations in the light of this  
discussion, I can see that you probably did want fewer and more detailed  
proposals, but that wasn't clear (to me at least) in your weekly blog posts  
and comments on the proposals.

Hopefully this all makes sense. I really did enjoy the process, and  
appreciate the effort that you put in to make it happen. But maybe a  
little 'finessing' of your conclusions would keep me happy!

Regards,

Paul



More information about the coin-dev mailing list