Splitting the meat of a proposal from the trivial details.
reinier at zwitserloot.com
Thu Apr 16 03:51:28 PDT 2009
If Coin did effectively take 3 months, that's all the more reason to
open up coin-dev for the complete 3 month timespan!
By restricting discussion to the shortlist after a month and a week, a
lot of interesting but not relevant chatter about proposals that
definitely won't make the grade anyway can be weeded out. At times I
felt the coin discussion turned needlessly specific for early stage
proposals, and yet for other proposals, the idle banter on vague
proposals was distracting from finalizing the details on something
On Apr 16, 2009, at 06:35, Joseph D. Darcy wrote:
> Reinier Zwitserloot wrote:
>> Actually, Joe has repeatedly turned down proposals because they
>> were laughably incomplete,
> Quite so!
>> 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).
> Part of my goal of sending in the strings in switch proposal (first
> post!) was to demonstrate the sort of details that can come up even
> in the simplest of changes.
>> 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).
> Yes, the limited size of the set of possible proposals was
> established before the call for proposals started.
> However, the time required to write up even a fairly detailed
> proposal, say 8 hours, pales in comparison to the possible effort
> needed to fully implement a proposal.
> For example, implementing just the *single method* Class.isEnum
> probably took around five hours of effort during JDK 5. While this
> method is only two lines long, three tries were needed before
> getting the right two lines; more detail on why this happened is
> described in:
>> This provides a dilemma: Put in all that effort for not much to
>> show for it?
> As I've stated before, Project Coin is a participatory process,
> which means people have the opportunity to participate in the work
> of a proposal too :-)
>> 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.
> While some iteration and refinement of proposals is fine and
> expected, details are not trivialities. Seemingly small details can
> make a difference and having some set of details available early
> allows better decisions to be made.
>> 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:
> The future existence of what would be known of Project Coin was
> announced on December 8, 2008 (http://blogs.sun.com/darcy/entry/small_language_changes_jdk_7
> ). This included an overview of the coming call for proposals and a
> link to "So you want to change the Java Programming Language...",
> whose content served as the skeleton for the later proposal form.
> The proposal form was published in January 27, 2009 (http://blogs.sun.com/darcy/entry/project_coin
> ) and the mailing list started a month later, February 27, 2009.
> So there was a three month period before the call for proposals
> officially got underway, and a month after the form was published
> but before a proposal could be submitted, where interested parties
> could think about proposal ideas and possibly implement them, guided
> by the published criteria for the effort.
> There were a few inquiries to the list to ask for help drafting a
> proposal and some "pre-proposals" sent in to get a reading on
> whether a proposal topic would be smiled upon, both of which are
> good, on-topic uses of the list! However, after my unfavorable
> assessment of the "Source and Encoding keyword" pre-proposal (http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000298.html
> ) was sent to the list, people choose to continue the discussion for
> a time. Some continued discussion is fine, but people who send in
> proposals or pre-proposals don't to tend to give up right away ;-)
> To reiterate terms of roles and responsibilities here,
> "Especially with the maturity of the Java platform, the onus is on
> the proposer to convince that a language change should go in; the
> onus is not to prove the change should stay out."
> December 23, 2008
> Having thought through the details is one way to be more convincing.
More information about the coin-dev