Alan Burlison wrote:
>
> Adam Turoff wrote:
>
> > It would have been nicer to institute this policy from the start,
> > but no one expected to get 200 RFCs in just over one month, either.
>
> Indeed - I think everyone was astonished by the rate at which they
> appeared. I just hope the code is produced at the same prodigious rate
> ;-) As I said I was becoming increasingly dismayed by the continuing
> stream of RFCs, and in the end felt I had to raise the issue. Having
> done so I have been very happy to see the wide consensus that seems to
> be appearing.
Huh? I'd say quite the opposite. I expected more. There are many, many
people who use perl. Anybody who uses anything will come up with ways to
improve it (though many improvements aren't.) And we don't just use perl
like we use a fork or spoon. I average a lot more time per day using
perl than just about any other tool (ok, my chair and my computer are
exceptions.)
Some percentage of these ideas for improvement will end up cast as RFCs.
This is a signal-noise problem, and as such, attacking it by attempting
to remove all noise isn't going to work. (Ok, it'll work, but it'll kill
most of the signal too.) Better would be to improve the filtering. Don't
mandate prototyping, but make a standard Status: code for RFCs that are.
Same for test cases. (I think there's a stronger argument for requiring
RFCs to come with test cases than for requiring prototypes, btw.) Then
sort by those fields and time since last update.
The noise in discussions is harder. I don't mind it much, though, since
I scan the author names and skip discussions that aren't inherently
interesting and don't contain people I recognize and respect. If it's
that great, it'll show up as an RFC. I also jump over subthreads that
spin off into the night. I end up reading 20-30 messages a day, more
when I'm avoiding work.
But if you wanted to improve matters, I'd suggest *more* RFCs: if
discussion goes in circles, fork the RFC to contain both halves. If one
half is all noise, it'll fizzle out. Add more states to the RFC process.
The noisy ones will wander off when it comes down to implementation or
concrete design discussion. Give up on the idea of monitoring the
overall evolution of perl6, since that's barely started anyway. Noise
largely derives from the impatient; it'll die down over time.
I'd also argue against the idea of stamping all RFCs with "ACCEPT" and
"REJECT". That's fine for some, but the best way to avoid demoralizing
someone by not incorporating their RFC in the initial perl6 design is to
postpone it. Lump it in with the darlings of other pieces of the
community, and keep an eye on that lump so that you can allow much of it
to be added later. I dislike the notion of gathering *all* requirements
first, and forging a gleaming new all-encompassing design out of them.
That works for some things, but it won't for Perl. Punting things to
"post-v1" is not rejection and won't feel like it is. And the
illuminating light of v1 will do wonders for firming up the advantages
and disadvantages and means of realization of the post-v1 lump. Even if
it's something that requires a core change -- the core _will_ change,
and most of these things are a heckuva lot easier to add in than threads
or Unicode.
But Larry has already proven his ability to keep productive avenues open
while still accomplishing the primary goal (see Perl5!), so I don't
think we're headed for disaster.
