Re: [PHP-DEV] Re: Voting choice for language changes (Was: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count)
Hi, you replied to the wrong thread ;)
2015-07-22 19:38 GMT-03:00 S.A.N ua.san.a...@gmail.com:
I am satisfied, the possibility of group declarations, but the that lack:
?php
use App\RestException\ // name RestException, not imported to
current namespace :(
{
Gone,
NotFound,
BadRequest
};
?
Unfortunately have to write so:
?php
use App\RestException;
use App\RestException\{Gone, NotFound, BadRequest};
?
It looks ugly and very strange.
There is nothing strange on it (except, possibly, the trailing `\`
which was discussed to death and voted).
Even if we had no trailing '\' it wouldn't make any sense to import
App\RestException when use App\RestException{Gone, NotFound,
BadRequest}; is used.
My proposition, the imported end name, if end of without slash.
Like this:
?php
use App\RestException
{
Gone,
NotFound,
BadRequest
};
echo RestException::class; // App\RestException
?
Importing from within a namespace is not the same thing as importing a
class. I'd be against it.
My 2 cents: why do you have RestException with Exception suffix
and then don't have the same suffix on the other exception names? This
unpredictable exception hierarchy is the ugly part and subtle
alternative syntax won't make it better, IMMO.
Marcio
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting choice for language changes (Was: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count)
2015-07-23 18:10 GMT+03:00 Marcio Almada marcio.w...@gmail.com:
Hi, you replied to the wrong thread ;)
2015-07-22 19:38 GMT-03:00 S.A.N ua.san.a...@gmail.com:
I am satisfied, the possibility of group declarations, but the that lack:
?php
use App\RestException\ // name RestException, not imported to
current namespace :(
{
Gone,
NotFound,
BadRequest
};
?
Unfortunately have to write so:
?php
use App\RestException;
use App\RestException\{Gone, NotFound, BadRequest};
?
It looks ugly and very strange.
There is nothing strange on it (except, possibly, the trailing `\`
which was discussed to death and voted).
Even if we had no trailing '\' it wouldn't make any sense to import
App\RestException when use App\RestException{Gone, NotFound,
BadRequest}; is used.
My proposition, the imported end name, if end of without slash.
Like this:
?php
use App\RestException
{
Gone,
NotFound,
BadRequest
};
echo RestException::class; // App\RestException
?
Importing from within a namespace is not the same thing as importing a
class. I'd be against it.
My 2 cents: why do you have RestException with Exception suffix
and then don't have the same suffix on the other exception names? This
unpredictable exception hierarchy is the ugly part and subtle
alternative syntax won't make it better, IMMO.
Marcio
RestException is the base class for classes Gone, NotFound, BadRequest...
He needed to catch all RestExceptions class.
We do not use suffixes for names of exception classes, simple clear
named classes of exceptions, this is our agreement.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting choice for language changes (Was: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count)
I am satisfied, the possibility of group declarations, but the that lack:
?php
use App\RestException\ // name RestException, not imported to
current namespace :(
{
Gone,
NotFound,
BadRequest
};
?
Unfortunately have to write so:
?php
use App\RestException;
use App\RestException\
{
Gone,
NotFound,
BadRequest
};
?
It looks ugly and very strange.
My proposition, the imported end name, if end of without slash.
Like this:
?php
use App\RestException
{
Gone,
NotFound,
BadRequest
};
echo RestException::class; // App\RestException
?
2015-03-11 11:08 GMT+02:00 Patrick ALLAERT patrickalla...@php.net:
Le mar. 10 mars 2015 à 19:29, Marcio Almada marcio.w...@gmail.com a
écrit :
Hi,
2015-03-10 11:39 GMT-03:00 Patrick ALLAERT patrickalla...@php.net:
Hello,
Le ven. 6 mars 2015 à 00:44, Marcio Almada marcio.w...@gmail.com a
écrit :
You are right about this. I'll setup a yes/no vote + a vote to decide
between E_WARNING (for consistency), E_DEPRECATED or E_STRICT. For me
this
is just a detail but maybe it's very important to others, so better to
let
each voter decide upon it.
In case of language changes, shouldn't the 2/3 of majority be required at
any levels?
I don't think it's possible. What would happen if the yes/no vote passes
but the secondary vote doesn't reach 2/3 for some option? This would be a
weird situation.
Pretty simple actually: it would simply not pass because it wouldn't gather
enough support.
Discuss the options, see what gather the most support and the better
reasonings and then suggest that the RFC yes vote means A, B or C while
summarizing the reasons of the choice for it in the RFC itself.
A language change vote requiring 2/3 majority on a Yes/No and a simple
majority in an option basically means not requiring 2/3 at all, but 50%
(with 2 options) at most!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Voting irregularities
Hi all, since my handle was included in the list compiled by Anthony, I figured I'd reply to internals list as well. On So, 2015-03-15 at 10:19 -0400, Anthony Ferrara wrote: I ran some numbers on the current votes of the dual-mode vote right now. There were a number of voters that I didn't recognize. You may not recognize my account but I sure hope you recall speaking to me in person before. You even attended one of my talks at Confoo last year.. So I decided to pull some stats. The following voters never voted before the dual-mode RFC went up: I cannot speak for anyone else, but I indeed didn't actively vote before. I honestly though don't recall if me voting on this RFC was my first vote or not. I also voted on other RFCs though. If we adjust the votes to remove these never voted accounts, it stands at 67:28. Which is 70.5%. Which is basically where the vote was prior to the competing RFC opening. Since sounds awfully like 2nd class voting. And, would you ask for the same if the situation would be reversed? I'm not saying that all of these are bad votes. Nor that they shouldn't be counted. Why would you calculate the alternative result then? I think it does raise a significant question around the voting practices. Something that I think we need to discuss as a group. Again, I can't speak for others but only myself. I decided to vote on this RFC as well as some others since I believe my experience and expertise might qualify. I didn't (and don't) vote on anything where I feel I don't fully oversee the consequences or can judge the impact. And because I think the RFCs I voted on are important. Quite often before, I discussed things with others - for instance with Sebastian Bergmann -, who then posted the results of our thoughts on internals or talked to others on IRC to get more feedback. Last that happened with the idea of providing the throwable interface as an addition to the engine exceptions and in favor of the base exception class. Either way, I mostly only passively read on internals. I prefer talking to people in person, or if there is no timely alternative on chat. For what it's worth: I do have a php.net account since 2001, mostly working on the German translation of the docs. If that and my general visibility in the community entitles me to add my vote here is something others have to judge. I honestly can't say. But having my vote ignored (or at least considered questionable) because it tends to sway the RFC results in the wrong direction feels really odd. Regards, Arne -- Those who do not understand Unix are condemned to reinvent it, poorly (Henry Spencer,1987) signature.asc Description: This is a digitally signed message part
[PHP-DEV] Re: Voting choice for language changes (Was: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count)
Le mar. 10 mars 2015 à 19:29, Marcio Almada marcio.w...@gmail.com a écrit : Hi, 2015-03-10 11:39 GMT-03:00 Patrick ALLAERT patrickalla...@php.net: Hello, Le ven. 6 mars 2015 à 00:44, Marcio Almada marcio.w...@gmail.com a écrit : You are right about this. I'll setup a yes/no vote + a vote to decide between E_WARNING (for consistency), E_DEPRECATED or E_STRICT. For me this is just a detail but maybe it's very important to others, so better to let each voter decide upon it. In case of language changes, shouldn't the 2/3 of majority be required at any levels? I don't think it's possible. What would happen if the yes/no vote passes but the secondary vote doesn't reach 2/3 for some option? This would be a weird situation. Pretty simple actually: it would simply not pass because it wouldn't gather enough support. Discuss the options, see what gather the most support and the better reasonings and then suggest that the RFC yes vote means A, B or C while summarizing the reasons of the choice for it in the RFC itself. A language change vote requiring 2/3 majority on a Yes/No and a simple majority in an option basically means not requiring 2/3 at all, but 50% (with 2 options) at most!
Re: [PHP-DEV] Re: Voting choice for language changes (Was: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count)
On 3/10/15 1:29 PM, Marcio Almada wrote: I think we should do some effort to discuss and discard as much options as possible so we can have max 2 options or maybe eliminate the secondary voting at all (which is the perfect scenario IMMO), but this requires a good absolute number of opinions. If for some reason more than a binary question is necessary, at least go for instant-runoff style voting as that can represent if not X, then Y is at least tolerable better than any mechanism currently in use in Internals. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Voting choice for language changes (Was: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count)
Hi, 2015-03-10 11:39 GMT-03:00 Patrick ALLAERT patrickalla...@php.net: Hello, Le ven. 6 mars 2015 à 00:44, Marcio Almada marcio.w...@gmail.com a écrit : You are right about this. I'll setup a yes/no vote + a vote to decide between E_WARNING (for consistency), E_DEPRECATED or E_STRICT. For me this is just a detail but maybe it's very important to others, so better to let each voter decide upon it. In case of language changes, shouldn't the 2/3 of majority be required at any levels? I don't think it's possible. What would happen if the yes/no vote passes but the secondary vote doesn't reach 2/3 for some option? This would be a weird situation. In situations like: Main feature: No/Yes Option: A, B or C My gut feeling is that it would be better to rally a 2/3 majority of people behind one of: No / Yes (A) / Yes (B) / Yes (C) in order to not dilute the importance of language changes. It would prevent accepting an important change where a lot of people agrees on a general idea but have strong opinions/arguments on implementation/details. Cheers, Patrick I think we should do some effort to discuss and discard as much options as possible so we can have max 2 options or maybe eliminate the secondary voting at all (which is the perfect scenario IMMO), but this requires a good absolute number of opinions.
[PHP-DEV] Re: voting without vcs accounts
On Mon, Apr 16, 2012 at 10:14 AM, Ferenc Kovacs tyr...@gmail.com wrote: Hi, I sent an email last year about this issue, but it got sidetracked (partly it was my fault): http://www.mail-archive.com/internals@lists.php.net/msg54267.html So this time, I would like focusing only on the following: 1. What are the requirements for getting voting rights in the wiki without having a vcs/master account? - The voting RFC states: - Representatives from the PHP community, that will be chosen by those with php.net SVN accounts - Lead developers of PHP based projects (frameworks, cms, tools, etc.) - regular participant of internals discussions 2. What are the necessary steps from a volunteer to request voting karma? 3. How do we handle the applicants? Who will judge the applications? 4. How can we see the list of the people having voting karma? Currently only the wiki admins can see who are the people with the voting group membership. The wiki is already prepared to support voting without vcs account: there is a voting group, anybody having membership in that group are able to vote ( http://git.php.net/?p=web/wiki.git;a=commit;h=e3b97f03548fab661b5bc2dd66420db1024b1f39 ). My personal opinion would be that we have an application form like we have for the vcs account request, which will send an email to the mailing list, we can discuss here whether we support/approve the applicant or not, and somebody with proper karma can approve/decline the application, which would also trigger an email to the mailing list. -- Ferenc Kovács @Tyr43l - http://tyrael.hu Hi, Seeing the discussion/confusion yesterday I'm bringing this up again, maybe we can get an agreement this time. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
[PHP-DEV] Re: Voting periods
On 2013-01-28, Zeev Suraski z...@zend.com wrote: --e89a8fb1fbd85c066a04d455d2d7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The specific case in point is https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 - which while has more supporters than opposers, consistent fell short of the 2/3 majority it needs to be approved. The vote should have ended on Wednesday =E2=80=93 4 = days ago, but for some reason it=E2=80=99s still open. It=E2=80=99s time to clo= se it. I agree. We need a defined period for voting. The past RFCs have seen very short voting periods to very long, depending on what the RFC creator wanted and usually worked in his favor. To make it more objectiv and actually concentrate on code instead of votings I tihnk a 1 week or 2 week period after calling for votes is okay and shouldn't be able to be extended. Concerning the property syntax, I agree that this vote should be closed already. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Voting periods
Hi, Le Mon, 28 Jan 2013 11:22:52 +0200, Zeev Suraski a écrit : Regardless, an ‘open ended’ voting period is unacceptable IMHO. I agree with that. An update of the voting rfc (https://wiki.php.net/rfc/ voting) should be made. However one week only seems a little shorter in my opinion to validate changes that will affect millions of people. There's times in the year when we are most AFK (summer vacations, christmas, etc...) and as you point that there can be a specific point in time where the vote happens to be in favor with what the proposer wanted, there also can have a specific period in the year to make a rfc pass easier due to the lack of voters (perhaps my mind is twisted but i've already seen this trick in politics so... ;-). I'm not sure how long we should make the vote duration but i think that, like the discussion period, there shoud be a minimum 2 weeks between the vote opening and it's closing. My 2 cents, regards, Bruno -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [Voting] Call for voting for RFC: Supports finally keyword
Hi all: after 1 week , we got the voting result: 25 supports, 5 against. here is the result: https://wiki.php.net/rfc/finally?#changelog I am going to commit the patch to trunk. thanks for your great advise. :) thanks On Mon, Aug 6, 2012 at 7:39 PM, Laruence larue...@php.net wrote: Hi: We have discussed this RFC for a while, and seems no new suggestion raise up. previous discussion could be found here: http://marc.info/?l=php-internalsm=134312917227815w=2 So, Let's voting for it: https://wiki.php.net/rfc/finally#vote :) thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re voting
Sharon, On Mon, Apr 16, 2012 at 8:42 PM, sle...@pipeline.com wrote: Stas: Just b/c there are rarely any women at all that participate on this list, could we at list maintain a facade of gender neutrality? I seriously can't believe that you used the word him. What about her? Yeah, her as in myself and every other woman who codes with PHP whether to earn her living or to have a pleasant past-time? I am sure that there are plenty of PHP women just like me who might really appreciate having the opportunity to vote on changes that might effect the way we work. Currently, it's as clear as mud to me as to what I need to do to be able to have some kind of voting impact. The protocol or process needs to be clearly articulated in very clear language so that all concerned PHP men and women can be informed. Sharon Lee Levy, ZCE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php You raise a valid concern, but I think you were unfairly harsh toward Stas. The gender-neutral he is an accepted standard in English. Maybe it shouldn't be, and I would applaud efforts to change that, but berating someone who uses it isn't the best way to get your message across. Personally, I'm a fan of the singular they. Some people prefer to use ze instead, but I think it just sounds stupid. Why? Well, just say the following sentence in a funny accent of your choosing and you'll understand: What is ze doing?! ;) --Kris
Re: [PHP-DEV] Re voting
On Mon, Apr 16, 2012 at 8:42 PM, sle...@pipeline.com wrote: Stas: Just b/c there are rarely any women at all that participate on this list, could we at list maintain a facade of gender neutrality? One of my favorite PHP dev folks is Sara Golemon. A fucking rock star. Female, I believe. I think she might be into women, but I don't really know, or care, because we honor *code*, not biological plumbing. Point being that PHP is not a sex or gender hostile community. -Bop -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re voting
Stas: Just b/c there are rarely any women at all that participate on this list, could we at list maintain a facade of gender neutrality? I seriously can't believe that you used the word him. What about her? Yeah, her as in myself and every other woman who codes with PHP whether to earn her living or to have a pleasant past-time? I am sure that there are plenty of PHP women just like me who might really appreciate having the opportunity to vote on changes that might effect the way we work. Currently, it's as clear as mud to me as to what I need to do to be able to have some kind of voting impact. The protocol or process needs to be clearly articulated in very clear language so that all concerned PHP men and women can be informed. Sharon Lee Levy, ZCE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re voting
Just b/c there are rarely any women at all that participate on this list, could we at list maintain a facade of gender neutrality? I seriously can't believe that you used the word him. What about her? Yeah, her as in myself and every other woman who codes with PHP whether to earn her living or to have a pleasant past-time? I am sure that there are plenty of PHP women just like me who might really appreciate having the opportunity to vote on changes that might effect the way we work. Currently, it's as clear as mud to me as to what I need to do to be able to have some kind of voting impact. The protocol or process needs to be clearly articulated in very clear language so that all concerned PHP men and women can be informed. Sharon Lee Levy, ZCE I believe you might have been trying to reply to the voting without vcs accounts thread, possibly? I do agree that the current state of affairs with regard to voting on RFCs and the requirements/expectations for one to be promoted into the voting process are about as clear the night sky. There should be more transparency in understanding the requirements and setting forth the expectations for the process in a formal and sane manner. I also think that process should be fair irrespective of gender, race, etc... The process should be subject to one's own demonstrated active (and hopefully positive) role in the PHP community. I think if someone shows initiative to consistently produce positive results they should be accepted into the voting process based on their own merits. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re voting
On 17 April 2012 11:42, sle...@pipeline.com wrote: Just b/c there are rarely any women at all that participate on this list, could we at list maintain a facade of gender neutrality? I seriously can't believe that you used the word him. What about her? Yeah, her as in myself and every other woman who codes with PHP whether to earn her living or to have a pleasant past-time? I am sure that there are plenty of PHP women just like me who might really appreciate having the opportunity to vote on changes that might effect the way we work. While I am fully in support of PHP being inclusive towards men, women, the transgendered community, and anyone else who is not covered by the aforementioned categories, with respect, I don't believe Stas merited the sarcastic flame he has received from you. Singular he as a gender-neutral pronoun was taught as standard English for a long time, and whilst it may not be the most politically correct phrasing in the modern era, I doubt any offence or non-inclusion was intended. Furthermore, many of the participants on this list are not native English speakers, and the nuances and politics of gender representation in a largely non-gendered language like English are likely to be lost on them. Hanlon's Razor would seem to apply. Currently, it's as clear as mud to me as to what I need to do to be able to have some kind of voting impact. The protocol or process needs to be clearly articulated in very clear language so that all concerned PHP men and women can be informed. On that point, I doubt anyone disagrees. Thanks, Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re voting
On Mon, Apr 16, 2012 at 11:42 PM, sle...@pipeline.com wrote: Stas: Just b/c there are rarely any women at all that participate on this list, could we at list maintain a facade of gender neutrality? I seriously can't believe that you used the word him. What about her? Yeah, her as in myself and every other woman who codes with PHP whether to earn her living or to have a pleasant past-time? I am sure that there are plenty of PHP women just like me who might really appreciate having the opportunity to vote on changes that might effect the way we work. Currently, it's as clear as mud to me as to what I need to do to be able to have some kind of voting impact. The protocol or process needs to be clearly articulated in very clear language so that all concerned PHP men and women can be informed. Sharon Lee Levy, ZCE Hi Sharon, I'm a father of 3 daughters, and I'm protective of the opportunities they'll have when they're old enough to enter the working world (right now the oldest is 7.) In fact, my daughters have started developing websites already, and I'm sure PHP is just around the corner, so maybe they'll end up using this list a few years from now :) I believe you quoted Stas's response below: no, it only means that our internal processes aren't clear or easily accessible. people outside the circle can't do much, than asking people inside to let them in. If somebody is an outsider to PHP development, why do you think giving him a deciding vote on it would be a good thing? One can discuss things, propose changes, etc. without any special access. Stas does a great job engaging in the dialogues on this list, and I can't even imagine the cost in terms of time. I know it must be great. In this case, I don't believe Stas meant any offense. The lack of a gender neutral pronoun in English is well documented (and argued:) http://en.wikipedia.org/wiki/Gender-neutral_pronoun When Stas wanted to use a singular form of a pronoun, he had a few options (as outlined in the link): - he - they (implied singular) - one - he/she I'm confident his choice of words was for speed, not one of precise articulation of the group involvement. Glad you're own the list :) My girls will be grateful for the role model(s) in a few years! Adam
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
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
On Jun 3, 2011, at 4:43 AM, Derick Rethans der...@php.net wrote: On Fri, 3 Jun 2011, Stas Malyshev wrote: - a call to vote is easily drowned out on the ML with all the noise I read the same ML as you do :) Using threaded email client it is very easy to separate new threads and see calls for votes. That is subjective. And even with a threaded client, if there are 80+ new messages then the call for vote is drowned out. *Requiring* something like [VOTE] in the subject helps, as then you can set-up a filter. And if it's a requirement, every call without [VOTE] in the subject is invalid. (Easy to fix if somebody forgot it as well). It would expose this kind of thing. Why not setup a different ML that is announce-only except a few people, just to announce votes?
RE: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
On Jun 4, 2011, at 3:07 AM, Pierre Joye wrote: On Sat, Jun 4, 2011 at 5:46 AM, Stas Malyshev smalys...@sugarcrm.com wrote: [VOTE] is a good idea, let's make it [VOTE]. There is no plugin used for it yet, and that's my problem with it. Well, votes aren't announced yet either :) I'll try to get it set up ASAP and see how it works, before announcing the vote. It looks good in description at least. Please keep them in the wiki as we planed to do. THere are plugins and it is very easy to manage, allows per section voting etc. I'm hopeful people will continue to understand the RFC definition: - RFC: Request For Comments And while doing so, not revert to a vote (RFV?) simply because discussing a topic can get messy. Voting has clear winners and losers with potential loss for improvements. That and you must then worry about who can and cannot vote (i.e., non-inclusive community). It's rare that we've required a formal vote, so I fear we will now implement voting at inappropriate times rather than allow a consensus to be reached. Also, people should be given a reasonable opportunity to offer an alternative RFC. I agree wholeheartedly with Philip - and that does not mean that my intention is to derail a healthy voting process. Some of you may have followed the twitter conversation that Pierre and I had at the end of last week; In my opinion, this dry (or partially wet) run that we had in the last few days of a voting process pointed to several deficiencies that need to be addressed in the RFC release process that need to be addressed before we move on. 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
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
On Sun, Jun 5, 2011 at 4:18 PM, Zeev Suraski z...@zend.com wrote: Some of you may have followed the twitter conversation that Pierre and I had at the end of last week; In my opinion, this dry (or partially wet) run that we had in the last few days of a voting process pointed to several deficiencies that need to be addressed in the RFC release process that need to be addressed before we move on. Fully agreed and it was the case for the array stuff and a consensus is clear here, and in favour of one the proposals. To make the point straight. 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. Right, that's why we have draft, on discussions status and we should add a vote status. Maybe clearly document that as well on the main RFCs page to avoid badly proposed RFC to end in a voting phase too early or at all. - 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. Agreed. - 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. Afaict, it is the case already. - 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. Yes, the authors should have the hand on the process, not some random not related developers, while anyone could be able to help to push an idea. 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. Agreed. 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. It is the case now. We have a poll plugin installed. To be proven to fulfill our needs but as far as I remember, moodle2 does the job pretty well. 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. Again, agreed. Deciding things between Friday evening and Monday morning is simply not possible nor correct, for example. 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. Even more true for languages related RFCs, they are critical (and irreversible) and we should proceed with much caution than anything else. I'd to say that I'm very happy to finally see such discussions happening, let sort the base (99% is done by our existing RFC about release process, let adopt it already!) and move on with 5.4. Cheers, -- Pierre
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
On Sun, Jun 5, 2011 at 17:20, Pierre Joye pierre@gmail.com wrote: On Sun, Jun 5, 2011 at 4:18 PM, Zeev Suraski z...@zend.com wrote: Some of you may have followed the twitter conversation that Pierre and I had at the end of last week; In my opinion, this dry (or partially wet) run that we had in the last few days of a voting process pointed to several deficiencies that need to be addressed in the RFC release process that need to be addressed before we move on. Fully agreed and it was the case for the array stuff and a consensus is clear here, and in favour of one the proposals. To make the point straight. Say what? Do people even know what they were voting for? I have absolutely no idea whatsoever what is being voted on, so I haven't yet. - 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. Afaict, it is the case already. Definitely not. There is so much discussion about the array stuff now that I have no idea what is being voted on.. People started counting votes before the discussion even began. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
On Jun 5, 2011, at 8:20 AM, Pierre Joye wrote: I'd to say that I'm very happy to finally see such discussions happening, let sort the base (99% is done by our existing RFC about release process, let adopt it already!) and move on with 5.4. This is a prime example of what we're talking about. Several have expressed a desire to follow an Ubuntu style of branching instead of the style proposed in said RFC. This is a core issue, so the RFC is certainly not ready to adopt. So does this require a new RFC, or do the RFC proposers feel this is a key concept? Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
On Sun, Jun 5, 2011 at 5:46 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Sun, Jun 5, 2011 at 17:20, Pierre Joye pierre@gmail.com wrote: On Sun, Jun 5, 2011 at 4:18 PM, Zeev Suraski z...@zend.com wrote: Some of you may have followed the twitter conversation that Pierre and I had at the end of last week; In my opinion, this dry (or partially wet) run that we had in the last few days of a voting process pointed to several deficiencies that need to be addressed in the RFC release process that need to be addressed before we move on. Fully agreed and it was the case for the array stuff and a consensus is clear here, and in favour of one the proposals. To make the point straight. Say what? Do people even know what they were voting for? I have absolutely no idea whatsoever what is being voted on, so I haven't yet. If you do not understand what has been discussed and can't vote, that's not my or our problem. Nothing I can do will help you here. - 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. Afaict, it is the case already. Definitely not. There is so much discussion about the array stuff now that I have no idea what is being voted on.. People started counting votes before the discussion even began. Please, and I mean it, stop to state wrong and misleading information. There is a page where people votes and have changed their votes, https://wiki.php.net/rfc/shortsyntaxforarrays/vote. There is a clear and obvious consensus, like or not. 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))
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
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
On 2011-06-05, Pierre Joye pierre@gmail.com wrote: On Sun, Jun 5, 2011 at 5:52 PM, Philip Olson phi...@roshambo.org wrote: I'd to say that I'm very happy to finally see such discussions happening, let sort the base (99% is done by our existing RFC about release process, let adopt it already!) and move on with 5.4. This is a prime example of what we're talking about. Several have expressed a desire to follow an Ubuntu style of branching instead of the style proposed in said RFC. This is a core issue, so the RFC is certainly not ready to adopt. So does this require a new RFC, or do the RFC proposers feel this is a key concept? As I stated before, there is a RFC with a fair amount of developers involved. Some of the supporters of the Ubuntu TLS model already changed their mind (as it clearly does not work for php, random features being TLS just because of the timing makes no sense). If you think a RFC is not ready, not desired, not good enough or whatever other reason motivates you, vote against and propose something else. But you can even say no and propose nothing afterwards. I agree. People should stick to the RFC system to hve a documented way of saying what they like and what not. If the RFC writers want to adopt a change that's their things. So far there is no reason to change it. As of this specific RFC, it is actually a very good one, it is not perfect and will need adjustement in the coming years, that's a damned sure thing. But we can not argue forever only because a minority thinks we should argue endlessly or change nothing. Yes. The Release RFC is nothing that needs Backward compatbility. We should vote on the general direction instead of fighting over a minor details and getting nothing done. Details can be modified with later RFCs. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Voting Process
Hi! 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 think we shouldn't over-formalize this. Certainly if about 50% of voters are against something, it does not have consensus. But I do not think specifying hard percentages would do us much good, especially if we do it without considering case in point. Some things are OK to decide on simple majority (like things that have two equally good options and we have to choose one, or things that are matters of taste/style, etc.), some may require more strong consensus, especially big changes, but I'd have very hard time formalizing this upfront. Currently the Feature selection and development basically says we'd have a public vote on features. It doesn't specify how exactly is the process for a vote, and while again I think your proposal is good, I don't see why it has to be part of this RFC - e.g., if we agree that we have to have RFCs and formal non-ML public vote, let's fix that and then talk about how exactly we do the vote. The RFC itself says nothing of how, so I don't see why we should mix the question of should we do it with let's decide how exactly we going to do it. -- 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
Currently the Feature selection and development basically says we'd have a public vote on features. It doesn't specify how exactly is the process for a vote, and while again I think your proposal is good, I don't see why it has to be part of this RFC - e.g., if we agree that we have to have RFCs and formal non- ML public vote, let's fix that and then talk about how exactly we do the vote. The RFC itself says nothing of how, so I don't see why we should mix the question of should we do it with let's decide how exactly we going to do it. I can't really agree here. Just watch what happened last week, when we moved ahead to a vote - the whole thing was IMHO rushed and messy. That's exactly why I don't think we can leave the details out. The way I see it, we can't employ the voting part of this RFC unless we can agree on rules on how this voting works; It's fine that we don't decide exactly how we're going to do it. But then, it means that we don't get to do it until we do decide. What makes the most sense to me is to separate the decision making process into another RFC altogether. If people feel it's premature to discuss that process - that's fine, but I don't think we can hold the stick at both ends, and start using a voting mechanism before we even agreed on the basics of voting in the first place. 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))
[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
[PHP-DEV] Re: Voting Process
Hi! The way I see it, we can't employ the voting part of this RFC unless we can agree on rules on how this voting works; It's fine that we don't decide exactly how we're going to do it. But then, it means that we don't get to do it until we do decide. Well, we'd have to vote somehow, e.g. on RFC itself :) I agree that before that (and including array syntax) votes were kind of haphazard and we need to do better. So let's have the voting process RFC. I took the liberty of capturing your email, with minimal edits, here: https://wiki.php.net/rfc/voting - please edit/rewrite as you wish. I did not add anything about percentages etc. there as I have no idea how we could formalize it :) What makes the most sense to me is to separate the decision making process into another RFC altogether. If people feel it's premature I don't think it's premature, quite the opposite. I just think we need to have agreement of release process in general (so we could start with the actual release process) and then work out details as they come up. The first of those would be the voting RFC. I'm just afraid substantial changes in the release RFC mean we need to have new discussion about it and take more time to do it, and in the meantime we have nothing at all, so we have to either start the release process without anything at all or delay it until we figure out every last fine detail. I'd rather have general principles down and when we get to the fine details we'd deal with them. -- 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
Re: [PHP-DEV] Re: Voting Process
On Mon, Jun 6, 2011 at 1:16 AM, Stas Malyshev smalys...@sugarcrm.com wrote: The way I see it, we can't employ the voting part of this RFC unless we can agree on rules on how this voting works; It's fine that we don't decide exactly how we're going to do it. But then, it means that we don't get to do it until we do decide. Well, we'd have to vote somehow, e.g. on RFC itself :) I agree that before that (and including array syntax) votes were kind of haphazard and we need to do better. So let's have the voting process RFC. I took the liberty of capturing your email, with minimal edits, here: https://wiki.php.net/rfc/voting - please edit/rewrite as you wish. I did not add anything about percentages etc. there as I have no idea how we could formalize it :) I will add a reference to it in the Relase Process RFC as they are complementary and must be resolved/adopted at the same time and before we go with 5.4 What makes the most sense to me is to separate the decision making process into another RFC altogether. If people feel it's premature I don't think it's premature, quite the opposite. I just think we need to have agreement of release process in general (so we could start with the actual release process) and then work out details as they come up. The first of those would be the voting RFC. Actually I think Zeev has a good point on the voting, it has been hurting us for too long already. I do think that waiting that these RFCs (voting and then release process) are adopted is a must, before any kind of new releases. Not doing that will open the pandaro box again, think of the dead cows like 6, or the endless release phase of 5.3. I'm just afraid substantial changes in the release RFC mean we need to have new discussion about it and take more time to do it, and in the meantime we have nothing at all, so we have to either start the release process without anything at all or delay it until we figure out every last fine detail. I'd rather have general principles down and when we get to the fine details we'd deal with them. I think we have a consensus on this rfc already. Except the voting process everything has been approved by most if not all active developers already (see the proposer, for the other readers). By the way, I'm not saying we don't need a vote, only that we are closed to get it approved globally. So if we need to wait one or two weeks more to sort them out, then let do it. It will be a giant step forward and spare us many of the painful moments we had in the past, way too often. That being said, it is not a waste of time anyway. The discussions about what should be in 5.4 (especially the recently proposed features) will take a couple of weeks as well, so we can already say that we are already in the 5.4 phase. But we did not and can't yet begin with a 1st release, without having defined what will be in. 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
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
On Sat, Jun 4, 2011 at 5:46 AM, Stas Malyshev smalys...@sugarcrm.com wrote: [VOTE] is a good idea, let's make it [VOTE]. There is no plugin used for it yet, and that's my problem with it. Well, votes aren't announced yet either :) I'll try to get it set up ASAP and see how it works, before announcing the vote. It looks good in description at least. Please keep them in the wiki as we planed to do. THere are plugins and it is very easy to manage, allows per section voting etc. -- 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
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
On Jun 4, 2011, at 3:07 AM, Pierre Joye wrote: On Sat, Jun 4, 2011 at 5:46 AM, Stas Malyshev smalys...@sugarcrm.com wrote: [VOTE] is a good idea, let's make it [VOTE]. There is no plugin used for it yet, and that's my problem with it. Well, votes aren't announced yet either :) I'll try to get it set up ASAP and see how it works, before announcing the vote. It looks good in description at least. Please keep them in the wiki as we planed to do. THere are plugins and it is very easy to manage, allows per section voting etc. I'm hopeful people will continue to understand the RFC definition: - RFC: Request For Comments And while doing so, not revert to a vote (RFV?) simply because discussing a topic can get messy. Voting has clear winners and losers with potential loss for improvements. That and you must then worry about who can and cannot vote (i.e., non-inclusive community). It's rare that we've required a formal vote, so I fear we will now implement voting at inappropriate times rather than allow a consensus to be reached. Also, people should be given a reasonable opportunity to offer an alternative RFC. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
Speaking generally, consensus is a dangerous and impossible standard. Few things can cripple progress like waiting for consensus. Voting may be one good way to move things forward without deadlocking forever. I agree though that without clear rules for how the process should work, voting is also chaotic. (Who can call for a vote? How? When is it final? Who can vote? How do they vote? How much is each vote worth? Is a simple majority or super majority needed?) John Crenshaw Priacta, Inc. -Original Message- From: Philip Olson [mailto:phi...@roshambo.org] Sent: Saturday, June 04, 2011 9:30 AM To: Pierre Joye Cc: Stas Malyshev; Derick Rethans; PHP Internals Subject: Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward) On Jun 4, 2011, at 3:07 AM, Pierre Joye wrote: On Sat, Jun 4, 2011 at 5:46 AM, Stas Malyshev smalys...@sugarcrm.com wrote: [VOTE] is a good idea, let's make it [VOTE]. There is no plugin used for it yet, and that's my problem with it. Well, votes aren't announced yet either :) I'll try to get it set up ASAP and see how it works, before announcing the vote. It looks good in description at least. Please keep them in the wiki as we planed to do. THere are plugins and it is very easy to manage, allows per section voting etc. I'm hopeful people will continue to understand the RFC definition: - RFC: Request For Comments And while doing so, not revert to a vote (RFV?) simply because discussing a topic can get messy. Voting has clear winners and losers with potential loss for improvements. That and you must then worry about who can and cannot vote (i.e., non-inclusive community). It's rare that we've required a formal vote, so I fear we will now implement voting at inappropriate times rather than allow a consensus to be reached. Also, people should be given a reasonable opportunity to offer an alternative RFC. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
hi Philip, On Sat, Jun 4, 2011 at 3:29 PM, Philip Olson phi...@roshambo.org wrote: - RFC: Request For Comments Thanks for the reminder. But RFC got approved at some point as well. See the numerous W3C RFCs for some known examples. And while doing so, not revert to a vote (RFV?) simply because discussing a topic can get messy. What got messy? That instead of simply rejecting the RFC instead of constantly adding new ideas to the stack. It is a perfectly valid flow to block a RFC because it is considered as not well designed, not desired or simple not fully compliant. It happened many times in php in the past and in other projects as well. Voting has clear winners and losers with potential loss for improvements. That and you must then worry about who can and cannot vote (i.e., non-inclusive community). It's rare that we've required a formal vote, so I fear we will now implement voting at inappropriate times rather than allow a consensus to be reached. I'm sorry to not be powerful enough to achieve my ultimate goal, have the most open processes and decissions in the OSS world within PHP. That is, to include the communities in the decision processes and not only to propose things. Now you can keep arguing that voting is pointless, unfair, that consensus can be reached easily, etc. etc. What we see is a total different picture which is more related to dictatorial decisions or puchists. None of these ways are good. 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
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
Hi! Please keep them in the wiki as we planed to do. THere are plugins and it is very easy to manage, allows per section voting etc. I've installed voting plugin, see description here: http://www.dokuwiki.org/plugin:doodle2 and example how it looks here at the end (login required to vote): https://wiki.php.net/playground/playground I think it'd work. -- 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
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
right, that's the one I was willing to install as well, great that you did it! Thanks :) On Sat, Jun 4, 2011 at 7:58 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Please keep them in the wiki as we planed to do. THere are plugins and it is very easy to manage, allows per section voting etc. I've installed voting plugin, see description here: http://www.dokuwiki.org/plugin:doodle2 and example how it looks here at the end (login required to vote): https://wiki.php.net/playground/playground I think it'd work. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- 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
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
On Sat, Jun 4, 2011 at 19:58, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Please keep them in the wiki as we planed to do. THere are plugins and it is very easy to manage, allows per section voting etc. I've installed voting plugin, see description here: http://www.dokuwiki.org/plugin:doodle2 and example how it looks here at the end (login required to vote): https://wiki.php.net/playground/playground I think it'd work. How does it work? Do you need write permission to the page it is located on, or is it enough to have login? How do you differentiate between 'core' and 'community' voting? (or is that maybe not needed?) -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
Hi! Voting on the wiki? Yuck. If you want participation, do it here on the mailinglist and store the record in the wiki. If all votes are showing Voting on ML is messy and means somebody needs to read every message on the list and look for votes, however long, tedious and offtopic the discussion gets. Voting with, well, voting application is clean, automatic and efficient. I don't understand why we should use medium that is unfit for the purpose instead of using applications specifically designed for doing what we try to do. up just in the wiki then there is no exposure on the list and things are easy to miss (especially with the huge amount of noise that's already on the list). There will be exposure to the list, with list of topics and explanations. -- 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
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
Why doesnt voting happen using a poll/voting engine. Written in (gasp) PHP! (although soon PJSON) On Jun 3, 2011, at 1:03 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Voting on the wiki? Yuck. If you want participation, do it here on the mailinglist and store the record in the wiki. If all votes are showing Voting on ML is messy and means somebody needs to read every message on the list and look for votes, however long, tedious and offtopic the discussion gets. Voting with, well, voting application is clean, automatic and efficient. I don't understand why we should use medium that is unfit for the purpose instead of using applications specifically designed for doing what we try to do. up just in the wiki then there is no exposure on the list and things are easy to miss (especially with the huge amount of noise that's already on the list). There will be exposure to the list, with list of topics and explanations. -- 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 Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
On Fri, 3 Jun 2011, Stas Malyshev wrote: Voting on the wiki? Yuck. If you want participation, do it here on the mailinglist and store the record in the wiki. If all votes are showing Voting on ML is messy and means somebody needs to read every message on the list and look for votes, however long, tedious and offtopic the discussion gets. Voting with, well, voting application is clean, automatic and efficient. I don't understand why we should use medium that is unfit for the purpose instead of using applications specifically designed for doing what we try to do. Yes, it's messy on ML. My points where: - a call to vote is easily drowned out on the ML with all the noise - editting votes on a wiki can too easily be manipulated (I could just change your votes, and there would be no trail). And IMO, those two things should be sorted out before we decide to do votes by editting some page on some wiki. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
Have you guys considered doodle.com? I think you are all stressing way too much over the voting process. When a vote is closed you can then transfer the decision to the RFC. Drak On 3 June 2011 14:12, Pierre Joye pierre@gmail.com wrote: On Fri, Jun 3, 2011 at 10:22 AM, Derick Rethans der...@php.net wrote: On Fri, 3 Jun 2011, Stas Malyshev wrote: Voting on the wiki? Yuck. If you want participation, do it here on the mailinglist and store the record in the wiki. If all votes are showing Voting on ML is messy and means somebody needs to read every message on the list and look for votes, however long, tedious and offtopic the discussion gets. Voting with, well, voting application is clean, automatic and efficient. I don't understand why we should use medium that is unfit for the purpose instead of using applications specifically designed for doing what we try to do. Yes, it's messy on ML. My points where: - a call to vote is easily drowned out on the ML with all the noise - editting votes on a wiki can too easily be manipulated (I could just change your votes, and there would be no trail). There is a log and we know who did edit what. Basic trust is required anyway and if such tricks happen, really, I do not know what to think about the person doing them (well I do, but that's not the place to say it). A plugin will be installed to ease the process, login, vote. You won't be able to add/edit other votes. About when a vote happens and how to inform the devs, I do not see other solutions than getting the devs to read the discussions on the MLs. If some can't stand the heat, then we can't do much for them anyway, 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 does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
Hi! - a call to vote is easily drowned out on the ML with all the noise I read the same ML as you do :) Using threaded email client it is very easy to separate new threads and see calls for votes. Also, voting on ML does not solve the drowning out problem, it makes it worse as about 80% of the people in given vote in a given moment can't say what they are/supposed to be voting for, is discussion still ongoing and what's the consensus, if any. - editting votes on a wiki can too easily be manipulated (I could just change your votes, and there would be no trail). Votes are public, if you see somebody edited it you'd notice. As editing could be done only by admins (if I understand correctly, same guys having root on pretty much all PHP infrastructure) if a plugin is used (see below) I don't think it's a big concern. And IMO, those two things should be sorted out before we decide to do votes by editting some page on some wiki. docuwiki has voting plugins for that purpose, editing some page is not the only way. For example: http://www.dokuwiki.org/plugin:doodle2 -- 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 does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
On Fri, 3 Jun 2011, Stas Malyshev wrote: - a call to vote is easily drowned out on the ML with all the noise I read the same ML as you do :) Using threaded email client it is very easy to separate new threads and see calls for votes. That is subjective. And even with a threaded client, if there are 80+ new messages then the call for vote is drowned out. *Requiring* something like [VOTE] in the subject helps, as then you can set-up a filter. And if it's a requirement, every call without [VOTE] in the subject is invalid. (Easy to fix if somebody forgot it as well). It would expose this kind of thing. Also, voting on ML does not solve the drowning out problem, it makes it worse as about 80% of the people in given vote in a given moment can't say what they are/supposed to be voting for, is discussion still ongoing and what's the consensus, if any. I didn't disagree with this. - editting votes on a wiki can too easily be manipulated (I could just change your votes, and there would be no trail). Votes are public, if you see somebody edited it you'd notice. As editing could be done only by admins (if I understand correctly, same guys having root on pretty much all PHP infrastructure) if a plugin is used (see below) I don't think it's a big concern. And IMO, those two things should be sorted out before we decide to do votes by editting some page on some wiki. docuwiki has voting plugins for that purpose, editing some page is not the only way. For example: http://www.dokuwiki.org/plugin:doodle2 There is no plugin used for it yet, and that's my problem with it. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
Hi! That is subjective. And even with a threaded client, if there are 80+ new messages then the call for vote is drowned out. *Requiring* There was never 80+ new messages on different topics on the list. There are 3-4 topics max, if you not count commit messages. Each of them can contain dozens of messages, but those can be easily grouped. something like [VOTE] in the subject helps, as then you can set-up a [VOTE] is a good idea, let's make it [VOTE]. There is no plugin used for it yet, and that's my problem with it. Well, votes aren't announced yet either :) I'll try to get it set up ASAP and see how it works, before announcing the vote. It looks good in description at least. -- 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
Lukas Kahwe Smith wrote: Hi, I think its painfully obvious that a system to manage the voting is needed. Like I said, ideally it should also have an email interface. People should be able to vote from +1 to -1 and be able to add a comment. Notifications should be send to this list about the start and final result of the vote. Voting itself should be split by people with access to cvs.php.net and those that do not. This is open source, everybody can voice their opinions, but the developers of the project should have final say. However if the end user and developer votes diverge greatly it will still be an important hint to take into account. That being said, end user polling imho belongs somewhere else and before the final developer vote. The features of PEPr in PEAR cover all of this quite well, except for the email interface. I personally would not need that and maybe its too much of a hassle to get this done in a reliable and secure way. PEPr, unfortunately, is very tightly bound to the pearweb code, and would be a big hassle to separate as it currently stands. We have been working (by we, I mostly mean Helgi) for over a year now trying to clean up pearweb and still are only about halfway through the codebase, but when PEPr is tackled, I will let you all know. Of course, if there is someone enterprising who wants to assist with that specific part of the cleanup, the code is in cvs at pearweb/. PEPr-specific code is located in pearweb/include/pepr, pearweb/public_html/pepr, and pearweb/cron/pepr.php. Thanks, Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: voting
On Jan 12, 2008 9:57 AM, Gregory Beaver [EMAIL PROTECTED] wrote: Lukas Kahwe Smith wrote: Hi, I think its painfully obvious that a system to manage the voting is needed. Like I said, ideally it should also have an email interface. People should be able to vote from +1 to -1 and be able to add a comment. Notifications should be send to this list about the start and final result of the vote. Voting itself should be split by people with access to cvs.php.net and those that do not. This is open source, everybody can voice their opinions, but the developers of the project should have final say. However if the end user and developer votes diverge greatly it will still be an important hint to take into account. That being said, end user polling imho belongs somewhere else and before the final developer vote. The features of PEPr in PEAR cover all of this quite well, except for the email interface. I personally would not need that and maybe its too much of a hassle to get this done in a reliable and secure way. PEPr, unfortunately, is very tightly bound to the pearweb code, and would be a big hassle to separate as it currently stands. We have been working (by we, I mostly mean Helgi) for over a year now trying to clean up pearweb and still are only about halfway through the codebase, but when PEPr is tackled, I will let you all know. Of course, if there is someone enterprising who wants to assist with that specific part of the cleanup, the code is in cvs at pearweb/. PEPr-specific code is located in pearweb/include/pepr, pearweb/public_html/pepr, and pearweb/cron/pepr.php. And if that entrepreneur-person needs tips about the pearweb code or mentoring, I'll be glad to help. Thanks, Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- David Coallier, Founder Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
