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