Marco Tabini wrote: > > On 10-Jan-08, at 10:58 AM, Lukas Kahwe Smith wrote: >> I know that PHP has so far stayed clear of processes and I am fine >> with keeping it this way. But I really think that some of these flames >> should best be taken off list into some work group that provides >> summaries at semi regular intervals, so that internals knows whats >> going on and people know if it makes sense for them to join this >> discussion. >> >> Right now people keep posting in threads only because they are afraid >> that silence means approval or because they missed part of the >> discussion or because they have time to kill. > > Not to barge in, but I think the word you're thinking of is > "governance," which unfortunately so many people confuse with > bureaucracy. A good process streamlines without impeding, and personally > I think internals could really use some help in that area.
Hi, As some of you know, I'm way into governance as a means to kill off flames before they start, so I second this motion ;). <ridiculous_dreaming> At the very least, some kind of centralized RFC tracker (like PEAR's PEPr for package proposals) would be a potential way to track features that would introduce slightly more work (another thing to maintain at php.net for web admins) but cut down on duplicate proposals and simplify things socially. Unfortunately, this idea would work best with some kind of patch-based proposal system that can do diffs of patches, so that we can track patches. In other words, it would probably mean using something like git + a basic proposal system that links to it. In other words, we start getting into headache-complicated land. </ridiculous_dreaming> To start simple, what might be a possibility is to simply use a rEST-based file in php-src CVS that contains links to mail archives of proposals and important messages underneath descriptions of feature proposals. This could include rejected features like multiple inheritance and summaries of why they were rejected (again links to mail archives could suffice if there are any), which would cut down significantly on noise. It would also mean that for a feature to get accepted, at least 1 developer with php-src karma would have to take the effort to add it to the feature file, which in my opinion would be a good thing since these folks would be the ones typing "cvs commit" anyways. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
