General community and Process Questions (blog comment followups)

[Reinier Zwitserloot]

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
>
>