Hi.
As it was brought up recently that who can vote, and how are the community
representatives granted with voting rights, I created an RFC draft for
defining that-
Please feel free to discuss and extend it.
https://wiki.php.net/rfc/voting_who
ps: it is really just a draft put together in like 5 minutes, and mainly
because I don't have the right answers, I hope that we can figure it out.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi.
As it was brought up recently that who can vote, and how are the community
representatives granted with voting rights, I created an RFC draft for
defining that-
Please feel free to discuss and extend it.
https://wiki.php.net/rfc/voting_who
3 BAD ideas:
- If you haven't contributed into src in 5 years, you must be "NEW".
- If you want PHP to work like <the other language you like more>
- "My ego is involved, because I matter, and I am important!".
GOOD ideas are harder to come by than self important people.... which
seem to multiply in abundance.
Something I learned early, from Rasmus, and Zeev, and Andrei (any many
others), is that PHP is not a "right", "correct", or "accurate" coding
language. It's glue. Glue between HTML and C. That's it.
We can lay lots of layers on top, but that's icing.
-Ronabop
I just want to comment on one of the points:
Maybe we could define different type of votes (language syntax change, adding new feature/extensions, etc.) and define the who can vote for each of those.
- This could be a good middle-ground between allowing qa/documentation/web people to vote on language level RFCs or not.
I think that this isn't a good idea. The main reason for a [php-src]
vs. [php-doc et al.] distinction is that the php-src guys will be the
ones maintaining the code. (At least from what I heard this is the
main point.) I think this isn't a good argument. I would actually
argue that most, even minor, code changes cause much more work for
documentation than for core developers. Especially if you consider
that every change needs to be translated into quite a number of
different languages (and translation queues are looooong).
So: I would opt for keeping this point as is: Everyone with some sort
of svn access should be able to vote.
Nikita
Hi.
As it was brought up recently that who can vote, and how are the community
representatives granted with voting rights, I created an RFC draft for
defining that-
Please feel free to discuss and extend it.
https://wiki.php.net/rfc/voting_whops: it is really just a draft put together in like 5 minutes, and mainly
because I don't have the right answers, I hope that we can figure it out.--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
I think that this isn't a good idea. The main reason for a [php-src]
vs. [php-doc et al.] distinction is that the php-src guys will be the
ones maintaining the code. (At least from what I heard this is the
main point.)
I have more argument than that, maybe there are others also:
- The core devs usually know the internal parts better than the others
contributors, so they can weight the changes better on the technical parts
(opening a can of worms...). - The core devs are usually the ones who have to maintain the code, after
the happy RFC proposer disappears after having his/her feature included
(phar would be a fine example as I heard). - The core devs are usually the "stakeholders" of the project, if it turns
out, that it was a bad idea to add feature X, people won't check the wiki
and blame the original RFC author, or the Yesmen, the will blame "PHP" and
mostly the core devs. - The active core devs are usually contributing to the project since years
or decades, I think that the average experience/"lifespan" of a core-dev is
longer than for the other roles.
This usually means two things: more experience, and higher chances that
they will here to blame, when the shit hits the fan, so they tend to be
somehow more conservative than the average people from other groups.
So I think that being a core devs is somewhat bigger responsibility than
the other roles (and I don't say that other roles are easier or less
important) and I personally think that it would be a bad idea(and maybe
even unfair) to put them into a situation where they would have the
minority of the total votes.
Just my two cents.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
- The core devs usually know the internal parts better than the others
contributors, so they can weight the changes better on the technical parts
(opening a can of worms...).
I think you are hitting another issue with voting here that is not
related to the
"who can vote" part. If there are technical issues with an implementation (like
"opening a can of worms" or introducing large BC breaks) a vote should never
happen. This is the issue we already had for the "make scalar types reserved
keywords" request. There was a voting which decided it to be included, but
further discussion revealed that it would majorly break BC, so the vote was
discarded.
To summarize: The technical viability of a feature should always be determined
through discussion before voting even starts.
- The core devs are usually the ones who have to maintain the code, after
the happy RFC proposer disappears after having his/her feature included
(phar would be a fine example as I heard).
I addressed this point in my previous reply already
- The core devs are usually the "stakeholders" of the project, if it turns
out, that it was a bad idea to add feature X, people won't check the wiki
and blame the original RFC author, or the Yesmen, the will blame "PHP" and
mostly the core devs.
People usually blame PHP, not anybody in particular. I often call PHP bad
names myself (after encountering yet another implementation quirks) and
I definitely don't mean to insult any of the PHP developers (who are nice
people doing their best.) But you may be right that core developers might
be more offended by statements like "PHP sucks" than other contributors.
- The active core devs are usually contributing to the project since years
or decades, I think that the average experience/"lifespan" of a core-dev is
longer than for the other roles.
This seems valid :)
So, I don't really know. In some way it does make sense to give php-src more
voting rights, after all they do know internals better and are more engaged than
other contributors. On the other hand it also is kind of unfair for
everybody else
(okay, I am probably just biased here because I am not one of the
php-src people.)
Nikita
Hi!
To summarize: The technical viability of a feature should always be determined
through discussion before voting even starts.
It doesn't matter too much when it happens, as the purpose of the vote
is to see if the feature is needed/desired in the form that is proposed.
That doesn't mean it will actually be implemented - there are other
conditions for that, such as technical viability, willingness to
contribute/support, etc. It would be best if they would be closed before
voting in order to not waste time, but one should always realize they
are necessary in any case, voting or not.
So, I don't really know. In some way it does make sense to give php-src more
voting rights, after all they do know internals better and are more engaged than
other contributors. On the other hand it also is kind of unfair for
everybody else
I'm not sure what you mean by "fair" here. PHP project is not some
limited resource that is in common ownership and should be fairly
distributed between owners. I think decisions in PHP should be taken by
people that have the most ability to take correct decisions that would
make PHP more usable, and it has nothing to do with fairness.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
To summarize: The technical viability of a feature should always be
determined
through discussion before voting even starts.
It doesn't matter too much when it happens, as the purpose of the vote is to
see if the feature is needed/desired in the form that is proposed. That
doesn't mean it will actually be implemented - there are other conditions
for that, such as technical viability, willingness to contribute/support,
etc. It would be best if they would be closed before voting in order to not
waste time, but one should always realize they are necessary in any case,
voting or not.
That's what I was trying to say. That implementability isn't much of a
factor for voting,
as it is determined by the discussion, not the vote. By that argument
voting should not
require that you know all Zend API calls by heart (a basic
understanding of PHP internals
might be helpful though), so a restriction to php-src isn't necessary
from that point of view.
So, I don't really know. In some way it does make sense to give php-src
more
voting rights, after all they do know internals better and are more
engaged than
other contributors. On the other hand it also is kind of unfair for
everybody else
I'm not sure what you mean by "fair" here. PHP project is not some limited
resource that is in common ownership and should be fairly distributed
between owners. I think decisions in PHP should be taken by people that have
the most ability to take correct decisions that would make PHP more usable,
and it has nothing to do with fairness.
I borrowed the term "fair" from Tyrael's response, though retrospectively it was
a bad aspect to consider, as fairness or such isn't a precondition for
good descisions.
What I should have said is that in my eyes - as outlined in my other replies -
I don't see any compelling reasons why one should distinguish between php-src
contributors and the others.
Nikita
Hi!
What I should have said is that in my eyes - as outlined in my other replies -
I don't see any compelling reasons why one should distinguish between php-src
contributors and the others.
Because the premise here that PHP contributors understand PHP, it's
ideas, limitations, history, goals, technical structure etc. more than
anybody else. Of course, this is not absolute - somebody may have
excellent understanding of PHP and not be a contributor, or contribute
into some narrow area without ever gaining understanding of the project
as a whole. But if we have to have a simple rule of how to identify
people that are informed enough in PHP matters to influence decisions
that have huge impact, that's the best we have right now. Maybe we could
have better one, if proposed, it can be discussed.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi internals,
I won't enter on this thread of "Who can vote", but I'll get around it
during the exposure of my point of view. I may also point to
individual RFCs that were either accepted/rejected or it's still
pending. It's a long email, so take a seat and read carefully. I have
no means to hurt anyone or be impolite. But many times I did weird
things... it wouldn't be the first time if I've done so. It's not my
intention.
My short version of this entire email is very simple question. Is PHP
meritocracy based?
One day, Zeev told me that only people that do something for the
language should have voice over it. I completely agree with it. This
notion of meritocracy is healthy and it's exactly what pushes an Open
Source project forward. Individual contributions should also have a
voice. If someone that has no real experience of the internals of this
project suggest something, he should be treated as nicely as possible.
sidenote That's what I felt when I came to #php.pecl and Tyra3l gave
some attention to what I was trying to expose. That's awesome and he
won a lot of respect to me. If ever I have the opportunity to help
him, I'll try my best.
But lately I've seen this meritocracy failing multiple times, through
multiple ways in PHP.
This thread by itself is an attempt to address what the meritocracy
stated previously. You all discussed every single argument of voting
RFC and approved it. Everything seems to be fine until someone point
out that your voting can get out of control due to a dubious argument
in that RFC. And now you're trying by many ways to find a new argument
to put the control back to you. While I tend to agree the voting
process is broken and that it should be changed, I also consider that
the voting process shouldn't be changed DURING a voting of another
RFC. It should be only changed either before or after. Also, it should
not touch that meritocracy that Zeev enforced so much to put on my
head, and I think he did it very well.
By changing the rules of how major PHP enthusiasts except the ones
with SVN karma is really bad. If you're not a maintainer of the
language, who are the people that wants to move PHP forward? The PHP
tools' project leaders. By denying the voice of them is almost the
same as telling there's meritocracy only if you contribute with the
language internals.
From now on, you might be anxious waiting for my email to finish to
start a reply. Before do that, please continue to read.
I want to highlight another RFC where I saw the before mentioned
meritocracy fallen into the cracks.
http://wiki.php.net/rfc/shortsyntaxforarrays
I just want you to read the conclusion. It doesn't matter the content
of RFC, just the conclusion. If I could vote on that again, I'd have
changed my vote because I found out the complexity of having it
implemented after evaluating the patch. But that doesn't take out the
matter of that conclusion. If PHP is a meritocracy based language, I
thought that everyone have equally voice over it. It doesn't matter if
it's php-src SVN karma, php-doc karma, php-website or even user that
actively participates on mailing list. But that conclusion just state
to me that meritocracy does not exist. We could have +Hundreds/-0 of
userland and 0/-Everyone of PHP core and this feature would not be
implemented. Why? That RFC exposed correctly. Because userland does
not have voice.
But wait, the language exists for developers, userland, right? But if
they don't have voice, then the language is just a playground of a
few, that only when something "cool" is requested for core, it gets
implemented. Sorry, but this is not meritocracy, it's a programming
hobby.
I can even highlight another example, but I'm very afraid to mention
it here because I may be completely ignored. Annotations. How many
times I've heard "Oh no, that subject again, I should not connect
today" from some of you. It took me three attempts to improve the
language to finally understand that you only accept what you want, not
what others want. And even if strong pro arguments, if the RFC isn't
the exact same thing you want, you would never accept. I got many
prompt responses of "it would never be in core", "we won't touch the
symbol table", "if it doesn't belong to pecl, it would never be in
core", "do it in docblocks or it will never be implemented". We invest
tons of hours until we finally implement that by themselves and tried
again, and again and again. I questioned multiple times for RFC
stability and all I got was "it won't be implemented" or simply
ignored. I didn't even had a change to make a poll.
Some would simply say "he only did that because he got 3 proposals
rejected". Others would say "he is pressuring A to be in PHP". But
not. I learned the hard way and multiple times to hear a big NO. But
at the same time, I earn my salary from a language that is lead by
people that do only what they want, not what the language really
needs. PHP is a mess, everyone knows it. You have the power to change
that, to make it right. But only you can do that, only you can approve
someone's SVN karma, only you can vote and accept/reject something,
according to what you defined. We (I'm putting myself into userland
now) can only watch, without a single voice. If we can change and make
the language better somehow, one of these steps to achieve it is
broken. And I would love to know which one it is, so we can workaround
it.
Now I come back to original subject. Do you still think PHP is
meritocracy based?
Ok, you can start a reply. =)
Cheers,
Hi!
What I should have said is that in my eyes - as outlined in my other
replies -
I don't see any compelling reasons why one should distinguish between
php-src
contributors and the others.Because the premise here that PHP contributors understand PHP, it's ideas,
limitations, history, goals, technical structure etc. more than anybody
else. Of course, this is not absolute - somebody may have excellent
understanding of PHP and not be a contributor, or contribute into some
narrow area without ever gaining understanding of the project as a whole.
But if we have to have a simple rule of how to identify people that are
informed enough in PHP matters to influence decisions that have huge impact,
that's the best we have right now. Maybe we could have better one, if
proposed, it can be discussed.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227--
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
My short version of this entire email is very simple question. Is PHP
meritocracy based?
It is.
I want to highlight another RFC where I saw the before mentioned
meritocracy fallen into the cracks.
http://wiki.php.net/rfc/shortsyntaxforarrays
Except that is a terrible example because that was eventually accepted.
But yes, meritocracy means that the core developers have more say than
userland folks and if 14 active core developers vote against something
and 9 vote for, as per your example, then there is enough reason to not
implement it. Or, as was the case with this feature, it just took a bit
longer to get more core folks on board before it could be implemented.
If PHP is a meritocracy based language, I
thought that everyone have equally voice over it.
I think you are misunderstanding what a meritocracy means. It means
exactly the opposite of everyone having an equal voice. The people who
do the bulk of the work on the code have the most say over their own
code. And that doesn't make it a hobby, that makes it an open source
project created by volunteers.
From your example of the short syntax for arrays. If you check the
original voting, I voted for the feature. If this was a dictatorship and
not a meritocracy then I would have just pushed ahead and implemented
the feature, but with 14 high-merit votes against it I obviously
couldn't do that.
So yes, the conclusion stands. If a majority of core developers are
against a feature, it really doesn't matter how many userland people
want something. Core people don't vote against things for the fun of it.
They tend to have legitimate concerns. You may not agree with those
concerns, but that doesn't mean they aren't real and they are coming
from the perspective of someone who has a lot more experience than other
voters for a feature. Now, the way to change that dynamic is for more
people to become involved and help with the core of the language. Help
with fixing bugs, fixing test cases, reviewing bug reports and through
this effort become core contributors who can then vote the next time the
feature is brought up and push it through at that point.
-Rasmus
Hi Rasmus,
Comments inline.
My short version of this entire email is very simple question. Is PHP
meritocracy based?It is.
I'd rather say "wort of, when interesting".
I want to highlight another RFC where I saw the before mentioned
meritocracy fallen into the cracks.
http://wiki.php.net/rfc/shortsyntaxforarraysExcept that is a terrible example because that was eventually accepted.
But yes, meritocracy means that the core developers have more say than
userland folks and if 14 active core developers vote against something
and 9 vote for, as per your example, then there is enough reason to not
implement it. Or, as was the case with this feature, it just took a bit
longer to get more core folks on board before it could be implemented.
I'll stick to "userland".
Anyone that can vote today contributes to PHP by any way. Only SVN
users can vote, so they are either contributors of doc, website, src.
I have wrongly classified the "userland" here. My mistake, but the
fact is that every single voter there must have equal voice.
I want to expand my explanation on next topic.
If PHP is a meritocracy based language, I
thought that everyone have equally voice over it.I think you are misunderstanding what a meritocracy means. It means
exactly the opposite of everyone having an equal voice. The people who
do the bulk of the work on the code have the most say over their own
code. And that doesn't make it a hobby, that makes it an open source
project created by volunteers.
I don't think so. You have classified that php-src have more weight in
voting because they do the biggest effort.
That's great, but you're forgetting that php-doc, php-web and php-test
do have a lot of effort too.
The fact when it comes to touch the php-src, no matter what you do, if
you're not part of php-src, your vote doesn't have the same weight.
This means clearly to me that meritocracy is applied correctly until
the SVN karma, but after that, only php-src are listened. That's what
the short array syntax describes.
From your example of the short syntax for arrays. If you check the
original voting, I voted for the feature. If this was a dictatorship and
not a meritocracy then I would have just pushed ahead and implemented
the feature, but with 14 high-merit votes against it I obviously
couldn't do that.
And I'm not criticizing you individually. I'm questioning core as a
whole. You're part of it, but your ideas may be different from others.
I respect you a lot and I really appreciate all the effort you put
into the language. But still, there're hundreds of other people who
also put it too, either contributing in spreading PHP, helping docs,
maintaining the website, etc. Would you still consider them that their
vote weight is different?
So yes, the conclusion stands. If a majority of core developers are
against a feature, it really doesn't matter how many userland people
want something. Core people don't vote against things for the fun of it.
They tend to have legitimate concerns. You may not agree with those
concerns, but that doesn't mean they aren't real and they are coming
from the perspective of someone who has a lot more experience than other
voters for a feature. Now, the way to change that dynamic is for more
people to become involved and help with the core of the language. Help
with fixing bugs, fixing test cases, reviewing bug reports and through
this effort become core contributors who can then vote the next time the
feature is brought up and push it through at that point.
Still... the userland is still people with SVN access.
I tend to agree that short array syntax is cool, but if the patch is a
can of worms, then it's fine to revert it. But it's something I spoke
with Andi other day... if it opens so many issues in the language,
then the engine is starting to reach its own limitations.
I saw that PHP had complete rewrite of its engine happened after 5
years... it's been exactly 5 years since last rewrite and it seems
some of the RFC are already requiring changes in the engine. Don't you
think it's time to consider it again?
-Rasmus
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
I don't think so. You have classified that php-src have more weight in
voting because they do the biggest effort.
That's great, but you're forgetting that php-doc, php-web and php-test
do have a lot of effort too.
The fact when it comes to touch the php-src, no matter what you do, if
you're not part of php-src, your vote doesn't have the same weight.
This means clearly to me that meritocracy is applied correctly until
the SVN karma, but after that, only php-src are listened. That's what
the short array syntax describes.
If there is voting on an RFC related to php-doc stuff, then the
meritocracy shifts to the main php-doc contributors. Same goes for
testing-related issues. My vote on a doc issue carries considerable less
weight than my vote on a src issue. Call it a consensus-based
meritocracy, if you will. The idea here is that it isn't sustainable for
the voting process to create a decision that a large number of the
people doing the day-to-day work on a given part of the project disagree
with. In a volunteer organization that simply doesn't work because the
volunteers will naturally just stop volunteering if they are forced to
work this way.
Still... the userland is still people with SVN access.
I tend to agree that short array syntax is cool, but if the patch is a
can of worms, then it's fine to revert it. But it's something I spoke
with Andi other day... if it opens so many issues in the language,
then the engine is starting to reach its own limitations.
I saw that PHP had complete rewrite of its engine happened after 5
years... it's been exactly 5 years since last rewrite and it seems
some of the RFC are already requiring changes in the engine. Don't you
think it's time to consider it again?
Sure, but this is another great example. If you wrote an RFC that
basically said, "Let's rewrite the engine" I bet it would get a lot of
positive votes. But then what? Rewriting the engine is a multi-year
effort by at least a couple of really strong developers. Unless the RFC
is written by these developers or it includes a credible commitment by
said developers to actually do the work and stick around to support it,
the votes are meaningless. You are kind of implying that because a bunch
of people click a checkbox on the wiki site, I, or someone like me
should quit our jobs and spend the next 2 years of our lives working on
something you think is a good idea. Things just don't work like that.
-Rasmus
If there is voting on an RFC related to php-doc stuff, then the
meritocracy shifts to the main php-doc contributors. Same goes for
testing-related issues. My vote on a doc issue carries considerable less
weight than my vote on a src issue. Call it a consensus-based
meritocracy, if you will. The idea here is that it isn't sustainable for
the voting process to create a decision that a large number of the
people doing the day-to-day work on a given part of the project disagree
with. In a volunteer organization that simply doesn't work because the
volunteers will naturally just stop volunteering if they are forced to
work this way.
We may really come back to earth. There are no decision that has been
taken in a way that php has been hurt in any way, since the RFC has
been re introduced.
There is also not 1000s of random people voting on features but well
known persons. Persons who already contribute to PHP in one way or
another.
We are not giving away our power or freedom of choices but only giving
a voice to people who deserves it, for the good of the future of PHP.
And we damned have to do it.
Sure, but this is another great example. If you wrote an RFC that
basically said, "Let's rewrite the engine" I bet it would get a lot of
positive votes. But then what? Rewriting the engine is a multi-year
effort by at least a couple of really strong developers. Unless the RFC
is written by these developers or it includes a credible commitment by
said developers to actually do the work and stick around to support it,
the votes are meaningless. You are kind of implying that because a bunch
of people click a checkbox on the wiki site, I, or someone like me
should quit our jobs and spend the next 2 years of our lives working on
something you think is a good idea. Things just don't work like that.
That's another myth spread by the opponents of making our process
open. All RFCs proposed has been proposed with patches, implemented by
the proposers, with or without the help of other core developers.
Nobody ever succeed (except the alternative array RFC which did no go
further than draft) to propose something without a clear&clean
implementation. I'm sorry, and with all respects, this is FUD.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
That's another myth spread by the opponents of making our process
open. All RFCs proposed has been proposed with patches, implemented by
the proposers, with or without the help of other core developers.
Nobody ever succeed (except the alternative array RFC which did no go
further than draft) to propose something without a clear&clean
implementation. I'm sorry, and with all respects, this is FUD.
We are not talking about a specific RFC here. This discussion is about
changing the current way of voting.
-Rasmus
We are not talking about a specific RFC here. This discussion is about
changing the current way of voting.
Yes, and that's what I'm talking about too.
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
We are not talking about a specific RFC here. This discussion is about
changing the current way of voting.Yes, and that's what I'm talking about too.
Ok, then I guess I don't understand what your argument is. We already
agreed that leaders of large projects get a vote and the voting RFC
(which you helped write) is quite clear that language changes need a 2/3
majority to pass but 50%+1 for other changes. Could you please clearly
state what it is you want to change then? Because so far to me it sounds
a bit like you are simply beating up on the people who chose to vote
differently from you on this latest RFC.
-Rasmus
We are not talking about a specific RFC here. This discussion is about
changing the current way of voting.Yes, and that's what I'm talking about too.
Ok, then I guess I don't understand what your argument is. We already
agreed that leaders of large projects get a vote and the voting RFC
(which you helped write) is quite clear that language changes need a 2/3
majority to pass but 50%+1 for other changes. Could you please clearly
state what it is you want to change then? Because so far to me it sounds
a bit like you are simply beating up on the people who chose to vote
differently from you on this latest RFC.
It is clear to me and I get the feeling here, with Tyrael's thread and
Stas arguments that this agreement is all of a sudden invalid. And
that's where I so strongly disagree.
If that's not the case, and after a 2nd thought, it is actually not
the case, then we can just discard this whole thread and go back to
code and proposals. I only find very disturbing to have to explain and
argue so many times about that only because we have a edge case in a
proposal (which is perfectly valid, that happens, show must go on).
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
On Thu, Nov 10, 2011 at 9:04 PM, Rasmus Lerdorf rasmus@lerdorf.com
wrote:On Thu, Nov 10, 2011 at 7:18 PM, Rasmus Lerdorf rasmus@lerdorf.com
wrote:We are not talking about a specific RFC here. This discussion is about
changing the current way of voting.Yes, and that's what I'm talking about too.
Ok, then I guess I don't understand what your argument is. We already
agreed that leaders of large projects get a vote and the voting RFC
(which you helped write) is quite clear that language changes need a 2/3
majority to pass but 50%+1 for other changes. Could you please clearly
state what it is you want to change then? Because so far to me it sounds
a bit like you are simply beating up on the people who chose to vote
differently from you on this latest RFC.It is clear to me and I get the feeling here, with Tyrael's thread and
Stas arguments that this agreement is all of a sudden invalid. And
that's where I so strongly disagree.If that's not the case, and after a 2nd thought, it is actually not
the case, then we can just discard this whole thread and go back to
code and proposals. I only find very disturbing to have to explain and
argue so many times about that only because we have a edge case in a
proposal (which is perfectly valid, that happens, show must go on).
If that's the case, could someone please update the voting RFC?
The most common questions, misunderstandings:
- "that have contributed code to PHP": this is too vague, as it could mean
either
-- C code (contributed code to the PHP language not to the project)
-- any code (web, tests, etc.)
-- any contribution (documentation for example) - how are the the PHP community representatives selected?
-- the "Representatives from the PHP community, that will be chosen by
those with php.net SVN accounts" line would suggest that "we" select the
representatives, but from the discussion it seems more likely that we only
approve the applications. how would that work exactly?
-- is there any technical or other difference between a vote of the
community representatives and those with SVN accounts? (both Rasmus and
Stas mentioned in this thread that in extreme cases having the majority of
the votes isn't enough if the majority of the "core-devs" are against it).
-- is there any limitation for the newly approved representatives? (are
there any limit on the number of community representatives? etc.)
For the record: I didn't created this draft/thread to change the current
rules, I only wanted to clear up the misunderstanding and find out what do
we all mean by those rules exactly.
When I was asked recently by William DURAND that how could he be a
community representative I couldn't just send him a link, that here is how,
you have to follow these steps and you are good to go.
I could only tell him, that by the voting RFC we do have community
representatives, and they can vote, but I don't know how that works, but
being the lead of the Propel ORM would be make him a good candidate.
So I asked him to send an email to the mailing list, hoping that someone
with better understanding of the process can clear that up.
There is no reply to his mail yet:
internals@lists.php.net/msg54229.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg54229.html
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Pierre Joye wrote:
If that's not the case, and after a 2nd thought, it is actually not
the case, then we can just discard this whole thread and go back to
code and proposals. I only find very disturbing to have to explain and
argue so many times about that only because we have a edge case in a
proposal (which is perfectly valid, that happens, show must go on).
Ferenc raised a legitimate question, but it seems to have been deliberately
misinterpreted. As someone who does not have the right to vote, only 'heckle' it
would be useful to know what I need to do to get on the voting list. This I
think was Ferenc's intention? We can see who has the right to vote since the
polls are open, but no way of telling if a person CAN vote on the point being
discussed?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
If that's not the case, and after a 2nd thought, it is actually not
the case, then we can just discard this whole thread and go back to
code and proposals. I only find very disturbing to have to explain and
argue so many times about that only because we have a edge case in a
proposal (which is perfectly valid, that happens, show must go on).
The problem with some RFCs is that it is not clear what people are
voting on. In some cases people are voting for or against a proposal
based solely on the concept while other people are looking at the nitty
gritty details of the implementation and voting against it due to
implementation problems. Then there are procedural problems like the RFC
changing during the voting process.
As long as it is completely obvious what is being voted on and the
process is followed, the voting RFC rules are fine. It would be nice
though if we could iterate in order to get 2/3 approval on most
proposals. It is these 50/50 ones that are problematic and often boil
down to half the people voting, "We want this feature!" and the other
half voting, "Yes, but this implementation, as proposed, is half-baked."
In cases like this where we end up in a 50/50 standoff instead of
pushing thought with 50+1 I would much rather see each of the valid
criticisms added to the RFC with an explanation of what the problem is
and what is or isn't being done to address it and open the voting for
another week to give the former no (or yes) voters a chance to be better
informed and change or add their votes.
-Rasmus
Hi!
As long as it is completely obvious what is being voted on and the
process is followed, the voting RFC rules are fine. It would be nice
though if we could iterate in order to get 2/3 approval on most
proposals. It is these 50/50 ones that are problematic and often boil
down to half the people voting, "We want this feature!" and the other
half voting, "Yes, but this implementation, as proposed, is half-baked."
This is exactly the problem. Most of the people vote for generic idea,
but later it's taken as approval of specific design and specific patch
attached to the RFC - even though I'm willing to bet most of the voters
didn't actually read the patch and verified it even works. Which would
be fine if there would be additional layer of supervision from core -
but "equal vote for all" precludes that, and I see a problem with that.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
Sure, but this is another great example. If you wrote an RFC that
basically said, "Let's rewrite the engine" I bet it would get a lot of
We already have such proposal. It's called unicode support. Everybody
talks about how great it would be to have one. If we had a vote, I bet
there would be zero votes against in from the community. But we all know
by now it's not that easy and if there was a patch to do it this patch
would with 99% probability fail. Even if it were perfect, it would take
very long time to ensure that, and very deep and passionate discussion.
That's because this thing is much harder and more complex than it
appears on the first sight, until you really start to think about all
the consequences. Having such matters decided on simple vote is madness.
That's another myth spread by the opponents of making our process
open. All RFCs proposed has been proposed with patches, implemented by
the proposers, with or without the help of other core developers.
The problem is not having patches, the problem is having the patches
that won't cause trouble in other parts of PHP. For example - and please
understand I'm not trying to single out anybody, it's just and example -
IIRC for spl loader patch right now there's a problem of it trying to
load non-existing files if non-existing class is checked. We'd have to
deal with this problem. It also has something called "include path"
which works totally different from PHP's include path. We'd have to deal
with that too, and with users asking us why we call two different things
"include path" and then ranting all over the internet how PHP is an
inconsistent mess.
Also I see that get_filename() modifies its arguments, while getPath()
passes its argument directly to it. Not sure it's the best idea.
Also, not sure if it's an issue or not, but it looks like the included
files will be run in the scope of whichever code initiated the
autoloader. Which is not the case with PHP-based loaders. I know
everybody writes good code which would never spill anything to including
scope but... :)
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
tools' project leaders. By denying the voice of them is almost the
same as telling there's meritocracy only if you contribute with the
language internals.
Nobody's "denying voice" to anybody. Anybody who's interested can feel
free to come to the list and bring forward their arguments and defend
them and convince people. However, if the situation comes out that a
particular proposal failed to convince any substantial number of people
who maintain PHP and deal with it every day, or even substantial part of
them think it is a bad idea - maybe indeed it is not the best idea to
have it in PHP? Or maybe time for it has not come or it was not thought
out or explained properly? I do not think it makes sense for PHP core
developers to take on themselves to implement and maintain things that
they think are wrong only because certain number of people that they
don't know voted yes. If the proposal has merits, it should be - and
usually is - possible to convince enough people to support it. If it's
not possible - maybe it's not as ready for prime time as it appeared.
matter of that conclusion. If PHP is a meritocracy based language, I
thought that everyone have equally voice over it. It doesn't matter if
As it was already pointed out, that's the exact opposite of meritocracy.
But wait, the language exists for developers, userland, right? But if
Right. But that does not mean it should be jerked around by any minute
fad or any random idea. Language development should be guided, monitored
and somewhat conservative and changes should be done after careful
consideration and weighting of the need and the effect of it.
However big vote we hold, 99.9% of language users would not participate,
and we have to take that into account too.
again, and again and again. I questioned multiple times for RFC
stability and all I got was "it won't be implemented" or simply
ignored. I didn't even had a change to make a poll.
We had very extensive discussion about annotations and its
implementation, etc. (which may yet be reborn for 5.5, for all I know).
I can't believe from all that you got only "it won't be implemented".
according to what you defined. We (I'm putting myself into userland
now) can only watch, without a single voice. If we can change and make
What do you mean? You're enjoying a voice right now. You're talking to
core PHP developers, which are discussing your concerns and your
proposals. Do you want to make it so that if you find a friend and you
have 2 votes and PHP core dev has 1 then PHP core dev has to implement
and maintain whatever you want? Sorry, you can't get that. You can and
will, however, get any good proposal discussed and seriously considered.
And yes, that means they can be rejected too. Such is life. My proposals
get rejected too. It happens, it stings, I hope for better luck next time.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
hi Stas,
Nobody's "denying voice" to anybody. Anybody who's interested can feel free
to come to the list and bring forward their arguments and defend them and
convince people. However, if the situation comes out that a particular
proposal failed to convince any substantial number of people who maintain
PHP and deal with it every day, or even substantial part of them think it is
a bad idea - maybe indeed it is not the best idea to have it in PHP? Or
maybe time for it has not come or it was not thought out or explained
properly? I do not think it makes sense for PHP core developers to take on
themselves to implement and maintain things that they think are wrong only
because certain number of people that they don't know voted yes. If the
proposal has merits, it should be - and usually is - possible to convince
enough people to support it. If it's not possible - maybe it's not as ready
for prime time as it appeared.
There are different things we are talking about here.
What is a (active) core developer? Who maintains what? Who maintains
anything at all?
What I see is a large gap between the reality of the needs of our
users and us. Many of new RFCs have rejected (some many times) before
they got accepted, only because of some core developers not
understanding or not willing to have a given feature. And that even if
they won't be the ones who will maintain it anyway, just like they are
not the ones who maintain most of php anyway.
Another problem is the limited vision or view on how PHP is actually
used and where it is moving. Our communities can bring us these
feedback and lead us to improve PHP so it will still be successful.
Many times in the past (and today) we are just telling them that we do
not care about what they need or want. We better have to change, or we
can keep dreaming about our famous "let make it easy to people to
contribute", it won't work as we are not willing to give them a voice.
The last example of such a case is the SplClassLoader, the gap between
our communities and us is getting even larger. I think it is time to
consider their views and voices, especially as we get new contributors
(you know, the people actually doing the job?).
About who can vote, community leaders and php.net developers have the
same weight. There should not be some higher voters class, be inside
core devs, doc, or whatever else. It will just reproduce the horrible
things we had for years where some thought they can alone decide what
should be php or a specific area of the language.
To avoid to get bad things in the language, there is a clause in the
voting RFC requiring a larger majority. This clause applies for
language changes and makes perfectly sense. In a way it should solve
the core vs the world problem.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
The last example of such a case is the SplClassLoader, the gap between
our communities and us is getting even larger. I think it is time to
consider their views and voices, especially as we get new contributors
(you know, the people actually doing the job?).
But many of the objections to SplClassLoader are coming from non-core
people. The "community" isn't a single voice as has been
well-illustrated by the SplClassLoader discussion. When there is shaky
community consensus on something, we either need to pick a side and go
with it, or wait a bit and see if it sorts itself out.
-Rasmus
The last example of such a case is the SplClassLoader, the gap between
our communities and us is getting even larger. I think it is time to
consider their views and voices, especially as we get new contributors
(you know, the people actually doing the job?).But many of the objections to SplClassLoader are coming from non-core
people. The "community" isn't a single voice as has been
well-illustrated by the SplClassLoader discussion. When there is shaky
community consensus on something, we either need to pick a side and go
with it, or wait a bit and see if it sorts itself out.
It is a single voice in this case, and the disagreement I have seen
are not about what is about to be added. And if there are more about
PSR-0, then they should bring them to the PSR discussions and get them
fixed and approved for the next version.
But right now, PSR-0 has been approved by a waste majority of
frameworks and projects and is going to be even larger with the next
major version of projects like Drupal, which will adopt it while
relying on a common set of components.
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
The last example of such a case is the SplClassLoader, the gap between
our communities and us is getting even larger. I think it is time to
consider their views and voices, especially as we get new contributors
(you know, the people actually doing the job?).But many of the objections to SplClassLoader are coming from non-core
people. The "community" isn't a single voice as has been
well-illustrated by the SplClassLoader discussion. When there is shaky
community consensus on something, we either need to pick a side and go
with it, or wait a bit and see if it sorts itself out.It is a single voice in this case, and the disagreement I have seen
are not about what is about to be added. And if there are more about
PSR-0, then they should bring them to the PSR discussions and get them
fixed and approved for the next version.But right now, PSR-0 has been approved by a waste majority of
frameworks and projects and is going to be even larger with the next
major version of projects like Drupal, which will adopt it while
relying on a common set of components.
When the concerns about that "standard" were raised originally they
got ignored and eventually few people moved away from the open process
where people could voice issues to a forum were only people that
echoed eachothers +1 were able to participate.
After the agreement was finalized more people got the chance to join
in, but that hardly served any purpose as there already was agreement.
Your "approved vast majority of framworks and projects" argument is
therefore bogus. They never approved anything, they really just got it
stuffed down their throat.
When you say that they can fixed outstanding issues in their updated
"standard", how should the SplClassLoader accommodate that standard?
SplClassLoadV2?
In any case, no matter how much I disagree with the politics around
that document, we are voting on the RFC, not that "standard".
-Hannes
Hi!
can keep dreaming about our famous "let make it easy to people to
contribute", it won't work as we are not willing to give them a voice.
I don't think one implies the other. If one helps PHP project it's
great, really, but that doesn't mean one can have his pet feature pushed
through over objections of other project participants. It can't work
this way - there should be control and there should be consensus.
The last example of such a case is the SplClassLoader, the gap between
our communities and us is getting even larger. I think it is time to
consider their views and voices, especially as we get new contributors
(you know, the people actually doing the job?).
So who exactly of the people that's actually doing the job is not
allowed to contribute his ideas?
About who can vote, community leaders and php.net developers have the
same weight. There should not be some higher voters class, be inside
core devs, doc, or whatever else. It will just reproduce the horrible
things we had for years where some thought they can alone decide what
should be php or a specific area of the language.
I don't remember any horrible things and any dictatorship happening in
the history of PHP that led to any unimaginable horrors. As in any big
project, there were mistakes, there were screwups and there were
unobvious decisions that in the hindsight look bad - but I don't see how
more people voting on anything could prevent anything of that happening.
To avoid to get bad things in the language, there is a clause in the
voting RFC requiring a larger majority. This clause applies for
language changes and makes perfectly sense. In a way it should solve
the core vs the world problem.
Majority does not solve anything. Being majority doesn't automatically
makes it right. I do not believe right technical decision can be taken
by measuring majority in votes, especially if we're talking about giving
equal voice to everybody regardless of they level of informed-ness in
the details of the project, understanding of the project and commitment
to the project. I understand that people want their voices to be heard,
and this is welcome, but tell me how many projects you know that anybody
can come there and demand features and changes and have the same vote as
core project developers without even being a contributor? Can you do it
in any of major open source projects?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
can keep dreaming about our famous "let make it easy to people to
contribute", it won't work as we are not willing to give them a voice.
I don't think one implies the other. If one helps PHP project it's great,
really, but that doesn't mean one can have his pet feature pushed through
over objections of other project participants. It can't work this way -
there should be control and there should be consensus.
Pet feature? Can you please have more respects to proposals?
The last example of such a case is the SplClassLoader, the gap between
our communities and us is getting even larger. I think it is time to
consider their views and voices, especially as we get new contributors
(you know, the people actually doing the job?).So who exactly of the people that's actually doing the job is not allowed to
contribute his ideas?
See the votes, there is a patch, created by people able to maintain
it. It is especially obvious in this case as this RFC is supported by
a large part of our users.
I don't remember any horrible things and any dictatorship happening in the
history of PHP that led to any unimaginable horrors. As in any big project,
there were mistakes, there were screwups and there were unobvious decisions
that in the hindsight look bad - but I don't see how more people voting on
anything could prevent anything of that happening.
I call that consensus, and our vision has been proven wrong many times
already, remember the "we don't need OO" back then? Not sure if you
were already in php.net, but that was the moto for the core. We keep
repeating the same mistakes.
Majority does not solve anything. Being majority doesn't automatically makes
it right. I do not believe right technical decision can be taken by
measuring majority in votes, especially if we're talking about giving equal
voice to everybody regardless of they level of informed-ness in the details
of the project, understanding of the project and commitment to the project.
I understand that people want their voices to be heard, and this is welcome,
but tell me how many projects you know that anybody can come there and
demand features and changes and have the same vote as core project
developers without even being a contributor? Can you do it in any of major
open source projects?
I can show you many other major OSS projects where feedbacks and
proposals from users are taken seriously without this superior
attitude we keep to have here.
Now, tell me where I said that random people should have the same
weight than a core developer (whatever is a core developer today....).
I never said that.
However, and it is what we approved, OSS project leads have a voice,
today and here. And they are not random people, they know sometimes
much better than us what should be added to the core (be language, or
functions in an extension like spl).
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi!
See the votes, there is a patch, created by people able to maintain
it. It is especially obvious in this case as this RFC is supported by
a large part of our users.
Able != will. There are tons of people able to fix bugs in PHP, yet some
stay unfixed for years.
"Supported by users" doesn't mean these people will maintain it. It
means they want somebody to put it in core. These are totally different
things.
Anyway, you didn't name any projects, so the conclusion is there's no
projects that ever done what you propose to do for PHP. That's what I am
saying.
I call that consensus, and our vision has been proven wrong many times
already, remember the "we don't need OO" back then? Not sure if you
were already in php.net, but that was the moto for the core. We keep
repeating the same mistakes.
I don't see how that (which was like 10 years ago) has any relationship
to what happens now. And IIRC first iteration of OO in PHP sucked and we
still struggling with the fallout from that. Maybe if the php group
waited, it might be done right the first time.
I can show you many other major OSS projects where feedbacks and
proposals from users are taken seriously without this superior
attitude we keep to have here.
We spend huge amounts of time discussing various third party proposals,
yet I constantly hear about that "superior attitude" and complains about
"not considering anything" - by weird coincidence, from people whose
proposals aren't accepted. I'm starting to suspect something is missing
in this picture.
However, and it is what we approved, OSS project leads have a voice,
today and here. And they are not random people, they know sometimes
They do have a voice. They don't have a power to force PHP group do
things that aren't accepted by consensus. Just as I don't have a power
to force Apache Group or Python or Perl to do something they don't
accept just because I use Apache or Python or Perl.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
See the votes, there is a patch, created by people able to maintain
it. It is especially obvious in this case as this RFC is supported by
a large part of our users.Able != will. There are tons of people able to fix bugs in PHP, yet some
stay unfixed for years.
"Supported by users" doesn't mean these people will maintain it. It means
they want somebody to put it in core. These are totally different things.
Anyway, you didn't name any projects, so the conclusion is there's no
projects that ever done what you propose to do for PHP. That's what I am
saying.I call that consensus, and our vision has been proven wrong many times
already, remember the "we don't need OO" back then? Not sure if you
were already in php.net, but that was the moto for the core. We keep
repeating the same mistakes.I don't see how that (which was like 10 years ago) has any relationship to
what happens now. And IIRC first iteration of OO in PHP sucked and we still
struggling with the fallout from that. Maybe if the php group waited, it
might be done right the first time.
It was more about if the PHP group listened back then to the users
instead of staying between us with no or little idea about what is
actually needed from our users.
I can show you many other major OSS projects where feedbacks and
proposals from users are taken seriously without this superior
attitude we keep to have here.We spend huge amounts of time discussing various third party proposals, yet
I constantly hear about that "superior attitude" and complains about "not
considering anything" - by weird coincidence, from people whose proposals
aren't accepted. I'm starting to suspect something is missing in this
picture.
I do not but only see a schema being built, which create a larger gap
between our communities and the core developers. This feeling is being
confirmed when I talked to them at various events. I saw it before as
well even for proposals which got accepted. This is not about specific
proposals but about this exact discussion to go back to our old model.
I'm totally against it. That will kill any effort we have put to get
more contributors and feedback or help from our users.
However, and it is what we approved, OSS project leads have a voice,
today and here. And they are not random people, they know sometimesThey do have a voice. They don't have a power to force PHP group do things
that aren't accepted by consensus. Just as I don't have a power to force
Apache Group or Python or Perl to do something they don't accept just
because I use Apache or Python or Perl.
You are comparing apple and pears here.
We are not talking about giving a voice to totally irrelevant people
but well known PHP project leaders, who already contribute to PHP in
one way or another. We are not either talking about them telling us
what to implement, or what to do next. That won't change and did not
change for what we have done in the past, as you can see in 5.4.0.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi!
well even for proposals which got accepted. This is not about specific
proposals but about this exact discussion to go back to our old model.
I'm totally against it. That will kill any effort we have put to get
more contributors and feedback or help from our users.
Nobody talks about going "to old model", whatever it is. We have RFCs,
we have release process, we have discussion lists, we have community
vote when we need it - all this is not going to go anywhere. But you say
it's not enough - you say we need to actually make people be able to
cast a binding vote in the project without being part of it. I don't see
how not accepting it would constitute "going back to old model".
We are not talking about giving a voice to totally irrelevant people
but well known PHP project leaders, who already contribute to PHP in
one way or another. We are not either talking about them telling us
what to implement, or what to do next. That won't change and did not
change for what we have done in the past, as you can see in 5.4.0.
That didn't change, but my understanding is that that's exactly what you
are proposing to change now. If it is not, then what you are proposing?
I understood that you proposed that votes cast by non-members of PHP
project would actually be binding for the project. If it is not so, I
misunderstood you - then please explain what is your proposed change.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hello,
We are not talking about giving a voice to totally irrelevant people
but well known PHP project leaders, who already contribute to PHP in
one way or another. We are not either talking about them telling us
what to implement, or what to do next. That won't change and did not
change for what we have done in the past, as you can see in 5.4.0.
I would like to chime in by saying pretty much anyone who posts to
this list is taking time out of there schedule and if the feedback is
constructive, that person is relevant. If they own a fortune 500
company, or are a jr developer for a small startup, they are surely
providing feedback that is valuable to the PHP Group and to introduce
a method of measurement of a voices worth is only going to further
widen the communication gap we have seen in the past; that has
recently seen small measures of improvement.
I think voting on features shouldn't be so cut and dry as it is looked
at now. Really there should be two parts, first each person who
responds to this list should count towards measuring the php
communitys desire for a given proposal. That is really the only way
give PHP the community feeling you would expect from a open source
project, this will also provide people with motivation for
contributing what just may be PHP's next best thing. The second part
is adoption and implementation, it isn't fair or even possible to
implement every feature that has overwhelming community support, so a
core contributors sponsorship is required, this is basically what we
already see now for most things. By what I am reading, we are just
cutting out the community voice through arbitrary measures of
importance.
The long story short, start nit picking the importance of community
feedback and I see it having a negative impact on PHP. The last thing
I want to do is see people start sending resumes to the list to have
there votes count.
-Chris
On Thu, Nov 10, 2011 at 4:01 AM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:
Hi internals,
I won't enter on this thread of "Who can vote", but I'll get around it
during the exposure of my point of view. I may also point to
individual RFCs that were either accepted/rejected or it's still
pending. It's a long email, so take a seat and read carefully. I have
no means to hurt anyone or be impolite. But many times I did weird
things... it wouldn't be the first time if I've done so. It's not my
intention.My short version of this entire email is very simple question. Is PHP
meritocracy based?One day, Zeev told me that only people that do something for the
language should have voice over it. I completely agree with it. This
notion of meritocracy is healthy and it's exactly what pushes an Open
Source project forward. Individual contributions should also have a
voice. If someone that has no real experience of the internals of this
project suggest something, he should be treated as nicely as possible.
sidenote That's what I felt when I came to #php.pecl and Tyra3l gave
some attention to what I was trying to expose. That's awesome and he
won a lot of respect to me. If ever I have the opportunity to help
him, I'll try my best.
But lately I've seen this meritocracy failing multiple times, through
multiple ways in PHP.
This thread by itself is an attempt to address what the meritocracy
stated previously. You all discussed every single argument of voting
RFC and approved it. Everything seems to be fine until someone point
out that your voting can get out of control due to a dubious argument
in that RFC. And now you're trying by many ways to find a new argument
to put the control back to you. While I tend to agree the voting
process is broken and that it should be changed, I also consider that
the voting process shouldn't be changed DURING a voting of another
RFC. It should be only changed either before or after. Also, it should
not touch that meritocracy that Zeev enforced so much to put on my
head, and I think he did it very well.
By changing the rules of how major PHP enthusiasts except the ones
with SVN karma is really bad. If you're not a maintainer of the
language, who are the people that wants to move PHP forward? The PHP
tools' project leaders. By denying the voice of them is almost the
same as telling there's meritocracy only if you contribute with the
language internals.From now on, you might be anxious waiting for my email to finish to
start a reply. Before do that, please continue to read.I want to highlight another RFC where I saw the before mentioned
meritocracy fallen into the cracks.
http://wiki.php.net/rfc/shortsyntaxforarrays
I just want you to read the conclusion. It doesn't matter the content
of RFC, just the conclusion. If I could vote on that again, I'd have
changed my vote because I found out the complexity of having it
implemented after evaluating the patch. But that doesn't take out the
matter of that conclusion. If PHP is a meritocracy based language, I
thought that everyone have equally voice over it. It doesn't matter if
it's php-src SVN karma, php-doc karma, php-website or even user that
actively participates on mailing list. But that conclusion just state
to me that meritocracy does not exist. We could have +Hundreds/-0 of
userland and 0/-Everyone of PHP core and this feature would not be
implemented. Why? That RFC exposed correctly. Because userland does
not have voice.
But wait, the language exists for developers, userland, right? But if
they don't have voice, then the language is just a playground of a
few, that only when something "cool" is requested for core, it gets
implemented. Sorry, but this is not meritocracy, it's a programming
hobby.I can even highlight another example, but I'm very afraid to mention
it here because I may be completely ignored. Annotations. How many
times I've heard "Oh no, that subject again, I should not connect
today" from some of you. It took me three attempts to improve the
language to finally understand that you only accept what you want, not
what others want. And even if strong pro arguments, if the RFC isn't
the exact same thing you want, you would never accept. I got many
prompt responses of "it would never be in core", "we won't touch the
symbol table", "if it doesn't belong to pecl, it would never be in
core", "do it in docblocks or it will never be implemented". We invest
tons of hours until we finally implement that by themselves and tried
again, and again and again. I questioned multiple times for RFC
stability and all I got was "it won't be implemented" or simply
ignored. I didn't even had a change to make a poll.Some would simply say "he only did that because he got 3 proposals
rejected". Others would say "he is pressuring A to be in PHP". But
not. I learned the hard way and multiple times to hear a big NO. But
at the same time, I earn my salary from a language that is lead by
people that do only what they want, not what the language really
needs. PHP is a mess, everyone knows it. You have the power to change
that, to make it right. But only you can do that, only you can approve
someone's SVN karma, only you can vote and accept/reject something,
according to what you defined. We (I'm putting myself into userland
now) can only watch, without a single voice. If we can change and make
the language better somehow, one of these steps to achieve it is
broken. And I would love to know which one it is, so we can workaround
it.Now I come back to original subject. Do you still think PHP is
meritocracy based?
Ok, you can start a reply. =)
Hi,
I will just answer the parts what I think Rasmus or Stas didn't addressed
or I have different opinion:
"You all discussed every single argument of voting RFC and approved it"
nope, the arguments were brought up(
internals@lists.php.net/msg51580.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg51580.html), but one
of the rfc authors expressed that we shouldn't over regulate that part and
we define it later.
internals@lists.php.net/msg51594.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg51594.html
internals@lists.php.net/msg51657.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg51657.html
internals@lists.php.net/msg51629.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg51629.html
So the RFC was pushed for voting, and the majority of the voters thought
that the mentioned problems can be sorted out later.
And I would like to do just like that, because I think that it is better
for all parties if we have a set of rules which we can comply.
Stas and Rasmus both expressed that they think that not everybody's vote is
equal, and as you pointed out, we already seen cases, where a vote was
canceled because a good number of the core-devs was against it.
It doesn't matter from the RFC point of view that what is my personal
opinion on who can vote, the most important thing is having a clearly
specified document explaining it unambiguously the rules of voting, because
that is the only way to not have those "yes, you win, but still no cookie
for you" moments.
"While I tend to agree the voting process is broken and that it should be
changed, I also consider that the voting process shouldn't be changed
DURING a voting of another RFC. "
I think you misunderstood this, I didn't brought up this topic, to change
the votes on you RFC (and there would be hardly possible to discuss this in
details, wait the 2 weeks then set it up for voting before the voting would
be finished on your RFC) and it would be really a bad idea to do that.
I brought this up now, because we faced now with the problem that there is
no process handling out accounts to the community reps, and if we start
giving out those for every project lead(if I remember correctly just the
standards group had 18 voters, that could turn the table for most RFC) it
will be inevitably brought up that all votes are really equal or not.
So I thought that we should be all on the same page about this, and our
voting process should be clear for everyone, so there are no surprises.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Some would simply say "he only did that because he got 3 proposals
rejected". Others would say "he is pressuring A to be in PHP". But not.
I learned the hard way and multiple times to hear a big NO. But at the
same time, I earn my salary from a language that is lead by people
that do only what they want, not what the language really needs. PHP
is a mess, everyone knows it. You have the power to change that, to
make it right.
spl_autoload_register('SplAutoLoader');
class_exists('Foo'); // Fatal error
is_a('Foo', 'Bar', true); // Fatal error
is_subclass_of('Foo', 'Bar'); // Fatal error
How exactly is PSR-0 making the language better? It's inconsistent with what's in core.
That said, I don't think there's anything wrong with bringing the className => fileMapping convention of PSR-0 in core.
Small political note: I trust decision making in php to people who understand the internals of the language (on a majority that's the core devs).
Other political note: PSR-0 seems to imply that your 'standard project' should have a particular directory structure:
https://github.com/lapistano/fig-standards/tree/compatibilityTests/
Is this right, wrong, for the better good?
Hi Jonathan,
Some would simply say "he only did that because he got 3 proposals
rejected". Others would say "he is pressuring A to be in PHP". But not.
I learned the hard way and multiple times to hear a big NO. But at the
same time, I earn my salary from a language that is lead by people
that do only what they want, not what the language really needs. PHP
is a mess, everyone knows it. You have the power to change that, to
make it right.spl_autoload_register('SplAutoLoader');
class_exists('Foo'); // Fatal error
is_a('Foo', 'Bar', true); // Fatal error
is_subclass_of('Foo', 'Bar'); // Fatal errorHow exactly is PSR-0 making the language better? It's inconsistent with what's in core.
That said, I don't think there's anything wrong with bringing the className => fileMapping convention of PSR-0 in core.
Small political note: I trust decision making in php to people who understand the internals of the language (on a majority that's the core devs).
Other political note: PSR-0 seems to imply that your 'standard project' should have a particular directory structure:
https://github.com/lapistano/fig-standards/tree/compatibilityTests/Is this right, wrong, for the better good?
Please keep the focus on the subject.
It's part of another thread, do not mix the things. =)
Cheers,
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
However, and it is what we approved, OSS project leads have a voice,
today and here. And they are not random people, they know sometimes
much better than us what should be added to the core (be language, or
functions in an extension like spl).
Well, I would like to make a point here. Right now, and the
discussion here is that people who contribute to the core and OSS
project leads get a say in the language. What would happen if Google
chose to use PHP instead of Python. Would they get a voice? Should
they get a voice? (even if it's just a single vote)...? What about
professional lead/senior developers who use and develop large and high
traffic sites off the language? What about the sysadmins and/or OS
package maintainers who implement and maintain the language for mass
adoption? What about the individual hosts that contribute so much to
the traction and adoption of PHP as a whole? Do any of them get a
say?
I'm not saying that they should or should not. But I feel it's kind
of back-handed to put OSS project leads up to a voting position and
deny that same position to so many others that have as big (if not a
bigger) impact on the adoption and evolution of the language.
I'm not suggesting how to handle that (or if it even needs to be
handled at all). All I wanted to do is point out the apparent
hypocrisy with it.
Just my $0.02...
Anthony
On Thu, Nov 10, 2011 at 9:00 AM, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:
Hi Jonathan,
Some would simply say "he only did that because he got 3 proposals
rejected". Others would say "he is pressuring A to be in PHP". But not.
I learned the hard way and multiple times to hear a big NO. But at the
same time, I earn my salary from a language that is lead by people
that do only what they want, not what the language really needs. PHP
is a mess, everyone knows it. You have the power to change that, to
make it right.spl_autoload_register('SplAutoLoader');
class_exists('Foo'); // Fatal error
is_a('Foo', 'Bar', true); // Fatal error
is_subclass_of('Foo', 'Bar'); // Fatal errorHow exactly is PSR-0 making the language better? It's inconsistent with what's in core.
That said, I don't think there's anything wrong with bringing the className => fileMapping convention of PSR-0 in core.
Small political note: I trust decision making in php to people who understand the internals of the language (on a majority that's the core devs).
Other political note: PSR-0 seems to imply that your 'standard project' should have a particular directory structure:
https://github.com/lapistano/fig-standards/tree/compatibilityTests/Is this right, wrong, for the better good?
Please keep the focus on the subject.
It's part of another thread, do not mix the things. =)Cheers,
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
However, and it is what we approved, OSS project leads have a voice,
today and here. And they are not random people, they know sometimes
much better than us what should be added to the core (be language, or
functions in an extension like spl).
Well, I would like to make a point here. Right now, and the
discussion here is that people who contribute to the core and OSS
project leads get a say in the language. What would happen if Google
chose to use PHP instead of Python. Would they get a voice? Should
they get a voice? (even if it's just a single vote)...? What about
professional lead/senior developers who use and develop large and high
traffic sites off the language? What about the sysadmins and/or OS
package maintainers who implement and maintain the language for mass
adoption? What about the individual hosts that contribute so much to
the traction and adoption of PHP as a whole? Do any of them get a
say?
All of these people do have a voice, and some weight, what they do not
have is equal weight, or an equal vote (if any vote at all).
Once a php contributor has become familiar with the different players,
and who, and what, they represent, they can selectively evaluate
individual arguments based on their weight. Without naming (outing?)
specific user names, I can say that no less than three of the top ten
websites (on the planet) have voices, and representation, in the
various arguments and discussions here. The largest install bases of
the most popular PHP applications also carry weight here. Same with
frameworks, cross-compilers, etc.
There is also the weight, and arguments, of users who have hundreds,
or even just one (with low traffic), website/project based on php...
but their arguments are often far outweighed by the arguments of those
who represent the needs of thousands, or millions, of websites and
users.
-Ronabop
Ronald,
Very well said. Thanks for the clarification.
Anthony
However, and it is what we approved, OSS project leads have a voice,
today and here. And they are not random people, they know sometimes
much better than us what should be added to the core (be language, or
functions in an extension like spl).
Well, I would like to make a point here. Right now, and the
discussion here is that people who contribute to the core and OSS
project leads get a say in the language. What would happen if Google
chose to use PHP instead of Python. Would they get a voice? Should
they get a voice? (even if it's just a single vote)...? What about
professional lead/senior developers who use and develop large and high
traffic sites off the language? What about the sysadmins and/or OS
package maintainers who implement and maintain the language for mass
adoption? What about the individual hosts that contribute so much to
the traction and adoption of PHP as a whole? Do any of them get a
say?All of these people do have a voice, and some weight, what they do not
have is equal weight, or an equal vote (if any vote at all).Once a php contributor has become familiar with the different players,
and who, and what, they represent, they can selectively evaluate
individual arguments based on their weight. Without naming (outing?)
specific user names, I can say that no less than three of the top ten
websites (on the planet) have voices, and representation, in the
various arguments and discussions here. The largest install bases of
the most popular PHP applications also carry weight here. Same with
frameworks, cross-compilers, etc.There is also the weight, and arguments, of users who have hundreds,
or even just one (with low traffic), website/project based on php...
but their arguments are often far outweighed by the arguments of those
who represent the needs of thousands, or millions, of websites and
users.-Ronabop