On Sun, Sep 10, 2000 at 09:58:14PM +0100, Alan Burlison wrote:
> I don't believe in magic. I'm an engineer by profession, not an
> astrologer. However, I will predict endless arguments when some of the
> less than coherent proposals are rejected.
The RFC process was intended to bring out both good and bad suggestions.
On the positive side, there's interest in currying. On the negative
side, we have some half baked proposals, some of which frequently appear
on p5p every year or so. At least with an RFC archive, those fruitless
flame wars can be stopped quickly by citing a relevant rejected RFC than
they are today by saying "go look in the mailing list archives."
> [...] I
> suggest you do the blindingly obvious - look at the current p5p'ers,
> figure out who has contributed in each area of interest and ask those
> folks to form a team to work on the same area in p6. If new people want
> to contribute, fine, but they should be integrated into an existing team
> rather than be sent off to 'do their own thing'. A possible suggestion
> is an apprenticeship approach - ask potential contributers to take on a
> substantial but not critical-path part of the work, get them to complete
> it and then have it reviewed by the other members of the team (you are
> going to code reviews - right?) If everyone is happy then they can be
> invited in.
>From this, I can extract these action items:
1) Set up p6 development like other open source projects, where there
is a "core team" responsible for the progress of Perl6 or a component
of Perl6. These people have write access to the source repository
(whatever it may be).
2) Set up an explicit path for sometimes contributors to submit
patches, new code, new docs and new tests.
3) Set up an explicit path for apprenticeship. This should lead to
membership in the core team for trusted apprentices who have proven
themselves as being capable and reliable. Code/doc reviews
are one metric for proving oneself to the core team.
4) Set up closed mailing lists for the core team to post onto, that
are made available through read-only open subscription to the
community at large. These lists should have a policy established
to accept worthwhile postings from non-core members (simple
forwarding works; moderation works).
> > What we're doing about that:
> > * pushing the output through Larry
> > [Yes, this addresses only part of the problem. Any suggestions for
> > other ways to solve this?]
>
> The RFC mountain is way, way too high to be climbed by just one person,
> let alone the output of the various mailing lists. What about a litlle
> good old-fashioned dictatorship, or at least a Junta?
All of the RFCs have mailing lists associated with them, and all of
the mailing lists have chairpeople leading discussion.
Why not ask these chairpeople to start a Last Call process, whereby
any unmaintained RFCs can be marked as "unmaintained and withdrawn"
by the relevant WGC. That should cull out a bunch that haven't been
updated since being posted one month ago. Especially the dubious ones.
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.
Z.
