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:
- am I angry? yes => do not send your message, do not pass go, do not
collect $200. Wait until tomorrow. - 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 - do I know what I'm talking about? no => do more research and write
later, yes => goto #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 - for new features, do I have a patch? yes => send message, no => goto #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 - 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
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:
- am I angry? yes => do not send your message, do not pass go, do not
collect $200. Wait until tomorrow.- 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- do I know what I'm talking about? no => do more research and write
later, yes => goto #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- for new features, do I have a patch? yes => send message, no => goto #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- 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
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
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
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.
Marco Tabini 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
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/)
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
At the very least, some kind of centralized RFC tracker (like PEAR's
PEPr for package proposals) would be a potential way to track
featuresMaybe 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:
- Find a system that encourages thoughtful content addition over
diatribes - A way to summarize the issue at hand and key opinions
- 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
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
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