General community and Process Questions (blog comment followups)

[Neal Gafter]

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.

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