Front page | perl.bootstrap |
Postings from July 2000
Re: HERESY: *ONE* mailing list
From:
Dan Sugalski
Date:
July 25, 2000 20:47
Subject:
Re: HERESY: *ONE* mailing list
Message ID:
4.3.2.7.0.20000725233243.00dd2340@24.8.96.48
At 11:25 PM 7/25/00 -0400, Adam Turoff wrote:
>On Tue, Jul 25, 2000 at 10:59:41PM -0400, Dan Sugalski wrote:
> > At 09:41 AM 7/26/00 +0900, Simon Cozens wrote:
> > >On Tue, Jul 25, 2000 at 08:35:04PM -0400, Adam Turoff wrote:
> > > > The one idea that I left the p5p meeting with is that we need *more*
> > > > responsibility, *more* chairpeople/pumpkings and *more* direction.
> > >
> > >You cannot manufacture order out of chaos by adding managers. :)
> >
> > I'll disagree. The whole point of managing *is* to manufacture order
> out of
> > chaos.
>
>If I can speak to Simon's point, adding "managers" as managers tends
>to make the Perl6 scheme being proposed more like a day job and less
>like a fun endeavor. In a push to be serious, we can't engineer the
>fun out of the equation.
No, but neither can we ignore the need for someone to provide some level of
direction on a chunk of the world small enough to fit in one human's brain.
Scribbling a problem on the wall and throwing a bunch of programmers at it
is probably the worst possible way to get a solution.
Maybe the word "manager" carries a negative connotation for other people.
Call 'em supervisors, or leaders, or Folks With A Clue, or "That guy with
the attitute and big, pointy stick", or whatever. You don't get order out
of chaos (well, not often). Something has to push things in one direction.
>At some point, chaos is neither fun nor productive. Adding random
>management into the mix doesn't necessarily lead to less chaos or
>more fun, either.
>
>The answer is in the details somewhere. I haven't seen the one true
>community structure everyone is happy with come up yet.
Oddly enough, some of us aren't doing this strictly for fun. (Neither are
we doing it for work, or for the ego stroke) That's something that can be
used to good advantage. Not all people are motivated by the same things.
> > I'd still split it into several main lists--language design is mostly
> > separate from embedding API design, which is mostly separate from
> > PR/advocacy issues, which is mostly separate from QA things.
>
>PR/Advocacy is a separate space.
>
>QA needs to be tightly integrated into the language design as well as
>the internals. I can make a similar case for documentation.
>
>The lines are still fuzzy at the moment, and I'm beginning to question
>the wisdom of splitting an API discussion away from a core discussion,
>even with weekly updates to one central area. Aspects of documentation
>are core issues as well. While some documentation issues are discrete
>and separable, others aren't.
Some issues lend themselves to separation better than others, and some
things only need to touch base occasionally. 99% of language design is
irrelevant to designing the API presented to programs that embed perl. On
the other hand, language design and internals design go hand and hand,
though they *are* separate things.
I'm not sure some of the separations are a good thing. I *am* sure they're
necessary. Perl's gotten past the point that it can fit inside one (sane)
person's brain. Part of what we need to do is organize to minimize the
impact of the separation. (And no, I'm not sure what's best here either)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
dan@sidhe.org have teddy bears and even
teddy bears get drunk