Splitting the meat of a proposal from the trivial details.
Joseph D. Darcy
Joe.Darcy at Sun.COM
Wed Apr 15 21:35:24 PDT 2009
Reinier Zwitserloot wrote:
> 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).
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
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
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