On Thu, Nov 10, 2011 at 4:01 AM, guilhermebla...@gmail.com < guilhermebla...@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
