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  

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