On Wed, Oct 04, 2000 at 03:42:57PM -0500, Jarkko Hietaniemi wrote:
> > Any others? There are bugs in the RFC process. Now is the time to
> > fix them.
>
> I don't know whether this is worth a separate improvement # but here goes:
>
> Too many RFCs live in a vacuum by not not explaining in enough detail
> what is the problem they are trying to solve,
RFC Improvement #6: Every RFC must contain a brief background describing
the problem in enough detail for readers to understand
what this RFC proposes to solve. Conciseness is
preferred. Links to extended discussions are
appreciated.
> but instead go ahead and
> pull new/backward-incompatible syntax and/or keywords and/or semantics
> out of thin air.
I hope we're done the first phase of RFC submissions, that aspect
of RFC submissions should be behind us.
> Call me an old curmudgeon
Jarkko, you're an old curmudgeon.
> but some
> words towards backward compatibility, keeping proposed changes as
> small and generic as possible (I think that's one of things that
> epitomises perl: lots of cleverly interlocking small features or
> feature sets) would have been nice before the launch of the RFC process.
RFC Improvement #7: Every RFC must contain a discussion of migration
and backwards compatibility, as appropriate.
This includes non-internals areas such as
licensing. New areas of effort may be excluded[*].
Keeping RFCs current is another bug in the process. Here's a possible fix:
RFC Improvement #8: RFCs are patchable. This is to encourage RFCs to
be kept up to date with a synopsis of discussion
about a proposal, especially when the maintainer
is too busy to keep updating an RFC. Process TBD.
Z.
*: OK, so we're losing formats, but Damian shouldn't need to write a
backwards compatibility dissertation for each and every new extension
to formats he comes up with (even though he could).
Ditto on 'use Notation::Polish::Reverse;'
