Re: Guidelines for internals proposals and documentation
On Wed, 15 Nov 2000, David Grove wrote: Nat and I argued parts of this (I think this is included) at some length. Actually, I think I drove him crazy getting specifics out of this. [many thoughtful details omitted] All in all, I think Dan's doing a good job making this make sense. I'm just curious about the inner workings of a group. Well, since we don't actually *have* any groups yet, I'm not surprised that the inner workings of groups aren't clearly specified. I think we ought to just improvise as we go along for now. I'd much rather have Dan spend his time and talent trying to specify the api for perl extensions than trying to specify the api for perl development groups. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Critique available
On Thu, 2 Nov 2000, Nathan Torkington wrote: When an article in perl.com is so overwhelmingly negative about the work so far, do you think that stirs confidence in what we're doing? To strive for balance, I think perl.com's home page should also have the links to Larry's ALS talk and slides. I know they are not a polished collection of web pages, but they are still quite readable. They also give a different perspective to the RFC collection. An article emphasizing positive aspects of the process so far would also seem like a nice idea, but somebody'd have to write it :-). -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
RE: Continued RFC process
On Mon, 9 Oct 2000, David Grove wrote: On Monday, October 09, 2000 7:12 PM, Nathan Torkington [SMTP:[EMAIL PROTECTED]] wrote: How about an open, crossplatform mailing list for issues, with a mechanism on perl.org for public voting on larger issues. In a volunteer organization, you can't reliably translate votes on issues into action. To be concrete, consider a perl5 example. Suppose that there was a vote to change from metaconfig to autoconf for perl5. Suppose further that the current Configure maintainer didn't know anything about autoconf and judged himself unable to complete the task in any timely manner. What would happen next? Probably nothing, unless an autoconf champion steped forward and volunteered to take over configuration issues. But in that case, what was the point of the vote? At any time, _anyone_ can step forward and champion a cause. If he or she makes a good case and implements it well[*], then it will probably be adopted. Similar concerns hold for other issues. Without a champion to implement the changes, nothing is likely to happen. With a champion, no vote is needed--the champion can just go ahead and try to do it. There are, of course, cases where things are not clear cut. Suppose, for example, that someone proposes and implements a feature (e.g. safe signals) but it has a drawback (e.g. 10% slowdown). Should that feature be included in perl? That's a tough question involving difficult tradeoffs. It's not at all obvious to me that voting is a better way to resolve such issues than the current process of allowing the pumpkin holder to decide. [*]Of course "implements it well" is a subjective criterion, but one important aspect of it ought to be a reasonable plan for the long term maintenance of the feature (usually the champion saying "I'll do it.") -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
RE: Continued RFC process
On Mon, 9 Oct 2000, Nathan Torkington wrote: Closed-for-posting mailing lists that are publically readable is the best suggestion we've had to meet these ends so far. Anyone have better suggestions? Just that it not be *too* hard to get on the closed lists (and, symmetrically, that it not be *too* hard for the list chair to bounce someone *off* the list if that person is judged to be persistently and seriously damaging to the list). I'm not suggesting anything formal here--in fact I think it's best if we make it up as we go along--just that we record our overall expectation that we're reasonable people trying to balance conflicting needs in a reasonable way. Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
