Hi all,
We have number of RFC that has been declined. It's good we agree not to
introduce proposal. However, it's not good we don't see the reason why.
Since RFC is technical discussion, there should be good reasons to oppose
proposals and these opinions should be used to improve/create another RFC.
I would like to propose RFC to have vote for the reason why user voted "no"
for the RFC. Additionally, we may have comment plugin to explains the
reason why.
Users who would like to vote "no" for a RFC, they should explain during
discussion period or when voting at least. This way, we would have more
constructive RFC process.
Any comments?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi all,
We have number of RFC that has been declined. It's good we agree not to
introduce proposal. However, it's not good we don't see the reason why.
Since RFC is technical discussion, there should be good reasons to oppose
proposals and these opinions should be used to improve/create another RFC.I would like to propose RFC to have vote for the reason why user voted "no"
for the RFC. Additionally, we may have comment plugin to explains the
reason why.Users who would like to vote "no" for a RFC, they should explain during
discussion period or when voting at least. This way, we would have more
constructive RFC process.Any comments?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
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.
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.
Hi Sherif,
On Thu, Feb 13, 2014 at 12:03 PM, Sherif Ramadan theanomaly.is@gmail.comwrote:
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
Hi!
Since RFC is technical discussion, there should be good reasons to oppose
proposals and these opinions should be used to improve/create another RFC.
In general, there's no burden of proof to not introduce some feature or
change. It is the default. PHP has worked for many years before without
that feature, however good may it be, so it is proven we can live
without it, even if it appears very good (of course, this does not
include high-exposure security issues, etc. but we're talking about
regular stuff I suppose). The burden of proof is on the proposer to
convince people that with that feature it would be much better than
without it. Sometimes it is obvious (unanimous approval votes aren't
unheard of), sometimes it is not that obvious. Sometimes people just
don't realize it is important, sometimes they disagree on the
importance, sometimes it's just not the right time for it.
In this case, the burden is on the proposer to solicit feedback and
figure out why people are not convinced and what could be done, if
anything, to convince them.
So yes, it would be very good if people who disagree with the RFC would
voice their concerns, when they are different from ones already voiced
on the list ("me too" is not very useful). Especially if disagreement is
of constructive nature and can be resolved with some modification. But I
don't think there's a real duty for people to explain each of their "no"
vote if they just don't feel like spending time arguing. Not everybody
would do it, and nobody should be forced to do it (I'm not speaking
about myself here, if I disagree with something I usually make it known
;). Thus I think there's no need to add any special things - we have the
list, and if the discussion continues whithin the vote, the vote can
always be extended or even restarted.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227