Re: [PHP-DEV] RE: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
Am 05.06.2011 22:05, schrieb Zeev Suraski: - There wasn't sufficient time, or nearly any time at all - between when Brian pulled it off the attic, and when a vote was called. If my proposal is accepted, there'll have to be at least two weeks between when a clearly marked [RFC] email hits internals@, and when a vote is called. - There wasn't a clearly marked, separate [VOTE] email. - There wasn't a clear or easy way of voting. - No voting period was announced, instead, people were told to stop mess around and go vote. - The author of the RFC wasn't actively involved in the whole process (as far as I could tell); There was no official replacement proposer. These are all valid points. I'd still like to hear from others what they think about my proposal. If your proposal addresses the issue mentioned above: +1. Haven't had the time yet to read through it again, sorry. -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
-Original Message- From: Pierre Joye [mailto:pierre@gmail.com] Sent: Monday, June 06, 2011 1:46 AM To: Zeev Suraski Cc: PHP Internals Subject: Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)) In any case, if you feel like we have to re vote, and many do as well, then so be it. Let's do that, either that, or go with the old-style +1/-1 on-list until we adopt a voting process (which should hopefully be soon). I won't get around to review edit the new RFC that Stas prepared today (very busy day), but I promise to take a stab at it tomorrow. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
On 2011-06-05, Zeev Suraski z...@zend.com wrote: I'm fine if the entire 'Feature selection and development' part goes out of the RFC, but if there's any reference to how features are determined, we'd better get it right. Making changes once we've approved this RFC is going to be much tougher. This is big stuff - it's no coincidence we didn't have such guidelines for almost 15 years. Honestly there are other parts about the voting process that are much hotter potatoes than the points I brought up - such as who gets to vote, This is a tough one. I'm typically in favor of having the vote be completely open to anybody. However, since we're talking language features, there are a lot of other considerations -- internals folks will have a much better idea of what the BC and support ramifications are. Perhaps two votes should be considered? A general population vote, and an internals vote? This would show discrepancies between what users of PHP want, and how internals is voting. If internals votes against a feature that the general population has approved, I would expect to see some sort of executive summary showing what technical issues are at play that led to the internals vote. This would serve as a good historical record -- and also potentially show where bias lies within the internals community. is 50%+1 enough or do we need stronger majorities for substantial language changes (67%/75%), I think anything less than a strong majority (2/3 or 3/4) often is indicative of either ambivalence or strongly competing ideas. The question is where that threshold should be set (I'd lean towards 2/3 vote.) can someone who failed passing an RFC just put it up for another vote right away or is there some sort of a cool-off period, I'd argue a 2-3 week period in which to re-work the proposal and incorporate feedback from the prior discussion/voting periods. etc. etc. I think all of these need to be answered before we let this RFC govern how we do feature definition. Zeev -Original Message- From: Stas Malyshev [mailto:smalys...@sugarcrm.com] Sent: Sunday, June 05, 2011 11:17 PM To: Zeev Suraski Cc: Pierre Joye; PHP Internals Subject: Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)) Hi! I'd still like to hear from others what they think about my proposal. I'd like to update the Release Process RFC with these suggestions if people like them. I think these voting process additions totally make sense. But I am not sure it makes sense to put everything in one release RFC. The reason for that is that we don't want to endlessly amend and improve the RFC without having it actually agreed upon, I would rather prefer to agree on what we agree, have it as base for the future and then add other stuff. I've noticed a tendency on the list to lose the major goal behind endless amendments and tweaks and not doing what we agree on because we disagree on some minor detail. So maybe it would make sense to have release RFC separate (without spelling out the voting process there) and voting RFC separate which would define the voting process? -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
On Sun, Jun 5, 2011 at 5:20 PM, Pierre Joye pierre@gmail.com wrote: I'd to go with a 60% for language syntax, 50+1 for new exts or sapis. Other question is who can vote. For one, I like to have external people being able to vote, like frameworks/apps lead developers as well as @php.net in general (docs people at the same level than core devs, no diff). I have a little proposition here. I'm not —at least currently— known for any app or framework, but I'd like my voice to count, that is, if and only if the rest of the community thinks I make sane arguments that are worth considering. I'm perfectly aware that the fame one could gain from taking production code to visible success should be an indicator of an educated opinion, however, I think this might lead to a closed group who can vote, and I like the openness of this community, even if the general process is chaotic, it still gets the warm and fuzzy feeling of an open source community. OTOH, if a completely open group's votes were all considered, the final decision could just end up being a matter of numbers outnumbering other numbers. If I get it right, this is the current problem. So my proposal is that the voting privilege could be given on the basis of a *web of trust*, and if I'm not mistaken this is a little like what the concept of karma works here (I'm fairly new here). Not sure if there should be a voting to elect voters or if it could/should be something more lax, but I don't think the requirement to vote should be fame. Best regards, David
Re: [PHP-DEV] Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
On Mon, Jun 6, 2011 at 12:27 PM, dukeofgaming dukeofgam...@gmail.com wrote: I have a little proposition here. I'm not —at least currently— known for any app or framework, but I'd like my voice to count, that is, if and only if the rest of the community thinks I make sane arguments that are worth considering. I'm perfectly aware that the fame one could gain from taking production code to visible success should be an indicator of an educated opinion, however, I think this might lead to a closed group who can vote, and I like the openness of this community, even if the general process is chaotic, it still gets the warm and fuzzy feeling of an open source community. OTOH, if a completely open group's votes were all considered, the final decision could just end up being a matter of numbers outnumbering other numbers. If I get it right, this is the current problem. So my proposal is that the voting privilege could be given on the basis of a *web of trust*, and if I'm not mistaken this is a little like what the concept of karma works here (I'm fairly new here). Not sure if there should be a voting to elect voters or if it could/should be something more lax, but I don't think the requirement to vote should be fame. I'm similarly placed (as are many here I think), in the sense that I have not done any internals work and I am not one of the lead devs for a well-known project. Much as I think my opinions are great, I don't believe we should have a vote or, if we do, that it shouldn't count for as much as others', for the following reasons: - Long-term commitment: we want people voting who (1) know the history of past PHP discussions on topics and why they were rejected or postponed, (2) understand the PHP way, and (3) have shown commitment to *maintaining* PHP - Perspective: developing *with* PHP is not the same as developing *for* PHP internals. Feasibility, interoperability, maintenance concerns, and more are things that, as long as I've read the list, are often misunderstood or downplayed by people who develop *with* PHP and want a shiny new feature (including me). - Unified vision: we want people who are taking the whole PHP picture into account to be the ones doing the voting. Much of the volume on the list is very narrowly focused - this is a good thing for discussion of specific features, but a bad thing for picking which features to include in PHP. So, I would advocate a white list of core devs for formal voting (of which, for example, I would not be a member). I think this mailing list has grown sufficiently that public opinion can be gauged from here: everyone can write their opinion without giving them voting privileges. If you haven't already, I recommend you read the (incredibly long) discussions from last summer on type-hinting. They convinced me that sometimes a feature that sounds good is simply not a good fit for PHP for reasons which many did not (still do not?) understand. Chad Fulton -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
On 2011-06-06, Chad Fulton chadful...@gmail.com wrote: So, I would advocate a white list of core devs for formal voting (of which, for example, I would not be a member). I think this mailing list has grown sufficiently that public opinion can be gauged from here: everyone can write their opinion without giving them voting privileges. If you haven't already, I recommend you read the (incredibly long) discussions from last summer on type-hinting. They convinced me that sometimes a feature that sounds good is simply not a good fit for PHP for reasons which many did not (still do not?) understand. I think your analysis is great. That said, I think if this is the route ultimately taken, any time an RFC is voted out, a summary of the _technical_ reasons for denying it should be provided. Usually there are very good ones -- but this information can be invaluable to anybody who may want to ressurect the RFC in the future to ensure they don't hit the same pitfalls. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
Pierre, I'm happy that we agree pretty much completely about the clarifications updates needed for the RFC. I do however want to point out that the problematic way the short array syntax RFC was executed was the key reason that made me feel these updates were in fact necessary - I don't think that the way it was done was exemplary in any way... Pretty much each and every point in my email is based on things that I felt went wrong with how we handled the short array syntax RFC: - There wasn't sufficient time, or nearly any time at all - between when Brian pulled it off the attic, and when a vote was called. If my proposal is accepted, there'll have to be at least two weeks between when a clearly marked [RFC] email hits internals@, and when a vote is called. - There wasn't a clearly marked, separate [VOTE] email. - There wasn't a clear or easy way of voting. - No voting period was announced, instead, people were told to stop mess around and go vote. - The author of the RFC wasn't actively involved in the whole process (as far as I could tell); There was no official replacement proposer. I just want to make sure we're on the same page. If you feel that the array syntax RFC was 'done right' then we have a bit of a gap :) In my opinion, given the lacking process, the short array syntax RFC needs to be redone. I'd still like to hear from others what they think about my proposal. I'd like to update the Release Process RFC with these suggestions if people like them. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
For those of you who lost these proposals in the flood of RFC related emails of recent days, here they are again: --- First, we need to make sure that the RFC is properly evaluated by the members of internals@, and that there's enough time for the RFC to be discussed here on the list. As Philip pointed out - an RFC is request for comments, not a request for a vote. This list isn't supposed to become some sort of a bureaucratic voting body, but where new ideas are discussed, refined, and eventually - accepted or rejected. I realize that some here are worried that discussions can be endless, but we shouldn't go for the other extreme of having no discussion. For this reason, I propose the following: - There'd be a minimum amount of time between when an RFC is brought up on this list and when it's voted on (say 2wks). The effective date will not be when the RFC was published on wiki.php.net/rfc - but when it was announced on internals@, by the author, with the intention of voting on it. It doesn't matter if the RFC was up there for 2yrs, or discussed 20 times in the past - if the intention is to go for a vote, there needs to be time for a healthy discussion, as opposed to just yes/no. This will also allow for people who are attending conferences, are on vacations, etc. - not to miss an entire discussion/vote. - The announcement will be done in a way that's easy to flag follow, e.g. - by [RFC] in the subject line followed by the title of the RFC. Again, the effective date will start from the time this email is sent to the list, not any other time. - Eventually, it'll be up to the author to move ahead and call a vote on the RFC. That means that if the author feels that there's still healthy discussion going on, he can decide not to move ahead to request a vote after 2wks, but after 3 or 4wks. On the other hand, if he feels that the discussion is being derailed - he can always move ahead to a vote as long as the minimum discussion time elapsed. - In my opinion, only RFCs with active proposers should be discussed. If the proposer of an RFC is no longer leading the effort to get this RFC accepted - it should either find a new proposer, or it should be abandoned. Secondly - the announcement of the vote - I very much agree with Derick that having someone announce a vote in a thread of 50 messages (or even 10) messages is impractical. It needs to be a separate thread, and it has to be clearly marked - a simple subject prefix like [VOTE] followed by the title of the RFC should do. Thirdly, there's the voting mechanism itself. The voting experience has to be nicer than editing a wiki page, I think we all agree about that... The plugin Stas installed gets us something better than that, but ideally, if we could provide single-click URLs in the [VOTE] email itself for voting yay or nay that would be great. Last, we need a predefined time for voting. It too has to be sufficiently long so that everyone has a chance to cast their votes, and on the other end shouldn't be endless. I think the 1wk should do. If there's anybody who feels that the minimum 3wks period is too slow, it isn't. Any mistake we make can take a decade to fix, because downwards compatibility is such an important factor in PHP's design goals. Taking a bit of time to discuss the merits and contents of each RFC is well worth it, especially if we have rules and predefined schedules - so that discussions can't drag forever. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
Hi! I'd still like to hear from others what they think about my proposal. I'd like to update the Release Process RFC with these suggestions if people like them. I think these voting process additions totally make sense. But I am not sure it makes sense to put everything in one release RFC. The reason for that is that we don't want to endlessly amend and improve the RFC without having it actually agreed upon, I would rather prefer to agree on what we agree, have it as base for the future and then add other stuff. I've noticed a tendency on the list to lose the major goal behind endless amendments and tweaks and not doing what we agree on because we disagree on some minor detail. So maybe it would make sense to have release RFC separate (without spelling out the voting process there) and voting RFC separate which would define the voting process? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
I'm fine if the entire 'Feature selection and development' part goes out of the RFC, but if there's any reference to how features are determined, we'd better get it right. Making changes once we've approved this RFC is going to be much tougher. This is big stuff - it's no coincidence we didn't have such guidelines for almost 15 years. Honestly there are other parts about the voting process that are much hotter potatoes than the points I brought up - such as who gets to vote, is 50%+1 enough or do we need stronger majorities for substantial language changes (67%/75%), can someone who failed passing an RFC just put it up for another vote right away or is there some sort of a cool-off period, etc. etc. I think all of these need to be answered before we let this RFC govern how we do feature definition. Zeev -Original Message- From: Stas Malyshev [mailto:smalys...@sugarcrm.com] Sent: Sunday, June 05, 2011 11:17 PM To: Zeev Suraski Cc: Pierre Joye; PHP Internals Subject: Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)) Hi! I'd still like to hear from others what they think about my proposal. I'd like to update the Release Process RFC with these suggestions if people like them. I think these voting process additions totally make sense. But I am not sure it makes sense to put everything in one release RFC. The reason for that is that we don't want to endlessly amend and improve the RFC without having it actually agreed upon, I would rather prefer to agree on what we agree, have it as base for the future and then add other stuff. I've noticed a tendency on the list to lose the major goal behind endless amendments and tweaks and not doing what we agree on because we disagree on some minor detail. So maybe it would make sense to have release RFC separate (without spelling out the voting process there) and voting RFC separate which would define the voting process? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
On Sun, Jun 5, 2011 at 10:55 PM, Zeev Suraski z...@zend.com wrote: I'm fine if the entire 'Feature selection and development' part goes out of the RFC, but if there's any reference to how features are determined, we'd better get it right. Getting it totally out makes little sense as it brings us to the point where we have no idea how we decide what gets in or not, the RMs, etc. Making changes once we've approved this RFC is going to be much tougher. This is big stuff - it's no coincidence we didn't have such guidelines for almost 15 years. That was not the reason, the lack of will to define such processes was the reason despite the numerous requests to have one from in and outside the core team. Honestly there are other parts about the voting process that are much hotter potatoes than the points I brought up - such as who gets to vote, is 50%+1 enough or do we need stronger majorities for substantial language changes (67%/75%), can someone who failed passing an RFC just put it up for another vote right away or is there some sort of a cool-off period, etc. etc. I think all of these need to be answered before we let this RFC govern how we do feature definition. I'd to go with a 60% for language syntax, 50+1 for new exts or sapis. Other question is who can vote. For one, I like to have external people being able to vote, like frameworks/apps lead developers as well as @php.net in general (docs people at the same level than core devs, no diff). However I'd to say as well as I have no issue at all to define the basis of the voting system in it and add a note that it may be tuned later once we have more experiences. That's perfectly fine, nobody expects us to be perfect with the 1st shot. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
hi Zeev, On Sun, Jun 5, 2011 at 10:05 PM, Zeev Suraski z...@zend.com wrote: Pierre, I'm happy that we agree pretty much completely about the clarifications updates needed for the RFC. Same here :) I do however want to point out that the problematic way the short array syntax RFC was executed was the key reason that made me feel these updates were in fact necessary - I don't think that the way it was done was exemplary in any way... Well, it was done in a way without having an official way, so no, it was not perfect. Pretty much each and every point in my email is based on things that I felt went wrong with how we handled the short array syntax RFC: - There wasn't sufficient time, or nearly any time at all - between when Brian pulled it off the attic, and when a vote was called. If my proposal is accepted, there'll have to be at least two weeks between when a clearly marked [RFC] email hits internals@, and when a vote is called. - There wasn't a clearly marked, separate [VOTE] email. - There wasn't a clear or easy way of voting. - No voting period was announced, instead, people were told to stop mess around and go vote. - The author of the RFC wasn't actively involved in the whole process (as far as I could tell); There was no official replacement proposer. I just want to make sure we're on the same page. If you feel that the array syntax RFC was 'done right' then we have a bit of a gap :) In my opinion, given the lacking process, the short array syntax RFC needs to be redone. As I agree on everything you wrote here, I don't feel like we need to redo it. The votes result is pretty clear, despite 2-3 people not willing to vote for whatever reasons: https://wiki.php.net/rfc/shortsyntaxforarrays/vote All votes happened again after the alternatives have been proposed or discussed. One would have voted against this RFC if any of the alternatives was better. Anyway, if enough people thinks they want to re do it (3rd time IIRC), so be it. I'd still like to hear from others what they think about my proposal. I'd like to update the Release Process RFC with these suggestions if people like them. I'm all for theses changes and updates. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
[resending as the list appears to reject bit.ly URLs] As I agree on everything you wrote here, I don't feel like we need to redo it. The votes result is pretty clear, despite 2-3 people not willing to vote for whatever reasons: https://wiki.php.net/rfc/shortsyntaxforarrays/vote Take a look at http://english.ahram.org.eg/NewsContent/1/5/1712/Egypt/Egypt-Elections-/Mubarak-Despite-some-irregularities-elections-were.aspx . Spotting any resemblance? Look where he's at now :) Major parts in the process weren't executed properly (I've spelled them out so I won't repeat them). It's quite possible that if they were executed properly, we'd have different results. Perhaps not, maybe even probably not, but unless we do it right we'll never know. Also, I suspect that you'd find that there are more than just a couple of people who 'refused to vote'. I'm betting that there are plenty of people who had no idea a vote was going on, and plenty more that weren't entirely clear on what exactly it is they're voting on - with all the discussion that happened on internals@ spreading in half a dozen different directions. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
take #4.. Hmmm, not sure I like the comparison (with Egypt). Major parts in the process weren't executed properly (I've spelled them out so I won't repeat them). It's quite possible that if they were executed properly, we'd have different results. Perhaps not, maybe even probably not, but unless we do it right we'll never know. Are you saying that most people having voted +1 once, then a 2nd time +1 and finally a 3rd time (editing the votes to put it under the right syntax), would suddenly be totally against it? Also, I suspect that you'd find that there are more than just a couple of people who 'refused to vote'. I'm betting that there are plenty of people who had no idea a vote was going on, and plenty more that weren't entirely clear on what exactly it is they're voting on - with all the discussion that happened on internals@ spreading in half a dozen different directions. Given the active people, both in discussions and developments, I keep my estimation to 2-3 refusing to vote and the rest not giving it enough importance or does not care at all. In any case, if you feel like we have to re vote, and many do as well, then so be it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
