# [VOTE]Call for voting: support use list in foreach - Thread: https://externals.io/message/62518 - Original archive: https://news-web.php.net/php.internals/62518 - Started by Andrew Faulds on 2012-08-26T18:02:50+00:00 - Messages: 20 - 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 --- ## #62518 — Andrew Faulds — 2012-08-26T18:02:50+00:00 URL: https://externals.io/message/62518#62518 They don't, you need voting karma too, having rfc karma isn't enough. And this is how democracy works, Stas. If voters don't bother to turn up, too bad. -- Sent from Samsung Mobile Andrew Faulds http://ajf.me/ Yahav Gindi Bar wrote: On Sun, Aug 26, 2012 at 8:42 PM, Stas Malyshev wrote: > Hi! > > > […] >  denied. > > And here's again the problem with this voting setup. With all these long > discussions about people not getting votes we have 15 people that > bothered to vote at all, and essentially the vote is decided by one or > two single votes, and the vote doesn't even have to be from a PHP > contributor - but the vote of anybody who can register on PHP wiki is > enough to decide questions on the core of the language. And I'm not > talking about "the voice of the masses" there but by a single vote of > anybody who bothers to vote, which 99% of people just do not. > > I do not this it is a healthy state of things. Sorry to raise the topic > that was discussed 1000 times before, but the situation does not seem to > improve. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > > > > I got a PHP Wiki account but couldn't vote. Are you sure the Wiki accounts got the permissions to vote? --- ## #62519 — Yahav Gindi Bar — 2012-08-26T18:13:47+00:00 URL: https://externals.io/message/62518#62519 · In reply to: #62518 > They don't, you need voting karma too, having rfc karma isn't enough. > > Just what I thought, but because he said that wiki account should have the kama I've brought this up. Personally, I think it's good and really make sense~ > And this is how democracy works, Stas. If voters don't bother to turn up, > too bad. > > Yes, but even in democracy there's a minimum votes rate... I don't think that core decision should be done using 15 votes... > > -- > Sent from Samsung Mobile > Andrew Faulds > http://ajf.me/ > > > > Yahav Gindi Bar wrote: > > > On Sun, Aug 26, 2012 at 8:42 PM, Stas Malyshev > […] > > > […] > > > […] > I got a PHP Wiki account but couldn't vote. Are you sure the Wiki accounts > got the permissions to vote? --- ## #62522 — Stas Malyshev — 2012-08-26T18:20:41+00:00 URL: https://externals.io/message/62518#62522 · In reply to: #62518 Hi! > And this is how democracy works, Stas. If voters don't bother to turn > up, too bad. Putting aside the fact that democracy has very little to do with what we're trying to do here (we're not government, we're opensource project), that's how democracy *doesn't work*. As you noticed, it is "too bad", and it is exactly the problem we're having - without participation, votes are decided by a random sample of whoever bothered to appear, often on a single vote. This is not a way to build consensus. It is a very unhealthy state of things, and it only contributes to the image of PHP as a project having no direction, no governance and basically existing in a state of brownian motion. I thought we were trying to shed this image. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #62523 — Peter Cowburn — 2012-08-26T18:29:30+00:00 URL: https://externals.io/message/62518#62523 · In reply to: #62522 > Putting aside the fact that democracy has very little to do with what > we're trying to do here (we're not government, we're opensource > project), that's how democracy *doesn't work*. As you noticed, it is > "too bad", and it is exactly the problem we're having - without > participation, votes are decided by a random sample of whoever bothered > to appear, often on a single vote. > This is not a way to build consensus. It is a very unhealthy state of > things, and it only contributes to the image of PHP as a project having > no direction, no governance and basically existing in a state of > brownian motion. I thought we were trying to shed this image. For what it's worth, I have been following the RFC and internals threads on this topic and even after all that still have no strong opinion one way or the other. If there was an "on the fence" option in the polls, I would have chosen that. I did not toss a coin and choose one or the other purely because when there are so few votes, every one is significant — lets let those who feel they have put the time and effort* into coming to a conclusion have their say. (* lets hope that's the case anyway) --- ## #62525 — Gustavo Lopes — 2012-08-26T18:41:26+00:00 URL: https://externals.io/message/62518#62525 · In reply to: #62522 On Sun, 26 Aug 2012 20:20:41 +0200, Stas Malyshev wrote: > Putting aside the fact that democracy has very little to do with what > we're trying to do here (we're not government, we're opensource > project), that's how democracy *doesn't work*. As you noticed, it is > "too bad", and it is exactly the problem we're having - without > participation, votes are decided by a random sample of whoever bothered > to appear, often on a single vote. > This is not a way to build consensus. It is a very unhealthy state of > things, and it only contributes to the image of PHP as a project having > no direction, no governance and basically existing in a state of > brownian motion. I thought we were trying to shed this image. I honestly don't see what the problem is. If the sample is indeed random, there's no bias as to what the voters as whole would do, tough for close votes or for votes where very few people vote the result could differ. But most importantly, I would prefer that the people voting actually thought hard about the proposal. And it's more likely (I think) that people who invested time in that process and in the discussion actually voted. So this way we get more knowledgeable voters on average than if, say, 90% of the people voted (because a large part of the voting population doesn't care about many of the proposals). In fact, I think that in this model, we still get a lot of people that vote without a clue; a model with an elected committee could make more sense. -- Gustavo Lopes --- ## #62526 — Ferenc Kovacs — 2012-08-26T18:44:32+00:00 URL: https://externals.io/message/62518#62526 · In reply to: #62522 On Sun, Aug 26, 2012 at 8:20 PM, Stas Malyshev wrote: > Hi! > > > […] > > Putting aside the fact that democracy has very little to do with what > we're trying to do here (we're not government, we're opensource > project), that's how democracy *doesn't work*. As you noticed, it is > "too bad", and it is exactly the problem we're having - without > participation, votes are decided by a random sample of whoever bothered > to appear, often on a single vote. > This is not a way to build consensus. It is a very unhealthy state of > things, and it only contributes to the image of PHP as a project having > no direction, no governance and basically existing in a state of > brownian motion. I thought we were trying to shed this image. > To make things a little bit clear. The members of the 'admin', 'phpcvs', 'voting' groups can vote. The admin and voting group membership is handed out on case-by-case basis (although we don't have an open process for that), and the phpcvs group membership is granted when somebody logs in with a php.net account, so anybody with a php.net account can vote by default. Last time when I asked, I was told, that only 3 people has membership of the voting group(dunno who handed out those), so they don't have a significant presence in the voting. Of course if we would actively would handle out accounts to active community reps and such (which was somehow defined by and accepted with the voting rfc) you concern could be real given that the active people seems to be more active than the average person out of the ~3000 people with php.netaccount. Your other concern, that votes can win by a small margin: The voting RFC states that syntax or other major changes require 2/3 of the votes, other changes require simple majority (50%+1 vote). The minimal discussion period, and minimal voting period was added that there is enough time for the voters to understand the topic and hand, and make their votes. So we could either raise the required numbers, or the voting time period, or we could create some arbitary number of minimal votes, but non of those issues would fix our base problem: the lack of participation of the voters. Of course, it would prevent us from accepting RFCs without a proper evaluation, but it could also prevent us from accepting anything. I think that the voting rfc itself is a good example of another problem: accepting RFCs based on the subjective intention, instead of the actual specification/implementation (or in the voting RFCs case, the lack of clear specification in some areas). Maybe now that we have some experience with the current process we could create an improved version or an addition to the voting rfc. What do you think? -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #62527 — Yahav Gindi Bar — 2012-08-26T19:01:27+00:00 URL: https://externals.io/message/62518#62527 · In reply to: #62526 > > > On Sun, Aug 26, 2012 at 8:20 PM, Stas Malyshev wrote: > > > […] > > To make things a little bit clear. > The members of the 'admin', 'phpcvs', 'voting' groups can vote. > The admin and voting group membership is handed out on case-by-case basis > (although we don't have an open process for that), and the phpcvs group > membership is granted when somebody logs in with a php.net account, so > anybody with a php.net account can vote by default. > Last time when I asked, I was told, that only 3 people has membership of > the voting group(dunno who handed out those), so they don't have a > significant presence in the voting. > Of course if we would actively would handle out accounts to active > community reps and such (which was somehow defined by and accepted with the > voting rfc) you concern could be real given that the active people seems to > be more active than the average person out of the ~3000 people with > php.net account. > > Your other concern, that votes can win by a small margin: > The voting RFC states that syntax or other major changes require 2/3 of > the votes, other changes require simple majority (50%+1 vote). > The minimal discussion period, and minimal voting period was added that > there is enough time for the voters to understand the topic and hand, and > make their votes. > > So we could either raise the required numbers, or the voting time period, > or we could create some arbitary number of minimal votes, but non of those > issues would fix our base problem: the lack of participation of the voters. > Of course, it would prevent us from accepting RFCs without a proper > evaluation, but it could also prevent us from accepting anything. > > I think that the voting rfc itself is a good example of another problem: > accepting RFCs based on the subjective intention, instead of the actual > specification/implementation (or in the voting RFCs case, the lack of clear > specification in some areas). > > Maybe now that we have some experience with the current process we could > create an improved version or an addition to the voting rfc. > What do you think? > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu > I agree with the theoretical idea, but I don't see any other way to achieve good decision. We can't make peoples participate in the discussions so give peoples a vote without making sure they have good knowledge and they can be "trusted" is not a good thing. The main problem is the lack of participates. Um.. I thought about two ideas, not so good - but they can be improved to be an alternative: - We can try to contact the top popular PHP blogs and websites and request them to publish the discussed idea including all the required knowledge and theory about it and with it publish a poll. taking the results of the poll and add them to the internal poll. You can say that "peoples in this websites don't know well about this" - so we can, for example, divide the poll results by 2 and then add them. - My second idea is to give, in addition to the users who got regular vote permission, a permission to vote in the specific topic if they participate in the discussion - for example, each user who got more than X posts in discussion that contains Y posts can vote too. --- ## #62532 — Stas Malyshev — 2012-08-26T20:20:03+00:00 URL: https://externals.io/message/62518#62532 · In reply to: #62525 Hi! > I honestly don't see what the problem is. If the sample is indeed random, > there's no bias as to what the voters as whole would do, tough for close > votes or for votes where very few people vote the result could differ. The problem is that this is not consensus, this is apathy and disfunction. If out of 100 or 1000 or whatever we have project participants we can barely find a dozen that want to support a particular change - can we really say this change has the support of the developer community? > But most importantly, I would prefer that the people voting actually > thought hard about the proposal. And it's more likely (I think) that I'd prefer that too. That's another problem with votes which I did talk about in the past too. However, right now we do not have any guarantee that those 10 people that voted are those that thought hard about the proposal, and not just saw it first time yesterday and thought "neat, let's do it, I'll spend as much time on it as it takes to click 'yes' button". I want to emphasize here I don't mean anybody in particular that would do that (I hope nobody does), I am just saying we do not have any way of knowing that, so if you're concerned about that current situation is not ideal. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #62544 — Kris Craig — 2012-08-27T01:18:22+00:00 URL: https://externals.io/message/62518#62544 · In reply to: #62532 On Sun, Aug 26, 2012 at 1:20 PM, Stas Malyshev wrote: > Hi! > > > […] > > The problem is that this is not consensus, this is apathy and > disfunction. If out of 100 or 1000 or whatever we have project > participants we can barely find a dozen that want to support a > particular change - can we really say this change has the support of the > developer community? > > > […] > > I'd prefer that too. That's another problem with votes which I did talk > about in the past too. However, right now we do not have any guarantee > that those 10 people that voted are those that thought hard about the > proposal, and not just saw it first time yesterday and thought "neat, > let's do it, I'll spend as much time on it as it takes to click 'yes' > button". I want to emphasize here I don't mean anybody in particular > that would do that (I hope nobody does), I am just saying we do not have > any way of knowing that, so if you're concerned about that current > situation is not ideal. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > > > > I agree that can be a problem. However, I'm not sure what a viable solution would be. After all, Democracy or not, lack of participation can be crippling to a project. The obvious answer would be to increase participation somehow, but that's much easier said than done. It's even worse for us since PHP is written in C, which makes the learning curve for potential new contributors intimidatingly (and perhaps even prohibitively) steep. Short of killing ourselves rewriting it in C++, I'm not sure there is an ideal solution to this problem. --Kris --- ## #62545 — Rasmus Lerdorf — 2012-08-27T01:22:37+00:00 URL: https://externals.io/message/62518#62545 · In reply to: #62544 > Short of killing ourselves rewriting it in C++, I'm not sure there > is an ideal solution to this problem. Because you think more people can grok C++ than C? That's not my experience. C is essentially a subset of C++. Any strong C++ developer (I think I have only ever met 2 of those) will know C inside out. -Rasmus --- ## #62546 — Kris Craig — 2012-08-27T01:34:08+00:00 URL: https://externals.io/message/62518#62546 · In reply to: #62545 > > > […] > > Because you think more people can grok C++ than C? That's not my > experience. C is essentially a subset of C++. Any strong C++ developer > (I think I have only ever met 2 of those) will know C inside out. > I agree. But keyword there is "strong" lol. In terms of volume, I've noticed there are far more C++ and C# developers out there who don't know a lick of C. Makes sense if you think about it, as both are designed to make the job easier, which in turn also reduces the learning curve. When I browse through local college offerings in programming, it's not uncommon for me to see C++ emphasized with no mention of C. I've always likened it to learning to drive on an automatic transmission, whereas learning in C is like learning to drive a stick. It's harder and most people don't do it anymore, even though it's far more beneficial in the long-run. I guess the premise I was alluding to was that, if PHP was written in C++, there would be a much larger *quantity* of developers with a compatible skillset. You're right in that most of them would almost certainly be lacking in quality, but it would theoretically increase participation nonetheless IMNSHO. ;) --Kris > > -Rasmus --- ## #62547 — Gwynne Raskind — 2012-08-27T01:39:38+00:00 URL: https://externals.io/message/62518#62547 · In reply to: #62545 > > > […] > > Because you think more people can grok C++ than C? That's not my > experience. C is essentially a subset of C++. Any strong C++ developer > (I think I have only ever met 2 of those) will know C inside out. > > -Rasmus That's where it gets ugly, in my experience; there are lots of mediocre C++ developers (and legions of even expert PHP/JavaScript/Python/Ruby/etc. devs) who couldn't so much as use a pointer without around to check their NULLs and do their deletes for them. LLVM is written in C++, and all that's done is raise the barrier of entry. C++ enables countless idioms that haven't made it into as high-level a language as PHP itself because of the potential for massive abuse (unchecked operator overloads, for one example). Basically, I expect that going to C++ would do nothing but encourage less talented people to do much more of the work, and the result would be a hopeless tangle (what we have now is a tangle, but at least it's not hopeless). My intention isn't to turn this into a language flame war, of course, but if you want to talk about rewriting PHP itself in a language that doesn't require all the dancing around that C does (with zval, for example), C++ is hardly the answer unless it's possible to enforce coding guidelines even more strictly than has already been done. (And a side note on that, the requirement of C89 standard compliance in PHP has less and less advantage these days, and handicaps those few language features in the later flavors of C (C99, gnu99, Clang C, etc.) which -could- lessen the current unreadability of the code.) -- Gwynne --- ## #62548 — Rasmus Lerdorf — 2012-08-27T01:40:38+00:00 URL: https://externals.io/message/62518#62548 · In reply to: #62546 > > > On Sun, Aug 26, 2012 at 6:22 PM, Rasmus Lerdorf > wrote: > > > > […] > > Because you think more people can grok C++ than C? That's not my > experience. C is essentially a subset of C++. Any strong C++ developer > (I think I have only ever met 2 of those) will know C inside out. > > > I agree. But keyword there is "strong" lol. In terms of volume, I've > noticed there are far more C++ and C# developers out there who don't > know a lick of C. Makes sense if you think about it, as both are > designed to make the job easier, which in turn also reduces the learning > curve. When I browse through local college offerings in programming, > it's not uncommon for me to see C++ emphasized with no mention of C. > I've always likened it to learning to drive on an automatic > transmission, whereas learning in C is like learning to drive a stick. > It's harder and most people don't do it anymore, even though it's far > more beneficial in the long-run. > > I guess the premise I was alluding to was that, if PHP was written in > C++, there would be a much larger /quantity/ of developers with a > compatible skillset. You're right in that most of them would almost > certainly be lacking in quality, but it would theoretically increase > participation nonetheless IMNSHO. ;) That doesn't make any sense because they still wouldn't be able to understand the code. If you can't read a PHP written in C you definitely won't be able to read a PHP written in C++. And it would still be a yacc grammar or perhaps antlr and if you don't know the difference between a LALR and an LL grammar which language these tools spit out isn't going to make any difference at all. There are way more complicated concepts involved here than the implementation language. -Rasmus --- ## #62550 — Lars Strojny — 2012-08-27T01:48:17+00:00 URL: https://externals.io/message/62518#62550 · In reply to: #62547 Hi Gwynne, Am 27.08.2012 um 03:39 schrieb Gwynne Raskind : > (And > a side note on that, the requirement of C89 standard compliance in PHP > has less and less advantage these days, and handicaps those few > language features in the later flavors of C (C99, gnu99, Clang C, > etc.) which -could- lessen the current unreadability of the code.) OT but because I stumbled upon that some time ago: what was the original reason to enforce C89 and what would be needed to allow a modern standard? With regards, Lars --- ## #62551 — Rasmus Lerdorf — 2012-08-27T01:55:52+00:00 URL: https://externals.io/message/62518#62551 · In reply to: #62550 > Hi Gwynne, > > Am 27.08.2012 um 03:39 schrieb Gwynne Raskind : > > > […] > > OT but because I stumbled upon that some time ago: what was the original reason to enforce C89 and what would be needed to allow a modern standard? Main reason was the lack of compiler support on some platforms. C89 was the lowest common denominator that gave us the widest possible platform support. And we aren't just C89 anymore actually. We still try to stick to it when possible, but for example in the intl extension you will find C++ and it won't build without it. The idea there is that any small embedded platform that may still only have C89 support is unlikely to link against the massive ICU library. But we may be at the point where even tiny embedded platforms have better compiler support and we don't need to stick to C89 anymore. -Rasmus --- ## #62552 — Lars Strojny — 2012-08-27T02:08:01+00:00 URL: https://externals.io/message/62518#62552 · In reply to: #62551 Am 27.08.2012 um 03:55 schrieb Rasmus Lerdorf : [...] > And we aren't just C89 anymore actually. We still try to stick to it > when possible, but for example in the intl extension you will find C++ > and it won't build without it. The idea there is that any small embedded > platform that may still only have C89 support is unlikely to link > against the massive ICU library. > > But we may be at the point where even tiny embedded platforms have > better compiler support and we don't need to stick to C89 anymore. If I understand Wikipedia (http://en.wikipedia.org/wiki/C99) correctly, C99 is not at all supported in MS Visual C++ (except non-standard extensions like __inline or __forceinline). So C99 might not be a good candidate for us just now. But I'm sure Pierre has more on that issue. With regards, Lars --- ## #62556 — Stas Malyshev — 2012-08-27T07:27:37+00:00 URL: https://externals.io/message/62518#62556 · In reply to: #62547 Hi! > That's where it gets ugly, in my experience; there are lots of > mediocre C++ developers (and legions of even expert > PHP/JavaScript/Python/Ruby/etc. devs) who couldn't so much as use a > pointer without around to > check their NULLs and do their deletes for them. As a person who used both C and C++ and had to figure out others' code written in C and C++, my experience is that C code is usually easier to figure out (unless it's written in some heavily macro-ed style - remember that C preprocessor is a separate functional language and if you mix the two you can make some fine mess there) because C++ has tons of magic you have always to keep in mind. Operator is never just an operator, assignment is never just an assignment, pointer dereference is never just a pointer dereference. There's magic in all of that. And don't get me started on multilevel templates and trying to figure that out. Of course, C++ gives you a nice means of hiding complexity. But if you're not careful, you'd hide it in a way that it's still there, but you are no longer able to figure out where it is. So if somebody thinks C++ is a panacea here - probably not. Some pieces of Zend Engine are genuinely complex because they do complex things. I don't think hiding it behind C++ would help us much. Yes, we'd earn some with making zval an object, but probably not as much as one would think. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #62559 — Hannes Magnusson — 2012-08-27T09:49:07+00:00 URL: https://externals.io/message/62518#62559 · In reply to: #62522 > Hi! > > > […] > > Putting aside the fact that democracy has very little to do with what > we're trying to do here (we're not government, we're opensource > project), that's how democracy *doesn't work*. As you noticed, it is > "too bad", and it is exactly the problem we're having - without > participation, votes are decided by a random sample of whoever bothered > to appear, often on a single vote. > This is not a way to build consensus. It is a very unhealthy state of > things, and it only contributes to the image of PHP as a project having > no direction, no governance and basically existing in a state of > brownian motion. I thought we were trying to shed this image. I couldn't agree more. Which is why I have been trying to preach http://producingoss.com/en/consensus-democracy.html -Hannes --- ## #62560 — Derick Rethans — 2012-08-27T12:23:01+00:00 URL: https://externals.io/message/62518#62560 · In reply to: #62518 > They don't, you need voting karma too, having rfc karma isn't enough. > > And this is how democracy works, Stas. If voters don't bother to turn up, too bad. Atleast if you post to this list, could you follow the guidelines? They are here: http://uk.php.net/reST/README.MAILINGLIST_RULES cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #62561 — Derick Rethans — 2012-08-27T12:23:58+00:00 URL: https://externals.io/message/62518#62561 · In reply to: #62522 > > […] > > Putting aside the fact that democracy has very little to do with what > we're trying to do here (we're not government, we're opensource > project), that's how democracy *doesn't work*. As you noticed, it is > "too bad", and it is exactly the problem we're having - without > participation, votes are decided by a random sample of whoever > bothered to appear, often on a single vote. > > This is not a way to build consensus. It is a very unhealthy state of > things, and it only contributes to the image of PHP as a project > having no direction, no governance and basically existing in a state > of brownian motion. I thought we were trying to shed this image. I very much agree with this. cheers, Derick