Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:34005
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 72.14.202.183 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Tyrh9gHewYlqdLx533uoFc0RsCowbEX3kSvoQVqZEpqUBSqU23LqzFnzrrowwbVwPh9ep+SjvPwJcajUsGlAP/H7kzPoVx3NDYdzKY0bLmlYnLre8A2OXW4Gm/iDRKr7rAXUjC6SIQd/MB1SbsHY4gb0nTEgukifwCuMGcSMso8=
Message-ID: <ab5568160712130709sfd9a7eeof7de89875fa24960@mail.gmail.com>
Date: Thu, 13 Dec 2007 10:09:23 -0500
To: "Andrew Rose" <rose.andrew@gmail.com>
Cc: "internals Mailing List" <internals@lists.php.net>
In-Reply-To: <f90bafdd0712130656me9f1daah928f064a54bcaa76@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <475F1984.603@chiaraquartet.net>
	 <1197450581.27917.2.camel@localhost.localdomain>
	 <4760227D.9050404@zend.com>
	 <alpine.DEB.0.98.0712130952470.27826@kossu.ez.no>
	 <1197551283.27917.9.camel@localhost.localdomain>
	 <47613538.1060308@wikimedia.org>
	 <1197553571.27917.12.camel@localhost.localdomain>
	 <47613EEE.5090305@richgray.com>
	 <f90bafdd0712130656me9f1daah928f064a54bcaa76@mail.gmail.com>
Subject: Re: [PHP-DEV] Internals read-only
From: parasane@gmail.com ("Daniel Brown")

    I would say, if anything, there are two viable choices that
wouldn't adversely affect the PHP project:

    1.) Have the Internals list read-only by all but (a)
developers/contributors and (b) people granted permission after having
posted useful information via the General list.

    2.) Probably a better idea, just click that DELETE button on any
emails you don't feel like reading or responding to.  I find that, in
a case study performed by myself just now, it takes me about a
half-second to achieve success with this method.

    By silencing the masses, you offer them little choice but to find
an alternative solution.  By closing out the discussions, even just
that much, you're turning PHP from a completely open source project,
in which all can participate and help mold the future of the language,
into a partially open source language.  Yes, the source code itself,
as created by the core developers, will still be available to the
public at large.... but any discussion on implementation of new ideas
could only really be achieved through a fork of the project.  Further,
how would you encourage new developers to join on if they couldn't
interact with - and get a feel for - those who actively post on this
list as it is?  By only allowing them to read the threads posted,
without the ability to ask questions, it's like reading a manual.  And
how often does the discussion in a published book evolve without
requiring a full reprint?

-- 
Daniel P. Brown
[Phone Numbers Go Here!]
[They're Hidden From View!]

If at first you don't succeed, stick to what you know best so that you
can make enough money to pay someone else to do it for you.