# who can vote - Thread: https://externals.io/message/56183 - Original archive: https://news-web.php.net/php.internals/56183 - Started by Ferenc Kovacs on 2011-11-09T08:07:34+00:00 - Messages: 39 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/56183.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #56183 — Ferenc Kovacs — 2011-11-09T08:07:34+00:00 URL: https://externals.io/message/56183#56183 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 --- ## #56187 — Ronald Chmara — 2011-11-09T10:31:13+00:00 URL: https://externals.io/message/56183#56187 · In reply to: #56183 > 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: 1. If you haven't contributed into src in 5 years, you must be "NEW". 2. If you want PHP to work like 3. "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 --- ## #56193 — Nikita Popov — 2011-11-09T15:20:01+00:00 URL: https://externals.io/message/56183#56193 · In reply to: #56183 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_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 --- ## #56199 — Ferenc Kovacs — 2011-11-09T18:10:06+00:00 URL: https://externals.io/message/56183#56199 · In reply to: #56193 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 --- ## #56201 — Nikita Popov — 2011-11-09T19:43:00+00:00 URL: https://externals.io/message/56183#56201 · In reply to: #56199 > - 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 --- ## #56202 — Stas Malyshev — 2011-11-09T20:04:52+00:00 URL: https://externals.io/message/56183#56202 · In reply to: #56201 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 --- ## #56203 — Nikita Popov — 2011-11-09T20:17:16+00:00 URL: https://externals.io/message/56183#56203 · In reply to: #56202 > > […] > 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. > > […] > 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 --- ## #56205 — Stas Malyshev — 2011-11-09T21:51:20+00:00 URL: https://externals.io/message/56183#56205 · In reply to: #56203 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 --- ## #56211 — guilhermeblanco@gmail.com — 2011-11-10T03:01:34+00:00 URL: https://externals.io/message/56183#56211 · In reply to: #56205 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! > > > […] > > 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 --- ## #56212 — Rasmus Lerdorf — 2011-11-10T04:51:19+00:00 URL: https://externals.io/message/56183#56212 · In reply to: #56211 > 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 --- ## #56213 — Stas Malyshev — 2011-11-10T07:12:39+00:00 URL: https://externals.io/message/56183#56213 · In reply to: #56211 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 --- ## #56215 — Ferenc Kovacs — 2011-11-10T07:53:06+00:00 URL: https://externals.io/message/56183#56215 · In reply to: #56211 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( 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. http://www.mail-archive.com/internals@lists.php.net/msg51594.html http://www.mail-archive.com/internals@lists.php.net/msg51657.html 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 --- ## #56216 — Pierre Joye — 2011-11-10T08:36:40+00:00 URL: https://externals.io/message/56183#56216 · In reply to: #56213 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 --- ## #56217 — Rasmus Lerdorf — 2011-11-10T09:32:41+00:00 URL: https://externals.io/message/56183#56217 · In reply to: #56216 > 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 --- ## #56219 — Pierre Joye — 2011-11-10T09:39:09+00:00 URL: https://externals.io/message/56183#56219 · In reply to: #56217 > > > […] > > 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 --- ## #56222 — Stas Malyshev — 2011-11-10T10:07:52+00:00 URL: https://externals.io/message/56183#56222 · In reply to: #56216 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 --- ## #56223 — Hannes Magnusson — 2011-11-10T10:09:57+00:00 URL: https://externals.io/message/56183#56223 · In reply to: #56219 > > > […] > > 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 --- ## #56225 — Jonathan Bond-Caron — 2011-11-10T13:12:57+00:00 URL: https://externals.io/message/56183#56225 · In reply to: #56211 > > 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? --- ## #56226 — Pierre Joye — 2011-11-10T13:46:06+00:00 URL: https://externals.io/message/56183#56226 · In reply to: #56222 > Hi! > > > […] > 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? > > […] > > 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 --- ## #56227 — guilhermeblanco@gmail.com — 2011-11-10T13:53:59+00:00 URL: https://externals.io/message/56183#56227 · In reply to: #56212 Hi Rasmus, Comments inline. > > > […] > > It is. I'd rather say "wort of, when interesting". > > > […] > > 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. 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. > > > […] > > 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 --- ## #56228 — guilhermeblanco@gmail.com — 2011-11-10T14:00:20+00:00 URL: https://externals.io/message/56183#56228 · In reply to: #56225 Hi Jonathan, > > > […] > > 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? > > > 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 --- ## #56234 — Anthony Ferrara — 2011-11-10T16:09:05+00:00 URL: https://externals.io/message/56183#56234 · In reply to: #56228 > 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 wrote: > Hi Jonathan, > > > > […] > > 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 --- ## #56236 — Rasmus Lerdorf — 2011-11-10T16:40:43+00:00 URL: https://externals.io/message/56183#56236 · In reply to: #56227 > 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 --- ## #56237 — Stas Malyshev — 2011-11-10T17:38:55+00:00 URL: https://externals.io/message/56183#56237 · In reply to: #56226 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 --- ## #56238 — Pierre Joye — 2011-11-10T17:44:26+00:00 URL: https://externals.io/message/56183#56238 · In reply to: #56236 > 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 --- Next page: https://externals.io/message/56183.md?page=2