Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:34665
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 38.99.98.18 cause and error)
Message-ID: <478698D6.2070005@chiaraquartet.net>
Date: Thu, 10 Jan 2008 16:14:46 -0600
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Marco Tabini <marcot@tabini.ca>
CC: Lukas Kahwe Smith <mls@pooteeweet.org>, 
 Ilia Alshanetsky <ilia@prohost.org>,
 Derick Rethans <derick@php.net>, 
 internals Mailing List <internals@lists.php.net>
References: <47618179.2080709@chiaraquartet.net> <alpine.DEB.0.98.0801101632190.4679@kossu.ez.no> <1840D9AD-4FB0-4A2D-8F25-BBD746649EFD@prohost.org> <2B0AC2C1-B41E-4644-A820-946FDF0322DC@pooteeweet.org> <FB8B3A96-8CED-49DC-893E-CBB4AB755619@tabini.ca>
In-Reply-To: <FB8B3A96-8CED-49DC-893E-CBB4AB755619@tabini.ca>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] no read-only, no moderation, just a simple self-enforced
 checklist
From: greg@chiaraquartet.net (Gregory Beaver)

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