Adam Turoff wrote:
> 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).
I think that initially this must be the approach, otherwise the
developers are going to be bombarded with patches. For example, a
particular team may put in some less-than optimal code in the interests
of getting something working for others to use, and with the full
intention of replacing it ASAP. The trouble is it will probably be an
inviting target for patching, and everyone's time will be wasted. Once
perl6 is up and running, it may be sensible to relax the boundaries and
revert to something more like the existing perl5 mechanism.
> 2) Set up an explicit path for sometimes contributors to submit
> patches, new code, new docs and new tests.
Explicitness is goodness. It gives visibility to everyone, and helps
trap errors early.
> 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.
Putting code reviews explicitly in the process (for *all* code, not just
that of neophytes) will serve another useful purpose. At the moment in
perl5, there is already a code review process, but it just isn't called
that. The current process by which this is done is the pumpking
deciding which patches will go in and which will be rejected - the code
is reviewed! The problem with this is it all funnels through one poor
victim^W individual, leading inevitably to pumpking burnout. By
distributing the review task to the subteams, hopefully being a pumpking
will now not require the cessation of normal life, and becomes something
that a mere mortal can carry out. The pumpking should of course have
the final say on what goes in, but because the candidate code has been
eyeballed before it gets to him it should be a less onerous task. The
pumpking role should then change to being what it should have been all
along - that of release management.
> 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).
Again, I think this is a good idea. I think completely closed lists are
a bad idea because they will lead to accusations of elitism and
secrecy. Read-only lists will give transparency without the risk of the
lists degenerating into a free for all.
> 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.
Yup.
> 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.
Indeed - I think everyone was astonished by the rate at which they
appeared. I just hope the code is produced at the same prodigious rate
;-) As I said I was becoming increasingly dismayed by the continuing
stream of RFCs, and in the end felt I had to raise the issue. Having
done so I have been very happy to see the wide consensus that seems to
be appearing.
Alan Burlison
