Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109084
MIME-Version: 1.0
References: <14383D05-EA33-4CD2-9648-40AA29A837A5@newclarity.net>
In-Reply-To: <14383D05-EA33-4CD2-9648-40AA29A837A5@newclarity.net>
Date: Tue, 17 Mar 2020 01:20:05 +0000
Message-ID: <CA+kxMuRkCZjWbuR1yrw8KxcM20ZxZ-7Zu8s=RAxbspLkGsjO=Q@mail.gmail.com>
To: Mike Schinkel <mike@newclarity.net>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Capturing reasons for votes for historical sake?
From: Danack@basereality.com (Dan Ackroyd)

On Mon, 16 Mar 2020 at 18:29, Mike Schinkel <mike@newclarity.net> wrote:
>
> Would it be possible to add a feature when voting were people either need to type in
> a one to two sentence reason why they voted "no" on a proposal

Pretty strong no for me.

* Explaining exactly why you're voting no can be hard as there can be
multiple overlapping reasons for voting no.

* It sets up arguments about what is and isn't a valid reason for voting no.

* It drives people who might want to vote no away from the project, if
they have to take the extra time to justify their position.

* The phrase "this is a terrible idea and I don't have enough crayons
to explain why to you" would be more likely to be used, and wouldn't
add much to the discussion.

* Shifts the part of the burden for coming up with a plan for how to
get the RFC implemented onto people who are not in favour of the RFC.

And the big issue, where possibly I disagree with your reasons for wanting this:

> and their reasons are really important when it comes
> to future consideration of the same issue

This kind of makes an assumption that all RFCs should have some path
to being passed.

For some RFCs, there just isn't a good path forward for them.

> However in PHP we have no way of knowing why people voted against a proposal

I think this type of analysis belongs off-list. Which is why:
https://github.com/Danack/RfcCodex/blob/master/rfc_codex.md

btw I think there's a bigger problem on some RFCs being accepted,
particularly where people who aren't core maintainers are voting on
things that really need an informed understanding of internals.

cheers
Dan
Ack