General community and Process Questions (blog comment followups)

[Joseph D. Darcy]

Neal Gafter wrote:
> Noel-
>
> This is a great idea; it would certainly help casual observers to follow the
> status of the proposals and discussion.  That would also be useful as a
> starting point for any future Coin-like project.
>
> I volunteer to provide web hosting and software support if you'll agree to
> set up and maintain the Wiki based on the existing discussion record.
> Please let me know.
>   

I can set up a wiki under http://wikis.sun.com, as done for the Da Vinci 
Machine Project (the JSR 292 RI).  However, I will not actively maintain 
a wiki so someone else would have to volunteer to do this work.  
Additionally, one purpose of my Coin blog posts is to provide a lower 
volume way to track what is going on; posts under 
http://blogs.sun.com/main/tags/projectcoin provide news of major 
developments and links to the latest versions of proposals, etc.

-Joe

> Cheers,
> Neal
>
> On Tue, Jul 28, 2009 at 4:35 AM, Noel Grandin <noel at peralex.com> wrote:
>
>   
>> further suggestions:
>>
>> Have a project wiki that provides a list of proposals, and for each
>> proposal:
>>  - status (incoming, rejected, phase1, phase2)
>>  - links to relevant mailing list discussions
>>  - links to relevant documents
>>
>> Then people can get referred to the wiki to get an idea of what is going
>> on.
>>
>> It might also be an idea to have a real project repository where each
>> proposal lives in it's own branch, and has documents, examples,
>> test-cases, scripts, code, etc.
>> We __are__ programmers after all :-)
>>
>> For a first attempt, I think project coin has done pretty well, but like
>> all things, it can be improved upon.
>>
>> Keep up the good work Joe.
>>
>> -- Noel Grandin.
>>
>>
>> Reinier Zwitserloot wrote:
>>     
>>> No, I think it realistically indicates nobody cares about underscores
>>> in numbers. I've reviewed in detail most of the coin reviews. Even the
>>> ones I don't like (perhaps /especially/ the ones I don't like). I'm
>>> ambivalent about those underscores. My only concern is the time
>>> they'll waste that could have gone to more meaningful additions to the
>>> language, though it seems like I overestimated the time sink :)
>>>
>>>
>>> On a different note: coindev as a whole isn't a good motivator, in my
>>> opinion.
>>>
>>> In the early phases, any proposal that wasn't specced out to the nines
>>> was sort-of discarded. However, discussion on woefully underspecced
>>> proposals still continued, which wasted a lot of time - time that
>>> could have been spent analysing e.g. the grammar of the underscores
>>> proposal. It also demotivates because with the continuing discussion,
>>> it seemed that much harder for your pet proposal to make it in the
>>> face of such a big list. In my opinion, coin was missing a step: The
>>> step where you make a case for a change not by submitting a complete
>>> coin proposal, but instead by showing why its neccessary, and why it
>>> will (likely) be implementable while retaining backwards
>>> compatibility. A list full of vehement support can always back out
>>> once it becomes obvious, when writing the full JLS changes and
>>> speccing out a grammar, that the change isn't nearly as simple as
>>> everyone thought at first.
>>>
>>> As a result of these negative effects, I'm guessing volunteer
>>> involvement wasn't nearly as large as you thought it might have been,
>>> Joe.
>>>
>>> fixing it in the future:
>>>
>>>   - Be a dictator. It works, for programming languages. Reduce the
>>> amount of effort needed for round 1 of a proposal, but aggressively
>>> turn down and in fact forbid discussion on denied proposals (this
>>> isn't overreacting; coindev is the OFFICIAL list. If people want to
>>> discuss an underspecced proposal, they can do so elsewhere, and come
>>> back with a complete proposal submission). The amount of traffic on
>>> coindev was (at least for me) hard to keep up with.
>>>
>>>   - Waaaaay more time. I don't see how any new java release can
>>> exclude language changes from the get go, so start the next project
>>> coin the day after the release of java7. With timespans of that
>>> magnitude, you can implement entirely different rules:  Multiple
>>> rounds, where the round that occurs at the same timespan as where coin
>>> was to the release of java 7 absolutely requires a prototype and a JLS
>>> patch with chapter and verse. However, the first round can hold to the
>>> above concept: Just make a case for why a given language change is a
>>> good idea. coin had a conflicting agenda: Everything had to be done
>>> _fast_, but everything also had to be carefully deliberated, fully
>>> specced out. Of course it didn't work very well. The rules would then
>>> be simple: There's an agenda with minimum requirements, and any
>>> proposal that doesn't meet the minimum requirements at that point in
>>> time may NOT be discussed on the official list.
>>>
>>> - Any proposal can also be vetoed at any time, at which point the
>>> volunteers can stop their efforts and focus on other things. Veto
>>> proposals sooner rather than later to avoid wasting time. If you know
>>> it's just not going to get there, don't just say so, make it official.
>>> Keep a list of proposals 'still in the running', so to speak, and
>>> update it more often than twice throughout the entire process.
>>>
>>>   --Reinier Zwitserloot
>>>
>>>
>>>
>>> On 2009/27/07, at 22:47, Derek Foster wrote:
>>>
>>>
>>>       
>>>>>> coin contributions.  For example, back in May there was an open
>>>>>> issue
>>>>>> concerning the grammar changes needed for underscores in numbers
>>>>>> [5].
>>>>>> No one sent in a message on this matter until I sent in a grammar in
>>>>>> July [6].   Neither the coin list nor readers on my blog caught the
>>>>>> embarrassing but small mistake I made in the grammar [7].  In
>>>>>> terms of
>>>>>> difficulty of language evolution, this grammar change is easy.
>>>>>> Having
>>>>>> taken an undergraduate class in compilers or automata theory is
>>>>>> sufficient background to work on this, but no one else contributed a
>>>>>> grammar for this despite presumed interest in the feature and the
>>>>>> large
>>>>>> number of coin subscribers.
>>>>>>
>>>>>>             
>>>>> May be this shown, that interest to number literals is relative
>>>>> small ?
>>>>>
>>>>>           
>>>> I think that this more realistically indicates that everybody
>>>> considers this someone else's problem to fix. (Presumably, mine,
>>>> since I submitted the original proposal.)
>>>>
>>>> Unfortunately, I have been slammed lately by an upcoming product
>>>> release at work as well as some issues in my personal life, and have
>>>> had little time to do much else other than try to at least read the
>>>> Project Coin list messages as they go by. I did put together an
>>>> initial draft of a fix to the issues Joe raised, but I didn't have
>>>> time to really run it through the wringer and analyze it for
>>>> problems, so I didn't submit it to the list yet. When Joe submitted
>>>> his fix, I was quite relieved that someone else had had the time to
>>>> do a more complete job of it, and I was planning to go over it in
>>>> detail, but I just haven't had time yet.
>>>>
>>>> This is unfortunately a risk of having work done by volunteers --
>>>> since they aren't getting paid for the work they do, the work is
>>>> subject to being delayed due to work that people ARE paid to do. As
>>>> a result, realistically, extra time needs to be allocated for
>>>> volunteer-driven efforts, and/or some kind of structure needs to be
>>>> put in place so that if one person has trouble keeping up, that
>>>> others can shoulder the load in some sort of controlled fashion.
>>>> Right now, it is basically expected that whoever originally
>>>> submitted a proposal is responsible for shepherding it through every
>>>> distinct phase of its development, from proposal, to design, to
>>>> implementation, answering criticisms about it, revising it,
>>>> prototyping it, etc. etc. This is a LOT of work for one person. (It
>>>> also requires that a single person be skilled in every step of the
>>>> process, which requires a lot of different skills to be present in
>>>> one person. A rare mix, which is unfortunately a significant
>>>> limiting factor
>>>> on proposals.) Of course, people who are interested in the proposal
>>>> but not responsible for it are willing to offer criticisms, but not
>>>> necessarily help (since raising issues takes MUCH less time than
>>>> fixing them, after all). I think that this is a weakness of the
>>>> process that Coin is using, and one that should be addressed in a
>>>> future effort of this sort.
>>>>
>>>> In any case, this is all I have time to write at the moment, since I
>>>> am about to get in a car and take a much-needed vacation (which I am
>>>> actually finally able to take, due to my having applied nose firmly
>>>> to grindstone for the last month or so). I'll be back in a week, and
>>>> I may be able to make a more substantial contribution at that time.
>>>>
>>>> Thanks, Joe, for taking the time to address the deficiencies in the
>>>> grammar. I appreciate it.
>>>>
>>>> Derek
>>>>
>>>>
>>>>
>>>>         
>>>
>>>
>>>       
>> Disclaimer: http://www.peralex.com/disclaimer.html
>>
>>
>>
>>
>>     
>
>