General community and Process Questions (blog comment followups)

Tue Jul 28 05:59:13 PDT 2009

Good points, Noel.

One of the things I forgot to mention: From time to time, discussion  
went in circles; I presume because not everyone felt up to the task of  
reading through the backlog of the coindev list (due to the sheer  
amount of traffic, I can't really blame them). A wiki would be a much  
nicer format, and by way of the wiki history function, you would  
_still_ have a time-based history of how the community decided on a  
certain change, which is one of the stated goals of the coindev  
mailing list.

  --Reinier Zwitserloot
Like it? Tip it!
http://tipit.to

On 2009/28/07, at 13:35, Noel Grandin 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
>
>
>