General community and Process Questions (blog comment followups)

[Noel Grandin]

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