develooper Front page | perl.bootstrap | Postings from July 2000

Re: Perl version of Python Enhancement Proposals [PEP]

Thread Previous | Thread Next
July 24, 2000 03:24
Re: Perl version of Python Enhancement Proposals [PEP]
Message ID:
Ask Bjoern Hansen (lists.bootstrap):
>When we get more working groups going we should maybe have the
>"RFC's" "attached" to one of the working groups or in some other way
>make sure to have a public forum for discussion of the RFC.

Uhm, with all due respect, I think this is precisely backwards.
Here are some ideas I had the other day.

=head1 Why we're not the IETF

Nat told me that the people at the meeting examined various development
models: Linux, Apache and some others, and then decided on a model
similar to the IETFs. It's my contention that the goals of Perl and the
goals of the IETF are very different, and the models are not comparable.

=head2 The Internet Exists

The main purpose of the IETF isn't development. It's documentation.
They're setting down standards for Internet protocols and behaviour
which, on the whole, already exists. Yes, they do some development -
ipsec comes to mind immediately. 

Have you B<read> the ipsec mailing list? The ipsec working group was
formed in 1992. The proponents of the IETF model for Perl say that
working groups do their job and are then closed. This isn't particularly
true; ipsec produced its first tangible protocol, ESP, in 1998. That's six
years. The full IPSEC protocol is not there yet, and the list continues
to operate.

=over 3

=item *

Documentation in this style is fast and effective. Development in this
style is slow, boring, unproductive and generally not fun.


=head2 Keep It Simple, Stupid

Compare and contrast:

    "If you're interested in working on Perl, join the perl5-porters
    mailing list."

I join the list, I set up a new mail filter rule, I contribute.

    "If you're interested in working on Perl, select the mailing lists
    which cover the topics you're particularly interested in, making
    sure that they haven't already done their work and have been closed

I join a bunch of mailing lists (who was it that said email is a
conspiracy to waste people's time?) and set up a bunch of filters, I
work out which mailing lists are appropriate for what I want to say.
(Argh, should posts about Windows threads go to perl6-windows,
perl6-threads, perl6-configure or should I start
perl6-windows-threads?!) I contribute. I get smacked down because I
didn't write an RFC.

=over 3

=item *

I want to encourage more people to work on Perl. To do that, it needs to
be easy for them.

=head1 Why we don't need an RFC process

I'm going to start here with a bizarre point that may sound like
dangerous philosophy: a perceived problem is a real problem. It's
not that odd, actually; it's a serious principle of man-management.
If someone feels that they have a problem, then they're going to be
uncomfortable and unproductive in that area. Assuming rationality,
there's something they have a problem with. Whether that's B<actually>
a problem or not becomes immaterial; it needs to be fixed, changed or
elucidated to remove the perceived problem.

I'd like to extend that to the formality issue. Perceived stuffiness is
as much of a problem as real stuffiness. Looking over at my incoming
mail logs, I see someone is suggesting renaming "working groups" to
something else. They've got a perceived problem with the stuffiness

I can see a "code style working group" on the horizon, and it's not
a horizon I want to cross.

=over 3

=item *

People don't like working under bureaucracy, real or perceived.


=head1 So what instead?

It's easy to complain, but it's harder to come up with more feasible
solution. Let's examine how people will behave on these lists.

Some people, like me, are generalists, and they'll want to read
everything. A single list works best for these people - they've got
everything they want to read from a single source. They also don't need
to work out where to direct responses and comments. 

Others will only be interested in their chosen fields, and they'll read
everything they're interested in and skim the rest. A single list will
be inefficient for them, but workable. A list per topic will be optimal
for them.

Some people will want to chip in occasionally, not reading everything.
I expect these will be in the majority. A single list will be best for

However, both the first two sets of people will read all the ideas about
what they're interested in. So an RFC track won't help them at all.
However, RFCs B<are> useful for marking where various fields have got to
so that we can ensure that, for instance, people from the VMS department
hear proposals from the Unicode department and make sure they aren't going
to smash up EBCDIC support. (Heh, heh.)

So it's these people who read everything that can draw up the RFCs
B<AFTER> the viewpoints have been bashed out.

So, I would:

=over 3

=item *

Maintain a central list for those who want to chip in ideas.

=item *

Once momentum has been achieved on an area, take the bunch of people
away to a separate list, but still listen out for suggestions about the
are on the main list.

=item *

The separate area lists will have a pumpking in charge. (Let's call it a
pumpking; "managers" spook people.) The aim of the list will be to have
the pumpking collate the ideas and turn them into a design.

=item *

Pumpkings regularly post status updates to the main list for two
reasons. Firstly, so other pumpkings can make sure their plans aren't
getting clobbered. Secondly, so that interested parties who aren't
interested B<enough> to join a separate mailing list can provide
feedback on the goings-on.


This is, I believe, tailored to allow people to participate to whatever
level they want.

Thermodynamics in a nutshell:
1st Law:  You can't win.  (Energy is conserved)
2nd Law:  You can't break even.  (Entropy)
0th Law:  You can't even quit the game.  (Closed systems) -- Taki Kogoma

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About