We threw the floodgates open and a lot of stuff washed in. The overall
odor and consistency of the stuff wasn't that great, and the number of
real gems mixed in was kind of low. 'Nuff said. What's the point in a
purely retrospective analysis? We do need to take the lessons learned,
but only in order to apply them to what's coming next. To put my money
where my mouth is (always a strange image), I'll evaluate the process
along a couple of dimensions:
Generating complaints about the current capabilities of Perl5:
-------------------------------------------------------------
We did ok here, but much worse than I'd hoped. Part of the problem is
that many people feel that this was not what the RFCs were for (maybe
correctly, maybe not). So the voices of people with a dislike for what
they have to do in order to accomplish something were lost if they
didn't have a firm idea of how to fix it. Which is too bad, because
that's the most valuable asset to a language redesigner: a clear view of
the scope, magnitude, and nature of all the perceived problems, real and
imaginary. He needn't fix all of them, but knowing them will make it
much easier to firmly ground his solutions, to make sure that they're
alleviating actual user pain and not just twiddling things.
Conclusion: we need to permanently prop the doors open wider for
complaints. The initial RFC process opened them much wider than they'd
been, but we need to be better about eliciting complaints and keeping
track of them. The overhead is too high for most complainants to bother.
To me, this means having another type or status of RFC -- more of a bug
report/feature request, really. You know -- those things that on p5p are
met with "ok, so come up with a solution and implement it so we can
argue over the performance implications of your patch on a CDC-6600."
That, or "if you want Java, you know where to find it."
Generating ideas for new capabilities of Perl6:
-----------------------------------------------
I think we did well here, though I'm biased by thinking that there's
nothing wrong with the capabilities of Perl5; they just need to be more
accessible. On the other hand, we probably would have gotten 80% of the
benefit from this category even without the RFC process -- Damian
wouldn't sit still, right? :-) To break this category down, I think we
did well on the generation of ideas (though not as well as with a more
focussed forum), ok on figuring out Perlish ways of accomplishing those
ideas, and pretty badly on figuring out how to implement them.
Conclusion: Pat yourselves on the back, and start seriously thinking
about how this is all going to work. ("use Python;" is *hard* to do
right!)
Getting more people usefully involved in perl/Perl development:
--------------------------------------------------------------
Unclear. A few new good voices are being heard, but we can't really tell
yet how long anyone will stick around. The number of people who bowed
out of the process in disgust was encouragingly low. :-)
Conclusion: none
Recording complaints, suggestions, and conversations for future
reference:
-------------------------------------------------------------------------
At least an order of magnitude improvement over the status quo, but in
the end, not that well. We have the RFCs, but they don't capture the
conversations all that well (although being able to search the archives
by RFC number is _nice_!). And it's tough to find anything you're
looking for without doing a linear scan through the whole 360.
Conclusion: we still need to work on archiving, filtering, and rating. A
link from an RFC to all spawned threads would help. Community ratings of
RFCs on different dimensions would help (eg feasibility,
interestingness, generality). Having working group chairs or some other
independent person/group attach a note to each RFC might help.
Designing Perl6:
---------------
The stated goal, no? I'm not too sure about this one. It's an unfair
test, because it's up to Larry, but I was hoping that some aspects of
the design would emerge from the discussion. Not much did, at least not
the sort I'd notice. I was hoping for at least one Grand Unifying Idea
that would pull together disparate pieces of the language and the whole
Perl experience, making it clear what irregularities to discard and what
things can be thought of and done differently and more easily.
Fun:
---
I didn't think the RFC process was much fun. Too much worry and
indecision over what the final goal was. Too time consuming to come up
with an RFC, point out the flaws in responders' spurious arguments,
update the RFC in response to people pointing out the flaws in mine,
etc. There were many things to balance -- premature detail vs too little
discussion of implementation, theory vs practice, .... And multiple
people complained no matter where you drew the line.
Conclusion: sorry, none.
Reforming the Perl community and processes:
------------------------------------------
Seems like we're doing okay on this one, though I'd like to dissect a
certain gnat's brain to get a better idea. There's clearly a danger of
sliding back into the pit. We do have too much of a committee feel,
namely, in order to change the process you have to both get nearly
everyone to agree and find someone to implement the change (or find time
to do it yourself). But the fundamentals are good: we're mostly on
schedule, we're on budget :-), and the promised features feel like they
make it worthwhile.
OTOH, The current "dead time" isn't a very good idea. "Ladies and
gentlemen, thank you for your input. Now please sit quietly in your
seats for the next twelve hours while Larry prepares your next task."
Conclusion: we should be actively working on reforming the process right
now. Retrospectives like mjd's are useful for starting discussions and
clarifying problems, but we should be more focussed on what to change
and what to do next.
