Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109146
MIME-Version: 1.0
References: <14383D05-EA33-4CD2-9648-40AA29A837A5@newclarity.net>
 <CAJW__o020OgyHEixHUCtgRijhx92OA1vzuKHAF8hRTcAxo1mRg@mail.gmail.com>
 <5e72b9a7.1c69fb81.7d447.f4f1SMTPIN_ADDED_MISSING@mx.google.com>
 <CAAKU0u=548NGynGnLbQO6N84g2NSiLq1zK7X6MF-QwByzqtf=g@mail.gmail.com> <5e73304d.1c69fb81.7ae48.890cSMTPIN_ADDED_MISSING@mx.google.com>
In-Reply-To: <5e73304d.1c69fb81.7ae48.890cSMTPIN_ADDED_MISSING@mx.google.com>
Date: Thu, 19 Mar 2020 16:25:29 +0200
Message-ID: <CAJW__o25fD1S7XEYYg0oMAmkKL_d30H0vaqdOAvtMDDUQteYzQ@mail.gmail.com>
To: Mark Randall <marandall@php.net>
Cc: Internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Capturing reasons for votes for historical sake?
From: kalle@php.net (Kalle Sommer Nielsen)

Den tor. 19. mar. 2020 kl. 10.41 skrev Mark Randall <marandall@php.net>:
> How is the RFC author expected to document the reasons people are voting
> no, if those voting against do not take the time to give even a brief
> explanation of why they did so either prior to the vote during the
> discussion period, or as part of voting?
>
> An unexplained "no" vote carries just as much weight as a yes vote,
> while being demonstrably less valuable to the community. At least when
> voting "yes" you're basically saying you agree with the arguments made
> in favour as presented by the RFC.

That fully depends on the topic in question. We have a lot of people
who are voting thats not actively involved with the core development
of the language itself from a code perspective. This means that also
any random voter that just votes yes causes additional work on the
hands of the active code maintainers. I think last year's vote on the
JIT here is a great example of the complexity that I think a very low
percentage of the voters in favor understands.

Why are we only attempting to harvest the negative thoughts (with the
word negative chosen carefully here as voting "No" is seemingly an
offense to some), why do we not also record why a feature was voted
in? Take the recent Stringable interface RFC, now we have one special
interface that is magically added but only for objects containing
__toString(). A valid question (to me at least, given I voted against
it) would be why we would want this almost seemingly random magic to
occur but only for this one instance. Since no such data is recorded
either, I can only assume that this is acceptable to most.

My point here is that it does both ways. If you wish to hold a survey
for such fair enough, but I do not want such to bloat RFCs so that it
morally questions my choices when I vote in the sense that I think is
best suited. I understand the curiosity but I do not wish for us to
fall so deep because someone on Reddit or what not believes anyone who
votes against something has to be pulled in for questioning.


-- 
regards,

Kalle Sommer Nielsen
kalle@php.net