Splitting the meat of a proposal from the trivial details.
Reinier Zwitserloot
reinier at zwitserloot.com
Wed Apr 15 17:03:09 PDT 2009
Actually, Joe has repeatedly turned down proposals because they were
laughably incomplete, and Neal Gafter had gone through the trouble of
writing up an example proposal before March 1st that showed most of
the concerns that were nonetheless completely skipped in most
proposals (such as definitive assignment rules).
However - I still mostly agree with your sentiment. The amount of work
and detail required before a proposal was considered 'complete' was
considerable, and yet the vast majority of proposals (even with the
neccessary detail) were clearly going to be rejected (only 4 to 5,
tops, that's been said many times).
This provides a dilemma: Put in all that effort for not much to show
for it?
I felt that many (but not all) of the proposals essentially had enough
detail in them to allow you to figure out if they were a good idea or
not. If there had been another month, such a half-finished proposal
could have been pointed out as 'would be on the shortlist, if only
someone went through the effort of going through all the details,
including writing down something like the definitive assignment rules.
I think we'd have seen more useful discussion on proposals, and waste
less time on trivialities, if it had been set up like that.
For example, I was going to write up my plan to allow named parameters
in method signatures, but in the end decided against it, because
writing out the full JLS spec including chapter and verse would have
been too much effort, compared to the tiny chance it would have been
considered worthy for coin. If, however, there was a separate pre-
proposal phase, I could have easily written up the gist of the
proposal, many examples, and ample support that my proposal would be
backwards and migration compatible, would not lead to much confusion,
and would not be amiguous. If, then, the proposal would be accepted as
'likely good for java, -if- fully specced and no surprises turn up',
I'd gladly have taken the time to write it out in excruciating detail,
and cook up a prototype.
This Project Coin was pressed for time, so much more than a month just
wasn't on the table, but for next time, I suggest smearing out coin
across 3 months:
Day 1-30: Pre-proposal Month.
A Pre-proposal discusses the feature at hand, what it'll solve, ample
example code of real-life situations so we can all assess the utility
and impact of the change, and much discussion about backwards and
migration compatibility, how confusing the feature may be in certain
situations (a.k.a. the java puzzler factor), and if the proposal is
ambiguous. This is not the time to complain about potential problems
and ambiguities for which the complainer-to-be can already think of a
fairly simple solution by himself - this is about fundamental issues
with a proposal, and the merits of each. Not for sweating the small
stuff.
The deadline for submitting a pre-proposal is day 20 (to give pre-
proposals submitted on the deadline at least 10 days to be discussed).
Day 31-37: Rest week.
Day 38-45: Pre-proposal sorting. Be it via polling or internal
decision by sun or a combination of the two, this is the time to sort
pre-proposals into 'no way', and 'on the shortlist'.
Day 45-90: Prototype and spec month.
This is the time for the shortlisted proposals to be fully specced
(with chapter and verse of the JLS as well as rewrites for the JLS),
and preferably a working prototype. The deadline for delivering the
spec+prototype is day 75, to give the list time to analyse all
proposals, even those submitted on the deadline. This IS the time to
name rare and easily solved nitpicks, ambiguities, no matter how
trivial, and other ommissions. At this point the discussion should
turn towards implementation detail, and not so much the merits (all
pre-proposals on the shortlist have already been deemed as having the
merit to make it, so if you don't like a proposal that's on the
shortlist, or you do like one that isn't, tough - the decision has
been made, move on). Of course, proposals that end up being more
complicated than they appeared to be in the pre-proposal phase can
still be discussed on merit (is it STILL worth it, now that we figured
out it's going to be this complicated?). I would be tempted to say
that ONLY shortlisted pre-proposals should even be considered in this
phase, as to keep down unrelated chatter on pet projects.
Aftermath: The shortlist is amended: Those on the shortlist that were
unsifficiently specced out are tossed, regardless of merit (if it was
such a good idea, ostensibly someone would have written it up
properly). Those that are fully specced are reconsidered again.
Preferably soon after the end of the 3 month period, the semi-official
list is released. (semi-official as in: These are the new language
features, barring unexpected surprises when we implement these into
the JLS and javac).
How some of the proposals would have gone, if the above flow had been
used for coin:
ARM - posted early in the pre-proposal phase, all the discussion we've
seen, without the need for Josh to keep updating the proposal in all
that detail. Somewhere around today, Josh or someone else coordinating
with Josh, starts working on a prototype. 2 months from now, with a
complete spec and prototype, ARM is officially accepted into java7
(well, if there hadn't been JSR issues).
Neal's expression blocks - little discussion (we haven't seen much in
coin either), but nobody can come up with serious issues either, and
neal adequatedly shows that the block proposal is unlikely to cause
serious issues. For whatever reason (denying pre-proposals should not
need a lengthy defense), the pre-proposal is not put on the shortlist,
and that's where it ends.
--Reinier Zwitserloot
On Apr 16, 2009, at 00:54, paul.martin at gmail.com wrote:
> (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