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
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
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
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
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
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
