Helping to find the usefulness of a proposal

[Joe Darcy]

On 04/02/09 04:30 PM, rssh at gradsoft.com.ua wrote:

[snip]

>>> Note, that I does not propose use polls as one and only one criteria. I
>>> just tell that see result of such poll will be interest.
>>>
>>> // btw - from other side, all this activity is overkill, I can suggest,
>>> // that  accepted proposals would be exactly same, which was listed in
>>> // project-coin description (before coin was started)
>>> //     http://blogs.sun.com/darcy/entry/project_coin
>>> //   +ARM  +jsr292  and ...  it's already 6, which is more than 5 :)
>>>
>>>       
>> Your own sentence disproves your point since ARM was not listed among
>> the five proposal areas under consideration before Project Coin started.
>>
>>     
>
> I mean not '<cite>would be exactly same, which was listed in project-coin
> description (before coin was started)[url]</cite>', but '<cite>would be
> exactly same, which was listed in project-coin description (before coin
> was started)[url] +ARM  +jsr292</cite>',
>  sorry for ambiguity.
>
>  ARM floating around (and widly discussed) from late 2007 or early 2008.
> And all we know, that if BGGA will not available, than at least ARM must
> be included.  

I don't know that.

> I. e. I can't say that ARM is 'external' and new or not to
> be generally known be included in Java 7 before project coin start.
>   


> I have no pretension about judgement process, It's only about information
> flow: i. e. Sun have all proposals before and <IMHO> call for new
> proposals with process of selecting 5 from set of newly received and 5
> apriory well-known items, for which we know, that they are necessory, it's
> near the same, that throw away all non-apriory proposals.
> </IMHO>
>
> I. e. I guess, that when people asked to submit new proposals, they expect
> that exists demand for new proposals, not demand for choosing from five
> well-known items. When appointment of all new proposals to be thrown away,
> with role be backgroung for well-known items, people, which invested some
> time in such activity, usually frustrated. It's why I think, that call for
> new proposals, whithout real possibility to implement something new (not
> well-known before) was an error. If we have slot, for example, in summary
> for 10 proposals to implement (5 well know and 5 new) - then all ok, it's
> fair game.
>   

Amongst other factors, the maximum number of proposals that can get in 
is a function of how many people work on implementations.  Very few of 
the proposals had any accompanying prototype.  For example, I'm 
sympathetic to the idea of having literals for bit strings and the like; 
those are much more likely to end up as part of the platform if people 
outside of Sun take the lead on the implementation.  However, even with 
help from the broader community, there is still an upper-bound on how 
many small language changes can get in because of various kinds of 
coordination activities that do not scale and the non-implementation 
aspects of the work (specification and testing).

Many of the submitted proposals were not really proposals in terms of a 
thoughtful analysis of what it would take to add a feature to the 
platform; rather they were "requests for enhancement" in Sun bug 
database terminology where much of the hard work of thinking through 
implications and interactions was left undone.  Existing discussion of 
such issues from Sun's bug database were often ignored even though they 
can be found by a simple web search query.  And a specification is much 
more than the grammatical changes involved!

>>> I. e. doing project coin with external auditory  was a 'Sun system
>>> error',
>>> I guess; if they want some feedback from community, correct way was at
>>> first implement own stuff, than ask community for something new ;)
>>>
>>>       
>> The call of proposal phase of Project Coin is an effort both to solicit
>> feedback from the external community and also to invite the external
>> community to participate more directly in evolving the language.  That
>> opportunity to participate also implies participating in the large
>> amount of work required to go from "I have this great idea!" to "I have
>> this great idea and here is a carefully considered review of all the
>> implications of the idea, along with a prototype."  The blogs I wrote
>> last year and the proposal form itself are part of an effort to explain
>> and expose what this language work entails so more people can get
>> involved.
>>
>>     
>
>
> It would be great, to participate in language evolution in future.
> For now I does not see general aviable process for future participation:
> call closed, all new proposal throwed away.
>   

I would counter the list received few serious actual proposals, which is 
directly tied to why few proposals (so far) have been selected for 
further consideration.  I reviewed all open language specification RFEs 
last year.  A restatement of an existing RFE in Sun's bug database as a 
Project Coin proposal without any further analysis has approximately 
zero value. 

Last year I published a list of five proposal ideas to seed the 
discussion.  Opinions will differ of course (different parts of the 
elephant), but I think few of the submitted proposals were as compelling 
as the problems being addressed by those initial five proposals, which 
again relates to why those proposal areas have not been displaced by 
subsequent ones.

> Finish. Fire bug reports is useless - they will live in bugzilla for years.
>
> One possible solution: is make 'coin project' regular, for example once a
> year. (May be with
> entry barrier as 'required implementation in some form')
> Another - propose some process (may be long) for author, how to push his
> proposal (whith implementation)
> into language after JDK7 (or receive official position, that this change
> is rejected)
>
>
>   
>> Unfortunately, many of the submitted proposals did not do a credible job
>> of analyzing the true effect the proposal would have, which has a rather
>> strong relation to why many were not chosen for further consideration.
>> For example, let's take the "'This' type" proposal:
>>
>>     
>  ...
>
>
> Problem with inaccurate proposals - it's well known problem, the same with
> publications, wildly used technique is peer review. (Honesly, overall
> quality of proposals was better that I was expected).
>   

Yes, the list is for peer review and many proposals found a vigorous 
discussion there!

In retrospect, I think it would have been helpful to publish, say, the 
completed strings in switch proposal form sooner after the proposal form 
was published.  That form for a very simple language change indicates 
the degree of thoroughnesses I would have liked to have seen from all 
the proposals:

http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000001.html

> Good entry barrier can be requirement to proposal to be implemented in
> some form.
>
> P.S. Project coin involved me to think about Java more close than before.
> So, despite my criticism, you achieve goal to raise interest to
> participate in process of Java language evolution ;)
>   
That is something at least ;-)

-Joe