Re: [RFC DISCUSSION] Have voting options to show reason why dislike proposal.

Hi Sherif, On Thu, Feb 13, 2014 at 12:03 PM, Sherif Ramadan <theanomaly.is@gmail.com>wrote: > While I agree with the premise that some people do not voice their > opinions during the discussion phase of the RFC process, I also disagree > with the notion that this would somehow prove anymore useful. Those who > don't care to elaborate on their disapproval from the beginning may not > chose to do so during the vote anyway, unless we make it a requirement, in > which case it seems a bit of a kludge. > > I think the authors of the individual RFCs should take it upon themselves > to gather as much feedback as possible during the discussion phase of the > RFC process in order to collect some constructive set of feedback that > would help the RFC, should it be declined. I doubt that a short comment > during the vote will be very meaningful. I find that the more diligent the > authors of the RFC are, they more likely they are to be motivated by > gathering, and going over feedback during their discussion phase. > > I agree. I had several RFC for 5.6 and tried that, but people tends to read RFC on voting. For example, I closed vote due to more discussions on voting phase. I don't blame to discuss during voting phase, I would rather like to discuss for improvements. In fact, I'm one of them that read RFCs on voting phase also. What I would like to know is the reason why people vote "no" for RFC, such as mbstring-ng. It's great for mbstring users who would like to provide self contained internal web application for development/test using CLI server with custom module, for example. It can be work round, but PHP should remove LGPLed code IF it is possible :) My guess is, if we introduce this feature, people who chose to vote no and > can't come up with a reason may very well just copy and paste other reasons > they found where someone else voted no. That's perhaps slightly pessimistic > of a view, but it's my gut feeling. > > I do think that adding a suggestions/improvements section to the RFC, in > the event it is declined, might prove useful should that RFC be taken up > for consideration at a later version or inherited by another author. That > might allow the next author to address key points of the RFC that were > previously not addressed. > Thank you for the input! Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net