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

How to move forward (was: Why we're here)

Thread Next
From:
Tim Bunce
Date:
July 24, 2000 12:45
Subject:
How to move forward (was: Why we're here)
Message ID:
20000724203906.C23550@ig.co.uk
On Mon, Jul 24, 2000 at 12:04:43PM -0600, Nathan Torkington wrote:
> 
> First thing first, I think.  I want to know how we tackle this rethink
> of Perl, where there will inevitably be great changes suggested, in
> such a way that we don't end up bickering and fighting and not making
> progress.

I suggest the following process:

1/ One or more people ("the editors") volunteer to collect suggestions
from others about what problems they believe the perl language has
*currently*.  *Without* any proposals for how to fix them. *Without* any
suggestions for new features. Just list them. Perhaps a title and one
paragraph max of description on each.

[ Here's one example that came up in the CPAN discussions:
  The inability to have multiple versions of a module installed and/or
  multiple implementations of the same interface (eg pure perl and XS). ]

2/ That person could then consolidate all the inputs. Merging all the
similar sections and producing a short summary of all the descriptions.

That simple process would lead to a very valuable list of issues.
This list can be taken further:

3/ We talk over each issue in turn. To keep it productive I'd suggest
posting a few every two days and limiting discussion to those two days.
Note that the only topic for discussion is *clarification* of the issue.
No talk of priority or solutions at this stage. Keep it short and simple.

4/ The editor(s) incorporate any valuable clarification of the issues.

So, now we've polished it up we need to prioritise it.

For this I'd suggest a web based voting scheme.  Something like giving
everyone N points to distribute among the issues, giving more points to
the higher priorities. Some people may put all N points on one issue
and others will distribute their points more widely.

They'll need to be some way to prevent multiple voting. One suggestion
off the top of my head would be to take the union of the p5p mailing
list and PAUSE ids so only people on p5p and/or PAUSE authors can vote.
That's probably reasonable since all we're doing is prioritizing issues
and I think the number of people voting would be sufficient to be
reasonably representative.

Now, at the end of that process we'd have a prioritized list of issues
with the perl5 language. That would be a very valuable resource.
I'm sure Larry would find such a community-prioritized list very useful.

Where to go from there? RFP's could be requested for proposed solutions
to the issues.  (Remember that the issues at this stage still only have
a title and a couple of paragraphs of description.)

A similar parallel process could be initiated for *new* features.
That track could be kept seperate till the RFP stage (since it's
likely that some new features would be addressing existing issues).
The ongoing process on one track will probably usefully influence
the other.

Tim.

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About