Re: Roadmap/plan for Perl 5?

I'm just going to blat out a response to all the messages I've read so far,
rather than carefully quoting and composing anything.  If I have missed some
specific point somebody wants addressed, please say so.

perl5 does not have a road map.  While I'm holding the pumpkin, I think it is
*extremely* unlikely that it will.  This is not to say that I think all the
"we should"s in this thread are things we shouldn't.

First, let me say what I mean by "roadmap," so it's clear what I'm saying we
won't have.  A roadmap lists the places that you are going to go, in the order
you are going to go to them, and how you plan to get there.  In software, of
course, we're not traveling.  Instead, the destinations are changes in behavior
or implementation.

I have worked on plenty of software that has a roadmap.  They can be very nice
to have, for a lot of reasons.  Something you need for a roadmap to be useful,
though, is a driver.  Right now, nobody is driving perl5.

What does that mean?  Well, if you have a roadmap, and you're driving, you keep
making sure that you're going the right way.  If someone tries to get you off
track, you decline.  *If nobody else is making the car move, you keep your foot
on the gas.*

In other words, a software project roadmap is useful when the same person or
group is in charge of determining the road map and affecting progress along the
road.  We don't have that.

Instead, we have a flock of programmers, each with their own set of priorities
and interests, each trying to pull the coconut in their own favored direction.
I propose that a roadmap would not help in this situation, and that publishing
one would be, at best, disingenuous.

There's nothing *wrong* with this situation, though.  It just calls for its own
kind of management.  Instead of imagining perl5 moving along some planned-out
road toward a goal, imagine it as a well-established city, being carefully
expanded and rebuilt over time.  The expansion and rebuilding are done by
private citizens' groups, but they have to be of benefit to everyone, so there
is a city planner who weighs these proposed changes in light of the existing
city and of other projects currently underway, previously undertaken, or
concurrently under discussion.  Also, knowing how other cities do stuff helps.

So, if not a road map, what is useful?  What's useful is a list of things that
the city needs, and a list of things that are already understood to be bad
ideas.  With a list of new places to which we'd like to expand, someday, when
possible, we have a different kind of road map.

The "todo" file is something like that, but it's not great.  The plan has been,
for some time, to translate it into RT tickets which are then categorized into
groups using meta tickets.  In other words, you can go look for tickets that
are "TODO" and "requires no C/XS skills."  Or maybe "TODO" and "Win32 API
expertise needed."  Or "TODO" and "Parser" and "OS2."  You get the idea.

In the past, I have occasionally posted things that I personally think would be
very valuable improvements to the system, and written down things that I think
would be the vital behaviors of those improvements.  Sometimes this goes
nowhere (except a list post or todo file) but sometimes there's enough
agreement that we end up with a new feature.  q.v., postfix deref

Other times, the planning needs to be undertaken by others, like fixing our
so-called API.  I'm no position to hand down a plan for that, so it has to be
constructed by the interested parties.  The best thing that can be done here, I
think, is for people to self-organize on projects that they think will be
successful and valuable.  "Fixing docs" is in the same category, along with
tests.

So: I don't see the future as something that we try to lay out in an ordered
plan, nor do I think that's what we can do any time soon.  Instead, I think
what we have been doing, and doing well, is letting people come forward with
suggestions that can then be considered, evaluated, and encouraged or
discouraged for further work.

On the topic of having a firm procedure for how a proposed feature becomes an
applied patch, I've said before and will say again that I do not plan to have a
firm set of rules for this.  You can't evaluate a feature without the patch,
and once you have the patch, you have to evaluate it in ways that can't be
quantified up front.  What we need, instead, is for there to exist a plausible
expectation that both proposals and patches will get quality review done in
good faith.  I think we're starting to get a decent track record in this
regard.  We've gotta keep it up.

Another use case people talk about for a roadmap is that it helps would-be
contributors figure out where to start.  That is (because who doesn't like an
over-extended metaphor?), a roadmap helps people find the on-ramps.  That's
something we want to address some other way, and I think the above two prongs
help:  a categorized list of "things we want to exist," with notes; and a
culture of constructive discussion and code review.

-- 
rjbs