Everything

php

no read-only, no moderation, just a simple self-enforced checklist

php.internals

Greg Beaver

18 years ago

Hi,

We don't need moderation, we don't need read-only.  We need people to
follow a simple common-sense checklist.  Before sending a message to
php-internals, ask these questions of yourself:

1) am I angry? yes => do not send your message, do not pass go, do not
collect $200.  Wait until tomorrow.
2) do I need help developing C code for the core, understanding how to
track down a bug, reminding about a forgotten/ignored bug, or writing
tests? yes => send your message and be graceful, no => goto #3
3) do I know what I'm talking about?  no => do more research and write
later, yes => goto #4
4) why should my opinion matter to anyone else? not sure => investigate
other people's opinions on the matter, potentially off-list or on irc
for new perspectives first, sure => goto #5
5) for new features, do I have a patch? yes => send message, no => goto #6
6) do I have a specific suggestion for changing the conception of how a
feature is implemented? yes => goto #7, no => delete your message and do
more research
7) have I made it this far? yes => send your message :)

A monthly auto-mailing of this checklist to internals@ for newbies would
also be a good way to remind us old farts to be decent citizens.  PHP
could also use a clearly defined leader who can shut down acidic debate
or a flame war before it gets out of hand, the RM for the
soon-to-be-released version might be a good candidate since most
discussion should (in theory) be about that code.

Greg

Derick Rethans

18 years ago

On Thu, 13 Dec 2007, Gregory Beaver wrote:

> We don't need moderation, we don't need read-only.  We need people to
> follow a simple common-sense checklist.

It's either that nobody saw this mail, or chose to ignore it. Obviously,
nothing changed and I'm getting sick and tired of all this crap on
internals, so here once more:

> Before sending a message to
> php-internals, ask these questions of yourself:
>
> 1) am I angry? yes => do not send your message, do not pass go, do not
> collect $200.  Wait until tomorrow.
> 2) do I need help developing C code for the core, understanding how to
> track down a bug, reminding about a forgotten/ignored bug, or writing
> tests? yes => send your message and be graceful, no => goto #3
> 3) do I know what I'm talking about?  no => do more research and write
> later, yes => goto #4
> 4) why should my opinion matter to anyone else? not sure => investigate
> other people's opinions on the matter, potentially off-list or on irc
> for new perspectives first, sure => goto #5
> 5) for new features, do I have a patch? yes => send message, no => goto #6
> 6) do I have a specific suggestion for changing the conception of how a
> feature is implemented? yes => goto #7, no => delete your message and do
> more research
> 7) have I made it this far? yes => send your message :)
>
> A monthly auto-mailing of this checklist to internals@ for newbies would
> also be a good way to remind us old farts to be decent citizens.  PHP
> could also use a clearly defined leader who can shut down acidic debate
> or a flame war before it gets out of hand, the RM for the
> soon-to-be-released version might be a good candidate since most
> discussion should (in theory) be about that code.
>
> Greg
>
>

--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org

Ilia A.

18 years ago

On 10-Jan-08, at 10:33 AM, Derick Rethans wrote:

> On Thu, 13 Dec 2007, Gregory Beaver wrote:
>
>> We don't need moderation, we don't need read-only.  We need people to
>> follow a simple common-sense checklist.
>
> It's either that nobody saw this mail, or chose to ignore it.
> Obviously,
> nothing changed and I'm getting sick and tired of all this crap on
> internals, so here once more:

+1

Lately the internals list has been a complete waste of time, with
little actually getting accomplished from endless discussions.

Ilia Alshanetsky

Lukas Kahwe Smith

18 years ago

On Jan 10, 2008, at 4:51 PM, Ilia Alshanetsky wrote:

>
> On 10-Jan-08, at 10:33 AM, Derick Rethans wrote:
>
>> On Thu, 13 Dec 2007, Gregory Beaver wrote:
>>
>>> We don't need moderation, we don't need read-only.  We need people
>>> to
>>> follow a simple common-sense checklist.
>>
>> It's either that nobody saw this mail, or chose to ignore it.
>> Obviously,
>> nothing changed and I'm getting sick and tired of all this crap on
>> internals, so here once more:
>
>
> +1
>
> Lately the internals list has been a complete waste of time, with
> little actually getting accomplished from endless discussions.

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.

regards,
Lukas

Marco Tabini

18 years ago

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.


Mt.

Greg Beaver

18 years ago

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

Jon Parise

18 years ago

On Thu, Jan 10, 2008 at 04:14:46PM -0600, Gregory Beaver wrote:

> 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.

My preference would be something more akin to Python's PEPs:

http://www.python.org/dev/peps/

PEP 1 is an overview of the system:

http://www.python.org/dev/peps/pep-0001/

--
Jon Parise (jon of php.net) :: The PHP Project (http://www.php.net/)

Stanislav Malyshev

18 years ago

> 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

Maybe just for the start create a wiki or something that people could
put their RFCs to and edit them, and then hopefully somebody would step
up to manage that wiki, etc.? You can also attach files to wiki, so it
might work.

--
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com

Lukas Kahwe Smith

18 years ago

On Jan 11, 2008, at 12:43 AM, Stanislav Malyshev wrote:

>> 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
>
> Maybe just for the start create a wiki or something that people
> could put their RFCs to and edit them, and then hopefully somebody
> would step up to manage that wiki, etc.? You can also attach files
> to wiki, so it might work.

I also doubt that we will adopt some other organizations governance
toolchain. However to me the main issue ia that we have a lot of
proposals, a lot of new guys (some of them are also involved in core
development, others are just lurkers turned posters) and our
discussion style does not seem to scale. Instead we are stuck in a
vicious circle that seems to cause even more posts with even less
content, which invites even more lurkers to turn posters (not that
participation is a bad thing in general, but it seems our new relevant
content per post ratio is going down hill insanely fast).

With that in mind I would appreciate 3 things:

1) Find a system that encourages thoughtful content addition over
diatribes
2) A way to summarize the issue at hand and key opinions
3) Some way to register votes so that the votes can be associated to
php.net karma

As such I think the idea of having someone write up a summary of the
initial proposal in a wiki is not too much to ask. This wiki page
should then be updated with information as the discussion progresses.
Ideally by the original author, others should get the opportunity to
add comments, which should then get folded into the main text. People
posting on the relevant threads are expected to keep themselves
uptodate as to whats written on the wiki so that they can complain if
the summary is wrong and so that they also refrain from reposting
already discussed points. So this covers 2) fairly well.

For 1) I think it comes down to discipline. People that do not follow
the process described in the previous paragraph should just get their
fingers slapped. Ideally off list. If we stick to this process,
newbies will soon learn how the list works and we will turn around
this vicious circle.

Finally for 3) it would be nice if the final votes get dumped on the
wiki, although an email based interface would probably be necessary to
make the likes of Rasmus happy. Obviously end user opinion counts to
the development of PHP, but in the end its the core developers that
will write and maintain the code. As the numbers of core developers is
growing (or just shifting to new names/faces), it becomes increasingly
hard to keep track of who is actually a core developer and who isnt.
If the votes go through some kind of system, such meta information
could easily be added to the votes.

Such a process is still very lightweight, leaves a lot of room for
flexibility and might still go a long way. The dangerous aspect is
that it somewhat relies on discipline (without discipline you sort of
forgo the chance at flexibility if you want to stay productive).

regards,
Lukas

Antony Dovgal

18 years ago

On 10.01.2008 18:33, Derick Rethans wrote:

> On Thu, 13 Dec 2007, Gregory Beaver wrote:
>
>> We don't need moderation, we don't need read-only.  We need people to
>> follow a simple common-sense checklist.
>
> It's either that nobody saw this mail, or chose to ignore it. Obviously,
> nothing changed and I'm getting sick and tired of all this crap on
> internals, so here once more:

We need to put this checklist somewhere and point to it each time the list starts to overfill again.
http://www.php.net/reST/ seems to be the best place for it.

--
Wbr,
Antony Dovgal

Lukas Kahwe Smith

18 years ago

On Jan 10, 2008, at 4:55 PM, Antony Dovgal wrote:

> On 10.01.2008 18:33, Derick Rethans wrote:
>> On Thu, 13 Dec 2007, Gregory Beaver wrote:
>>
>>> We don't need moderation, we don't need read-only.  We need people
>>> to
>>> follow a simple common-sense checklist.
>>
>> It's either that nobody saw this mail, or chose to ignore it.
>> Obviously,
>> nothing changed and I'm getting sick and tired of all this crap on
>> internals, so here once more:
>
> We need to put this checklist somewhere and point to it each time
> the list starts to overfill again.
> http://www.php.net/reST/ seems to be the best place for it.

I will put something there soon, loosely based on Greg's post. I will
likely ask for some quick feedback in #php.pecl and of course it can
be tweaked further later ..

regards,
Lukas