Re: The Future - grim.

2000-09-10 Thread Andy Dougherty

On Sun, 10 Sep 2000, Alan Burlison wrote:

> Unfortunately the greatest volume on the various p6 sublists tends to be
> coming from the least experienced people.  The comments based on common
> sense and long experience tend to be lost in the hubbub of uninformed
> noise. 

I think the chaotic brainstorming on -language has been very necessary. We
need a forum that encourages new radical ideas.  Sure, most of them
probably won't pan out or prove worthwhile, but I'm hopeful that there
will ultimately be a few new things in perl6 that grew out of this process
that a small team of core developers might never even have imagined.

Still, I certainly agree it's overwhelming, and I'm currently unsubscribed
because I just can't keep up.

> lot of people will inevitably be disappointed when their enthusiastic
> contributions are discarded, and I have seen absolutely no discussion of
> the process by which RFCs will be accepted or rejected (and saying
> 'Larry will do it' isn't good enough).

There has been a bit of this, actually, but it's generally been "lost in
the hubbub" :-).  In my opinion, there's little point in developing a
formal procedure when many (most?0 of the RFCs won't need one (the
acceptance or rejection will be pretty obvious to everyone anyway) and
when the truly difficult-to-handle-ones will be difficult-to-handle no
matter how carefully you specify the handling procedure.

> The most difficult part of this process is sorting out the human
> issues, not the technical issues, but that is the very area that seems
> to have received least discussion.

I think, in part, that's because we're not quite at the point where we
have to face this head-on yet.  But we're getting close, and I certainly
agree that the human issues will indeed be a very big hurdle, probably the
biggest hurdle facing the entire project.

-- 
Andy Dougherty  [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042




RE: Continued RFC process

2000-10-10 Thread Andy Dougherty

On Mon, 9 Oct 2000, David Grove wrote:

> On Monday, October 09, 2000 7:12 PM, Nathan Torkington [SMTP:[EMAIL PROTECTED]] 
> wrote:

> How about an open, crossplatform mailing list for issues, with a
> mechanism on perl.org for public voting on larger issues.

In a volunteer organization, you can't reliably translate votes on issues
into action.

To be concrete, consider a perl5 example.  Suppose that there was a vote
to change from metaconfig to autoconf for perl5.  Suppose further that the
current Configure maintainer didn't know anything about autoconf and
judged himself unable to complete the task in any timely manner.  What
would happen next?  Probably nothing, unless an autoconf champion steped
forward and volunteered to take over configuration issues.  But in that
case, what was the point of the vote?  At any time, _anyone_ can step
forward and champion a cause.  If he or she makes a good case and
implements it well[*], then it will probably be adopted.

Similar concerns hold for other issues.  Without a champion to implement
the changes, nothing is likely to happen.  With a champion, no vote is
needed--the champion can just go ahead and try to do it.

There are, of course, cases where things are not clear cut.  Suppose, for
example, that someone proposes and implements a feature (e.g. safe
signals) but it has a drawback (e.g. 10% slowdown).  Should that feature
be included in perl?  That's a tough question involving difficult
tradeoffs.  It's not at all obvious to me that voting is a better way to
resolve such issues than the current process of allowing the pumpkin
holder to decide.

[*]Of course "implements it well" is a subjective criterion, but one
important aspect of it ought to be a reasonable plan for the long term
maintenance of the feature (usually the champion saying "I'll do it.")

-- 
Andy Dougherty  [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042




RE: Continued RFC process

2000-10-10 Thread Andy Dougherty

On Mon, 9 Oct 2000, Nathan Torkington wrote:

> Closed-for-posting mailing lists that are publically readable is the
> best suggestion we've had to meet these ends so far.
> 
> Anyone have better suggestions?

Just that it not be *too* hard to get on the closed lists (and,
symmetrically, that it not be *too* hard for the list chair to bounce
someone *off* the list if that person is judged to be persistently and
seriously damaging to the list).

I'm not suggesting anything formal here--in fact I think it's best if we
make it up as we go along--just that we record our overall expectation
that we're reasonable people trying to balance conflicting needs in a
reasonable way.

Andy Dougherty  [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042




Re: Critique available

2000-11-02 Thread Andy Dougherty

On Thu, 2 Nov 2000, Nathan Torkington wrote:

>  When an article
> in perl.com is so overwhelmingly negative about the work so far, do
> you think that stirs confidence in what we're doing? 

To strive for balance, I think perl.com's home page should also have the
links to Larry's ALS talk and slides.  I know they are not a polished
collection of web pages, but they are still quite readable.  They also
give a different perspective to the RFC collection.

An article emphasizing positive aspects of the process so far would also
seem like a nice idea, but somebody'd have to write it :-).

-- 
Andy Dougherty  [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042




Re: Guidelines for internals proposals and documentation

2000-11-15 Thread Andy Dougherty

On Wed, 15 Nov 2000, David Grove wrote:

> Nat and I argued parts of this (I think this is included) at some length.
> Actually, I think I drove him crazy getting specifics out of this.

[many thoughtful details omitted]

> All in all, I think Dan's doing a good job making this make sense. I'm
> just curious about the inner workings of a group.

Well, since we don't actually *have* any groups yet, I'm not surprised
that the inner workings of groups aren't clearly specified.

I think we ought to just improvise as we go along for now.  I'd much
rather have Dan spend his time and talent trying to specify the api for
perl extensions than trying to specify the api for perl development
groups.

-- 
Andy Dougherty  [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042