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 g.b.yahav@gmail.com wrote:
On Sun, Aug 26, 2012 at 8:42 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Hi!
foreach supports list syntax: 11 for yes, 4 for no. accepted.
foreach supports list with silent token: 2 for yes, 10 for no.
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?
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 g.b.yahav@gmail.com wrote:
On Sun, Aug 26, 2012 at 8:42 PM, Stas Malyshev <smalyshev@sugarcrm.com
wrote:
Hi!
foreach supports list syntax: 11 for yes, 4 for no. accepted.
foreach supports list with silent token: 2 for yes, 10 for no.
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?
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
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)
On Sun, 26 Aug 2012 20:20:41 +0200, Stas Malyshev smalyshev@sugarcrm.com
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
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
On Sun, Aug 26, 2012 at 1:20 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:
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) thatI'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
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
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.
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
On Sun, Aug 26, 2012 at 6:22 PM, Rasmus Lerdorf <rasmus@lerdorf.com
mailto:rasmus@lerdorf.com> wrote:> 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.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
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
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 <insert favorite C++ pointer wrapper here> 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
Hi Gwynne,
Am 27.08.2012 um 03:39 schrieb Gwynne Raskind gwynne@darkrainfall.org:
(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
Hi Gwynne,
Am 27.08.2012 um 03:39 schrieb Gwynne Raskind gwynne@darkrainfall.org:
(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?
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
Am 27.08.2012 um 03:55 schrieb Rasmus Lerdorf rasmus@lerdorf.com:
[...]
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
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 <insert favorite C++ pointer wrapper here> 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
On Sun, Aug 26, 2012 at 8:20 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:
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.
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
On Sun, Aug 26, 2012 at 8:20 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:
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.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.
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.
I couldn't agree more.
Which is why I have been trying to preach
http://producingoss.com/en/consensus-democracy.html
-Hannes
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.
I very much agree with this.
cheers,
Derick
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