Voting Process (was: Re: Voting does not belong on the wiki! (Was: 5.4 moving forward))

14 years ago by Zeev Suraski — view source

unread

Pierre,

I'm happy that we agree pretty much completely about the clarifications & updates needed for the RFC.

I do however want to point out that the problematic way the short array syntax RFC was executed was the key reason that made me feel these updates were in fact necessary - I don't think that the way it was done was exemplary in any way...

Pretty much each and every point in my email is based on things that I felt went wrong with how we handled the short array syntax RFC:

There wasn't sufficient time, or nearly any time at all - between when Brian pulled it off the attic, and when a vote was called. If my proposal is accepted, there'll have to be at least two weeks between when a clearly marked [RFC] email hits internals@, and when a vote is called.
There wasn't a clearly marked, separate [VOTE] email.
There wasn't a clear or easy way of voting.
No voting period was announced, instead, people were told to stop mess around and go vote.
The author of the RFC wasn't actively involved in the whole process (as far as I could tell); There was no official replacement proposer.

I just want to make sure we're on the same page. If you feel that the array syntax RFC was 'done right' then we have a bit of a gap :) In my opinion, given the lacking process, the short array syntax RFC needs to be redone.

I'd still like to hear from others what they think about my proposal. I'd like to update the Release Process RFC with these suggestions if people like them.

Zeev

14 years ago by Zeev Suraski — view source

unread

For those of you who lost these proposals in the flood of RFC related emails of recent days, here they are again:

First, we need to make sure that the RFC is properly evaluated by the members of internals@, and that there's enough time for the RFC to be discussed here on the list. As Philip pointed out - an RFC is request for comments, not a request for a vote. This list isn't supposed to become some sort of a bureaucratic voting body, but where new ideas are discussed, refined, and eventually - accepted or rejected. I realize that some here are worried that discussions can be endless, but we shouldn't go for the other extreme of having no discussion.
For this reason, I propose the following:

There'd be a minimum amount of time between when an RFC is brought up on this list and when it's voted on (say 2wks). The effective date will not be when the RFC was published on wiki.php.net/rfc - but when it was announced on internals@, by the author, with the intention of voting on it. It doesn't matter if the RFC was up there for 2yrs, or discussed 20 times in the past - if the intention is to go for a vote, there needs to be time for a healthy discussion, as opposed to just yes/no. This will also allow for people who are attending conferences, are on vacations, etc. - not to miss an entire discussion/vote.
The announcement will be done in a way that's easy to flag & follow, e.g. - by [RFC] in the subject line followed by the title of the RFC. Again, the effective date will start from the time this email is sent to the list, not any other time.
Eventually, it'll be up to the author to move ahead and call a vote on the RFC. That means that if the author feels that there's still healthy discussion going on, he can decide not to move ahead to request a vote after 2wks, but after 3 or 4wks. On the other hand, if he feels that the discussion is being derailed - he can always move ahead to a vote as long as the minimum discussion time elapsed.
In my opinion, only RFCs with active proposers should be discussed. If the proposer of an RFC is no longer leading the effort to get this RFC accepted - it should either find a new proposer, or it should be abandoned.

Secondly - the announcement of the vote - I very much agree with Derick that having someone announce a vote in a thread of 50 messages (or even 10) messages is impractical. It needs to be a separate thread, and it has to be clearly marked - a simple subject prefix like [VOTE] followed by the title of the RFC should do.

Thirdly, there's the voting mechanism itself. The voting experience has to be nicer than editing a wiki page, I think we all agree about that... The plugin Stas installed gets us something better than that, but ideally, if we could provide single-click URLs in the [VOTE] email itself for voting yay or nay that would be great.

Last, we need a predefined time for voting. It too has to be sufficiently long so that everyone has a chance to cast their votes, and on the other end shouldn't be endless. I think the 1wk should do.

If there's anybody who feels that the minimum 3wks period is too slow, it isn't. Any mistake we make can take a decade to fix, because downwards compatibility is such an important factor in PHP's design goals. Taking a bit of time to discuss the merits and contents of each RFC is well worth it, especially if we have rules and predefined schedules - so that discussions can't drag forever.

Zeev

14 years ago by Stas Malyshev — view source

unread

Hi!

I'd still like to hear from others what they think about my proposal.
I'd like to update the Release Process RFC with these suggestions if
people like them.

I think these voting process additions totally make sense. But I am not
sure it makes sense to put everything in one release RFC. The reason for
that is that we don't want to endlessly amend and improve the RFC
without having it actually agreed upon, I would rather prefer to agree
on what we agree, have it as base for the future and then add other
stuff. I've noticed a tendency on the list to lose the major goal behind
endless amendments and tweaks and not doing what we agree on because we
disagree on some minor detail. So maybe it would make sense to have
release RFC separate (without spelling out the voting process there) and
voting RFC separate which would define the voting process?

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

14 years ago by Zeev Suraski — view source

unread

I'm fine if the entire 'Feature selection and development' part goes out of the RFC, but if there's any reference to how features are determined, we'd better get it right.
Making changes once we've approved this RFC is going to be much tougher. This is big stuff - it's no coincidence we didn't have such guidelines for almost 15 years.

Honestly there are other parts about the voting process that are much hotter potatoes than the points I brought up - such as who gets to vote, is 50%+1 enough or do we need stronger majorities for substantial language changes (67%/75%), can someone who failed passing an RFC just put it up for another vote right away or is there some sort of a cool-off period, etc. etc. I think all of these need to be answered before we let this RFC govern how we do feature definition.

Zeev

-----Original Message-----
From: Stas Malyshev [mailto:smalyshev@sugarcrm.com]
Sent: Sunday, June 05, 2011 11:17 PM
To: Zeev Suraski
Cc: Pierre Joye; PHP Internals
Subject: Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on
the wiki! (Was: [PHP-DEV] 5.4 moving forward))

Hi!

I'd still like to hear from others what they think about my proposal.
I'd like to update the Release Process RFC with these suggestions if
people like them.

I think these voting process additions totally make sense. But I am not sure it
makes sense to put everything in one release RFC. The reason for that is that
we don't want to endlessly amend and improve the RFC without having it
actually agreed upon, I would rather prefer to agree on what we agree, have
it as base for the future and then add other stuff. I've noticed a tendency on
the list to lose the major goal behind endless amendments and tweaks and not
doing what we agree on because we disagree on some minor detail. So maybe
it would make sense to have release RFC separate (without spelling out the
voting process there) and voting RFC separate which would define the voting
process?

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

14 years ago by Stas Malyshev — view source

unread

Hi!

Honestly there are other parts about the voting process that are much
hotter potatoes than the points I brought up - such as who gets to
vote, is 50%+1 enough or do we need stronger majorities for
substantial language changes (67%/75%), can someone who failed
passing an RFC just put it up for another vote right away or is there
some sort of a cool-off period, etc. etc. I think all of these need
to be answered before we let this RFC govern how we do feature
definition.

I think we shouldn't over-formalize this. Certainly if about 50% of
voters are against something, it does not have consensus. But I do not
think specifying hard percentages would do us much good, especially if
we do it without considering case in point. Some things are OK to decide
on simple majority (like things that have two equally good options and
we have to choose one, or things that are matters of taste/style, etc.),
some may require more strong consensus, especially big changes, but I'd
have very hard time formalizing this upfront.

Currently the "Feature selection and development" basically says "we'd
have a public vote on features". It doesn't specify how exactly is the
process for a vote, and while again I think your proposal is good, I
don't see why it has to be part of this RFC - e.g., if we agree that we
have to have RFCs and formal non-ML public vote, let's fix that and then
talk about how exactly we do the vote. The RFC itself says nothing of
"how", so I don't see why we should mix the question of "should we do
it" with "let's decide how exactly we going to do it".

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

14 years ago by Zeev Suraski — view source

unread

Currently the "Feature selection and development" basically says "we'd have
a public vote on features". It doesn't specify how exactly is the process for a
vote, and while again I think your proposal is good, I don't see why it has to be
part of this RFC - e.g., if we agree that we have to have RFCs and formal non-
ML public vote, let's fix that and then talk about how exactly we do the vote.
The RFC itself says nothing of "how", so I don't see why we should mix the
question of "should we do it" with "let's decide how exactly we going to do it".

I can't really agree here. Just watch what happened last week, when we moved ahead to a vote - the whole thing was IMHO rushed and messy. That's exactly why I don't think we can leave the details out.

The way I see it, we can't employ the voting part of this RFC unless we can agree on rules on how this voting works; It's fine that we don't decide exactly how we're going to do it. But then, it means that we don't get to do it until we do decide.

What makes the most sense to me is to separate the decision making process into another RFC altogether. If people feel it's premature to discuss that process - that's fine, but I don't think we can hold the stick at both ends, and start using a voting mechanism before we even agreed on the basics of voting in the first place.

Zeev

14 years ago by Stas Malyshev — view source

unread

Hi!

The way I see it, we can't employ the voting part of this RFC unless
we can agree on rules on how this voting works; It's fine that we
don't decide exactly how we're going to do it. But then, it means
that we don't get to do it until we do decide.

Well, we'd have to vote somehow, e.g. on RFC itself :) I agree that
before that (and including array syntax) votes were kind of haphazard
and we need to do better. So let's have the voting process RFC. I took
the liberty of capturing your email, with minimal edits, here:
https://wiki.php.net/rfc/voting - please edit/rewrite as you wish. I did
not add anything about percentages etc. there as I have no idea how we
could formalize it :)

What makes the most sense to me is to separate the decision making
process into another RFC altogether. If people feel it's premature

I don't think it's premature, quite the opposite. I just think we need
to have agreement of release process in general (so we could start with
the actual release process) and then work out details as they come up.
The first of those would be the voting RFC.
I'm just afraid substantial changes in the release RFC mean we need to
have new discussion about it and take more time to do it, and in the
meantime we have nothing at all, so we have to either start the release
process without anything at all or delay it until we figure out every
last fine detail. I'd rather have general principles down and when we
get to the fine details we'd deal with them.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

14 years ago by Pierre Joye — view source

unread

The way I see it, we can't employ the voting part of this RFC unless
we can agree on rules on how this voting works; It's fine that we
don't decide exactly how we're going to do it. But then, it means
that we don't get to do it until we do decide.

Well, we'd have to vote somehow, e.g. on RFC itself :) I agree that before
that (and including array syntax) votes were kind of haphazard and we need
to do better. So let's have the voting process RFC. I took the liberty of
capturing your email, with minimal edits, here:
https://wiki.php.net/rfc/voting - please edit/rewrite as you wish. I did not
add anything about percentages etc. there as I have no idea how we could
formalize it :)

I will add a reference to it in the Relase Process RFC as they are
complementary and must be resolved/adopted at the same time and before
we go with 5.4

What makes the most sense to me is to separate the decision making
process into another RFC altogether. If people feel it's premature

I don't think it's premature, quite the opposite. I just think we need to
have agreement of release process in general (so we could start with the
actual release process) and then work out details as they come up. The first
of those would be the voting RFC.

Actually I think Zeev has a good point on the voting, it has been
hurting us for too long already. I do think that waiting that these
RFCs (voting and then release process) are adopted is a must, before
any kind of new releases. Not doing that will open the pandaro box
again, think of the dead cows like 6, or the endless release phase of
5.3.

I'm just afraid substantial changes in the release RFC mean we need to have
new discussion about it and take more time to do it, and in the meantime we
have nothing at all, so we have to either start the release process without
anything at all or delay it until we figure out every last fine detail. I'd
rather have general principles down and when we get to the fine details we'd
deal with them.

I think we have a consensus on this rfc already. Except the voting
process everything has been approved by most if not all active
developers already (see the proposer, for the other readers). By the
way, I'm not saying we don't need a vote, only that we are closed to
get it approved globally.

So if we need to wait one or two weeks more to sort them out, then let
do it. It will be a giant step forward and spare us many of the
painful moments we had in the past, way too often.

That being said, it is not a waste of time anyway. The discussions
about what should be in 5.4 (especially the recently proposed
features) will take a couple of weeks as well, so we can already say
that we are already in the 5.4 phase. But we did not and can't yet
begin with a 1st release, without having defined what will be in.

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

14 years ago by Pierre Joye — view source

unread

I'm fine if the entire 'Feature selection and development' part goes out of the RFC, but if there's any reference to how features are determined, we'd better get it right.

Getting it totally out makes little sense as it brings us to the point
where we have no idea how we decide what gets in or not, the RMs, etc.

Making changes once we've approved this RFC is going to be much tougher. This is big stuff - it's no coincidence we didn't have such guidelines for almost 15 years.

That was not the reason, the lack of will to define such processes was
the reason despite the numerous requests to have one from in and
outside the core team.

Honestly there are other parts about the voting process that are much hotter potatoes than the points I brought up - such as who gets to vote, is 50%+1 enough or do we need stronger majorities for substantial language changes (67%/75%), can someone who failed passing an RFC just put it up for another vote right away or is there some sort of a cool-off period, etc. etc. I think all of these need to be answered before we let this RFC govern how we do feature definition.

I'd to go with a 60% for language syntax, 50+1 for new exts or sapis.
Other question is who can vote. For one, I like to have external
people being able to vote, like frameworks/apps lead developers as
well as @php.net in general (docs people at the same level than core
devs, no diff).

However I'd to say as well as I have no issue at all to define the
basis of the voting system in it and add a note that it may be tuned
later once we have more experiences. That's perfectly fine, nobody
expects us to be perfect with the 1st shot.

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

14 years ago by Matthew Weier O'Phinney — view source

unread

I'm fine if the entire 'Feature selection and development' part goes
out of the RFC, but if there's any reference to how features are
determined, we'd better get it right.

Making changes once we've approved this RFC is going to be much
tougher. This is big stuff - it's no coincidence we didn't have such
guidelines for almost 15 years.

Honestly there are other parts about the voting process that are much
hotter potatoes than the points I brought up - such as who gets to
vote,

This is a tough one. I'm typically in favor of having the vote be
completely open to anybody. However, since we're talking language
features, there are a lot of other considerations -- internals folks
will have a much better idea of what the BC and support ramifications
are.

Perhaps two votes should be considered? A "general population" vote, and
an "internals" vote? This would show discrepancies between what users of
PHP want, and how internals is voting. If internals votes against a
feature that the general population has approved, I would expect to see
some sort of "executive summary" showing what technical issues are at
play that led to the internals vote. This would serve as a good
historical record -- and also potentially show where bias lies within
the internals community.

is 50%+1 enough or do we need stronger majorities for substantial
language changes (67%/75%),

I think anything less than a strong majority (2/3 or 3/4) often is
indicative of either ambivalence or strongly competing ideas. The
question is where that threshold should be set (I'd lean towards 2/3
vote.)

can someone who failed passing an RFC just put it up for another vote
right away or is there some sort of a cool-off period,

I'd argue a 2-3 week period in which to re-work the proposal and
incorporate feedback from the prior discussion/voting periods.

etc. etc. I think all of these need to be answered before we let this
RFC govern how we do feature definition.

Zeev

-----Original Message-----
From: Stas Malyshev [mailto:smalyshev@sugarcrm.com]
Sent: Sunday, June 05, 2011 11:17 PM
To: Zeev Suraski
Cc: Pierre Joye; PHP Internals
Subject: Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on
the wiki! (Was: [PHP-DEV] 5.4 moving forward))

Hi!

I'd still like to hear from others what they think about my
proposal. I'd like to update the Release Process RFC with these
suggestions if people like them.

I think these voting process additions totally make sense. But I am
not sure it makes sense to put everything in one release RFC. The
reason for that is that we don't want to endlessly amend and improve
the RFC without having it actually agreed upon, I would rather
prefer to agree on what we agree, have it as base for the future and
then add other stuff. I've noticed a tendency on the list to lose
the major goal behind endless amendments and tweaks and not doing
what we agree on because we disagree on some minor detail. So maybe
it would make sense to have release RFC separate (without spelling
out the voting process there) and voting RFC separate which would
define the voting process?

--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

14 years ago by Pierre Joye — view source

unread

hi Zeev,

Pierre,

I'm happy that we agree pretty much completely about the clarifications & updates needed for the RFC.

Same here :)

I do however want to point out that the problematic way the short array syntax RFC was executed was the key reason that made me feel these updates were in fact necessary - I don't think that the way it was done was exemplary in any way...

Well, it was done in a way without having an official way, so no, it
was not perfect.

Pretty much each and every point in my email is based on things that I felt went wrong with how we handled the short array syntax RFC:

There wasn't sufficient time, or nearly any time at all - between when Brian pulled it off the attic, and when a vote was called. If my proposal is accepted, there'll have to be at least two weeks between when a clearly marked [RFC] email hits internals@, and when a vote is called.

There wasn't a clearly marked, separate [VOTE] email.

There wasn't a clear or easy way of voting.

No voting period was announced, instead, people were told to stop mess around and go vote.

The author of the RFC wasn't actively involved in the whole process (as far as I could tell); There was no official replacement proposer.

I just want to make sure we're on the same page. If you feel that the array syntax RFC was 'done right' then we have a bit of a gap :) In my opinion, given the lacking process, the short array syntax RFC needs to be redone.

As I agree on everything you wrote here, I don't feel like we need to
redo it. The votes result is pretty clear, despite 2-3 people not
willing to vote for whatever reasons:

https://wiki.php.net/rfc/shortsyntaxforarrays/vote

All votes happened again after the alternatives have been proposed or
discussed. One would have voted against this RFC if any of the
alternatives was better. Anyway, if enough people thinks they want to
re do it (3rd time IIRC), so be it.

I'd still like to hear from others what they think about my proposal. I'd like to update the Release Process RFC with these suggestions if people like them.

I'm all for theses changes and updates.

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

14 years ago by Zeev Suraski — view source

unread

[resending as the list appears to reject bit.ly URLs]

As I agree on everything you wrote here, I don't feel like we need to redo it.
The votes result is pretty clear, despite 2-3 people not willing to
vote for whatever reasons:

https://wiki.php.net/rfc/shortsyntaxforarrays/vote

Take a look at http://english.ahram.org.eg/NewsContent/1/5/1712/Egypt/Egypt-Elections-/Mubarak-Despite-some-irregularities-elections-were.aspx . Spotting any resemblance? Look where he's at now :)

Major parts in the process weren't executed properly (I've spelled them out so I won't repeat them).
It's quite possible that if they were executed properly, we'd have different results. Perhaps not, maybe even probably not, but unless we do it right we'll never know.

Also, I suspect that you'd find that there are more than just a couple of people who 'refused to vote'. I'm betting that there are plenty of people who had no idea a vote was going on, and plenty more that weren't entirely clear on what exactly it is they're voting on - with all the discussion that happened on internals@ spreading in half a dozen different directions.

Zeev

14 years ago by Pierre Joye — view source

unread

take #4......

Hmmm, not sure I like the comparison (with Egypt).

Major parts in the process weren't executed properly (I've spelled them out so I won't repeat them).
It's quite possible that if they were executed properly, we'd have different results. Perhaps not, maybe even probably not, but unless we do it right we'll never know.

Are you saying that most people having voted +1 once, then a 2nd time
+1 and finally a 3rd time (editing the votes to put it under the right
syntax), would suddenly be totally against it?

Also, I suspect that you'd find that there are more than just a couple of people who 'refused to vote'. I'm betting that there are plenty of people who had no idea a vote was going on, and plenty more that weren't entirely clear on what exactly it is they're voting on - with all the discussion that happened on internals@ spreading in half a dozen different directions.

Given the active people, both in discussions and developments, I keep
my estimation to 2-3 refusing to vote and the rest not giving it
enough importance or does not care at all.

In any case, if you feel like we have to re vote, and many do as well,
then so be it.

14 years ago by Sebastian Bergmann — view source

unread

Am 05.06.2011 22:05, schrieb Zeev Suraski:

There wasn't sufficient time, or nearly any time at all - between when Brian pulled it off the attic, and when a vote was called. If my proposal is accepted, there'll have to be at least two weeks between when a clearly marked [RFC] email hits internals@, and when a vote is called.

There wasn't a clearly marked, separate [VOTE] email.

There wasn't a clear or easy way of voting.

No voting period was announced, instead, people were told to stop mess around and go vote.

The author of the RFC wasn't actively involved in the whole process (as far as I could tell); There was no official replacement proposer.

These are all valid points.

I'd still like to hear from others what they think about my proposal.

If your proposal addresses the issue mentioned above: +1. Haven't had
the time yet to read through it again, sorry.

--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/

14 years ago by dukeofgaming — view source

unread

I'd to go with a 60% for language syntax, 50+1 for new exts or sapis.
Other question is who can vote. For one, I like to have external
people being able to vote, like frameworks/apps lead developers as
well as @php.net in general (docs people at the same level than core
devs, no diff).

I have a little proposition here.

I'm not —at least currently— known for any app or framework, but I'd like my
voice to count, that is, if and only if the rest of the community thinks I
make sane arguments that are worth considering.

I'm perfectly aware that the fame one could gain from taking production code
to visible success should be an indicator of an educated opinion, however, I
think this might lead to a closed group who can vote, and I like the
openness of this community, even if the general process is chaotic, it still
gets the warm and fuzzy feeling of an open source community.

OTOH, if a completely open group's votes were all considered, the final
decision could just end up being a matter of numbers outnumbering other
numbers. If I get it right, this is the current problem.

So my proposal is that the voting privilege could be given on the basis of a
web of trust, and if I'm not mistaken this is a little like what the
concept of karma works here (I'm fairly new here). Not sure if there should
be a voting to elect voters or if it could/should be something more lax, but
I don't think the requirement to vote should be fame.

Best regards,

David

14 years ago by Chad Fulton — view source

unread

I have a little proposition here.

I'm not —at least currently— known for any app or framework, but I'd like my
voice to count, that is, if and only if the rest of the community thinks I
make sane arguments that are worth considering.

I'm perfectly aware that the fame one could gain from taking production code
to visible success should be an indicator of an educated opinion, however, I
think this might lead to a closed group who can vote, and I like the
openness of this community, even if the general process is chaotic, it still
gets the warm and fuzzy feeling of an open source community.

OTOH, if a completely open group's votes were all considered, the final
decision could just end up being a matter of numbers outnumbering other
numbers. If I get it right, this is the current problem.

So my proposal is that the voting privilege could be given on the basis of a
web of trust, and if I'm not mistaken this is a little like what the
concept of karma works here (I'm fairly new here). Not sure if there should
be a voting to elect voters or if it could/should be something more lax, but
I don't think the requirement to vote should be fame.

I'm similarly placed (as are many here I think), in the sense that I
have not done any internals work and I am not one of the lead devs for
a well-known project.

Much as I think my opinions are great, I don't believe we should have
a vote or, if we do, that it shouldn't count for as much as others',
for the following reasons:

Long-term commitment: we want people voting who (1) know the history
of past PHP discussions on topics and why they were rejected or
postponed, (2) understand the "PHP way", and (3) have shown commitment
to maintaining PHP
Perspective: developing with PHP is not the same as developing
for PHP internals. Feasibility, interoperability, maintenance
concerns, and more are things that, as long as I've read the list, are
often misunderstood or downplayed by people who develop with PHP and
want a shiny new feature (including me).
Unified vision: we want people who are taking the whole PHP picture
into account to be the ones doing the voting. Much of the volume on
the list is very narrowly focused - this is a good thing for
discussion of specific features, but a bad thing for picking which
features to include in PHP.

So, I would advocate a "white list" of core devs for formal voting (of
which, for example, I would not be a member). I think this mailing
list has grown sufficiently that "public opinion" can be gauged from
here: everyone can write their opinion without giving them voting
privileges.

If you haven't already, I recommend you read the (incredibly long)
discussions from last summer on type-hinting. They convinced me that
sometimes a feature that sounds good is simply not a good fit for PHP
for reasons which many did not (still do not?) understand.

Chad Fulton

14 years ago by Matthew Weier O'Phinney — view source

unread

So, I would advocate a "white list" of core devs for formal voting (of
which, for example, I would not be a member). I think this mailing
list has grown sufficiently that "public opinion" can be gauged from
here: everyone can write their opinion without giving them voting
privileges.

If you haven't already, I recommend you read the (incredibly long)
discussions from last summer on type-hinting. They convinced me that
sometimes a feature that sounds good is simply not a good fit for PHP
for reasons which many did not (still do not?) understand.

I think your analysis is great. That said, I think if this is the route
ultimately taken, any time an RFC is voted out, a summary of the
technical reasons for denying it should be provided. Usually there are
very good ones -- but this information can be invaluable to anybody who
may want to ressurect the RFC in the future to ensure they don't hit the
same pitfalls.

--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc