General community and Process Questions (blog comment followups)
noel at peralex.com
Tue Jul 28 04:35:01 PDT 2009
Have a project wiki that provides a list of proposals, and for each
- 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
> 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,
> 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
>>>> concerning the grammar changes needed for underscores in numbers
>>>> No one sent in a message on this matter until I sent in a grammar in
>>>> July . Neither the coin list nor readers on my blog caught the
>>>> embarrassing but small mistake I made in the grammar . In
>>>> terms of
>>>> difficulty of language evolution, this grammar change is easy.
>>>> 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
>>>> 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.
More information about the coin-dev