Re: The Future - grim.
On Thu, 14 Sep 2000, Steve Fink wrote:
Alan Burlison wrote:
Having done so I have been very happy to see the wide consensus
that seems to be appearing.
Huh? I'd say quite the opposite. I expected more. There are many, many
people who use perl. Anybody who uses anything will come up with ways to
improve it (though many improvements aren't.)
{snip}
The noise in discussions is harder. I don't mind it much, though,
since I scan the author names and skip discussions that aren't
inherently interesting and don't contain people I recognize and
respect.
You'd be happier if more people (more unknowns, as it were, as most of
the established community is here already) had more things to say, but
you'll filter out discussions by people you don't recognize?
(I understood your point. This was just an interesting way of
presenting it.)
--
Bryan C. Warnock
([EMAIL PROTECTED])
Re: The Future - grim.
J. David Blackstone writes: Wait. Does a good idea have to go away simply because the person who originally proposed it no longer has interest? What if several people are interested, but the original author has totally skipped out on Perl6 development, and the other interested people don't realize the RFC is about to be discarded? If the author has abandoned it, someone else is welcome to pick it up. Has this situation arisen, or is this a hypothetical? Nat
Re: The Future - grim.
Well, THAT was certainly specific, insightful, politely phrased, and filled with pertinent advice on how to remedy the problem! Alan, you're right about certain things...it's important that talented, experienced people have the final say over the final product. However, most of the problems in every field of human endeavor come down to the fact that there just aren't very many talented, experienced people. What that means is that we take our top people, enshrine them as design gods, approvers of submitted code, and coders of RHP (Really Hard Problems), and then we allow as many enthusiastic people as possible to try to solve the less hard problems...the best of these attempts gets used, the rest get thrown out by the top people. Yes, it's a lot of work for them and no, it's not really what anyone would choose in an ideal world, but it's proven to work...unless, of course, you'd call Linux a "slow motion train wreck." The other reason to do it this way is that if we DON'T let new (== "less experienced") people help out, how are they ever going to get more experienced at the problems that we need solved? And if the pool of available experienced people never grows, how is Perl supposed to survive? Dave (PS: I do not by any stretch of the imagination include myself in the list of "top people.") On Sun, 10 Sep 2000, Alan Burlison wrote: Nathan Torkington wrote: We're lucky to have the experience of Chip to draw upon (he's already blazed some of the trails we'll be turning into fully-paved four-lane highways with Waffle Houses and Conocos), as well as a lot of people who've worked with perl5. They know what works and what doesn't, and experience is going to be invaluable in something as complicated as a Perl interpreter. Unfortunately the greatest volume on the various p6 sublists tends to be coming from the least experienced people. The comments based on common sense and long experience tend to be lost in the hubbub of uninformed noise. In retrospect I think the various sublists should have been moderated and read-only, and have been populated with the handful of people who understand most about a given area - and no, I don't include myself in that list of people, although I would have liked to have listened in. The whole p6 process is more bizarre than bazaar, and I really can't see how on earth a useful product is going to come out of it. Interest and enthusiasm are great attributes, but in the end are no substitute for knowledge and experience. If p6 is to be successful it needs to be carefully designed and meticulously implemented. To do this successfully it will need rigorous selection of the people carrying out the work. This will inevitably mean that some people will be left on the sidelines, and when that happens a lot of the current enthusiasm will I fear turn to bitterness and disillusionment. I feel it is grossly unfair to carry on this pretence of development by brownian motion any longer, and that it is about time that the p6 core developers (you know who you are!) started to be honest about this. A lot of people will inevitably be disappointed when their enthusiastic contributions are discarded, and I have seen absolutely no discussion of the process by which RFCs will be accepted or rejected (and saying 'Larry will do it' isn't good enough). I've seen endless and stultifying discussions of code repository tools, but very little talk of project teams and deliverables. The most difficult part of this process is sorting out the human issues, not the technical issues, but that is the very area that seems to have received least discussion. The body of code that comes out at the end of the process is nothing like as important as the group of people who are responsible for giving birth to it, but at the moment the focus and priorities seem to be completely awry. I'm sure the immediate response to my comments is that I'm being unnecessarily pessimistic, and indeed I hope I am. However, past bitter experience tells me that I'm probably at least partly correct, so please don't discard my comments out of hand. I'm sorry but I really can't stomach watching this slow motion train wreck any longer, so good luck and goodbye. Alan Burlison
Re: The Future - grim.
Nathan Torkington wrote: Thanks for that grim view, Alan. I've been looking around for someone to act as the Devil's Advocate and say what might go wrong, so I was happy to see this. Glad to be of service ;-) I agree that the current brainstorming is chaotic. I feel like that's the nature of the beast, though. I think it's important to separate your criticism of this brainstorming from the actual language design, which hasn't yet been done. Right now we're getting input on what people want. Then magic happens with Larry (I'll get back to that soon). After that we can get down to the details of specifying the language, nailing down the semantics and edge cases. Chaos in the brainstorming phase won't necessarily (and please dear God don't let it) be reflected in chaos in the specifications phase. 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. In the end someone is going to have to say 'No, it is not going in, now shut up.', Beware, at that point I see portents of doom and despair Your suggestion was to have moderated lists with a few people on each list. That's more appropriate for the specifications phase and architecture and software design phase, I think. I can't imagine anything being done if the same free-for-all happened then as is happening now. Agreed. I've been thinking that getting the approach roughed out takes precedence over picking teams. You wouldn't know what you were being picked for, for a start. There's definitely an art in deciding who should work on what. If you have advice and suggestions, give 'em up, baby! I wish I had some glib advice to offer, but I don't. You have an especially difficult task due to the geograpical distribution of the likely team members, although this isn't in itself unsurmountable. 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. I like the "risks" formulation of these concerns. Each risk is a potential derailment of our train. So we need to list the risks and make sure we're addressing them: Risk: That nothing good will come of the brainstorming process because good comments from people with experience are being lost in the flood of messages. 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? Risk: That not being selected for a team will offend developers, causing them to leave. What we're doing about that: * identifying tasks (e.g., filling in specifications and test cases?) can be done by as many who want * ensuring the development process is open, so that everyone knows in advance how it will work and nobody feels like it's an arbitrary "management" (ha!) decision. Please make strenuous efforts to lay out the ground rules as soon as possible. [this risk won't kill the project, though, merely hurt peoples' feelings] It'll kill it if you hurt enough peoples feelings... Alan Burlison
Re: The Future - grim.
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.
