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

- Thread: https://externals.io/message/34026
- Original archive: https://news-web.php.net/php.internals/34026
- Started by Gregory Beaver on 2007-12-13T19:01:13+00:00
- Messages: 11
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #34026 — Gregory Beaver — 2007-12-13T19:01:13+00:00

URL: https://externals.io/message/34026#34026

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

---

## #34651 — Derick Rethans — 2008-01-10T15:33:08+00:00

URL: https://externals.io/message/34026#34651 · In reply to: #34026

> 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

---

## #34652 — Ilia Alshanetsky — 2008-01-10T15:51:23+00:00

URL: https://externals.io/message/34026#34652 · In reply to: #34651

> 
>
> > […]
>
> 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

---

## #34653 — Antony Dovgal — 2008-01-10T15:55:04+00:00

URL: https://externals.io/message/34026#34653 · In reply to: #34651

> 
> 
> > […]
> 
> 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

---

## #34654 — Lukas Kahwe Smith — 2008-01-10T15:58:23+00:00

URL: https://externals.io/message/34026#34654 · In reply to: #34652

>
> 
>
> > […]
>
>
> +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

---

## #34655 — Marco Tabini — 2008-01-10T16:02:59+00:00

URL: https://externals.io/message/34026#34655 · In reply to: #34654

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

---

## #34663 — Lukas Kahwe Smith — 2008-01-10T19:57:59+00:00

URL: https://externals.io/message/34026#34663 · In reply to: #34653

> 
> > […]
>
> 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

---

## #34665 — Gregory Beaver — 2008-01-10T22:14:46+00:00

URL: https://externals.io/message/34026#34665 · In reply to: #34655

Marco Tabini wrote:
> 
> 
> > […]
> 
> 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

---

## #34666 — Jon Parise — 2008-01-10T22:43:41+00:00

URL: https://externals.io/message/34026#34666 · In reply to: #34665

> 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/)

---

## #34669 — Stanislav Malyshev — 2008-01-10T23:43:18+00:00

URL: https://externals.io/message/34026#34669 · In reply to: #34665

> 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

---

## #34685 — Lukas Kahwe Smith — 2008-01-11T08:40:25+00:00

URL: https://externals.io/message/34026#34685 · In reply to: #34669

> > […]
>
> 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