# Capturing reasons for votes for historical sake?

- Thread: https://externals.io/message/109076
- Original archive: https://news-web.php.net/php.internals/109076
- Started by Mike Schinkel on 2020-03-16T18:29:05+00:00
- Messages: 28
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/109076.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #109076 — Mike Schinkel — 2020-03-16T18:29:05+00:00

URL: https://externals.io/message/109076#109076

Hi all,

Seeing people referencing former RFCs that failed when someone brings up an RFC (which is a good thing to reference, BTW) I am finally compelled to comment in hope there would be will to improve it.

When court justices rule on important decisions they write opinions, or join with the majority or minority opinion. That way judges and others in the future can know why things were decided a certain way.  

However in PHP we have no way of knowing why people voted against a proposal except maybe for those very few who commented negatively on the mailing list. Which is far from concise and frequently not conclusive. 

It is a real shame that the PHP voting process has no way to capture a concise description of why people voted against an RFC.  A "No" vote could mean any of the following, or something completely different, and their reasons are really important when it comes to future consideration of the same issue:

1. I hate the idea and never want to see it in PHP
2. I'm okay with the idea but 
	a. I have a small issue with "x"
	b. I have a big issue with "y"
	c. I prefer to see it implemented using "z" approach instead
3. I love the idea but 
	a. Can't support it given "x"
	b. I want it to be implement using "y" approach instead
4. We can't do this until we do "x" first
5. We should do "x" instead
6. Or who knows what other reason?

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 OR select from the reasons that others have already given when voting down the specific RFC?  

If we had that we could list the reasons and the number of votes that choose those reasons on the RFC for historical purposes.

-Mike

---

## #109080 — Jakob Givoni — 2020-03-16T19:08:28+00:00

URL: https://externals.io/message/109076#109080 · In reply to: #109076

> If we had that we could list the reasons and the number of votes that choose those reasons on the RFC for historical purposes.

Thanks Mike, exactly what I was thinking when I started writing RFC:
COPA (https://wiki.php.net/rfc/compact-object-property-assignment)!

As you can see in my "Voting" section, I had the idea to capture
reasons for no-votes, to document it in the outcome of the RFC, should
it fail.
It would have saved my research quite a bit if I had had the no-vote
reasons for the RFCs I reference at the bottom.

+1 on the idea from me!

---

## #109084 — Dan Ackroyd — 2020-03-17T01:20:05+00:00

URL: https://externals.io/message/109076#109084 · In reply to: #109076

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

---

## #109092 — Jakob Givoni — 2020-03-17T02:31:09+00:00

URL: https://externals.io/message/109076#109092 · In reply to: #109084

> * 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.
Maybe a list of standard answers to choose from could be a good
compromise:
- Don't like the syntax
- Don't find the feature useful
- Limits future changes
- There are better solutions
- Is complicated to implement
- Breaks backwards compatibility
- Prefer not to say

All are valid reasons for voting no.
If there are multiple applicable reasons, just pick one.
Or allow picking multiple?
If having to pick one of these is enough to drive people away,
maybe it's for the best... ;-D

> For some RFCs, there just isn't a good path forward for them.
Even so, giving a reason for voting no will make that much clearer,
and maybe stop more RFCs in their tracks.

> 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.
True, - but likewise, there are purist who don't use PHP in the real world
and reject something pragmatic because it's not fancy enough.
It's important to be humble in a democracy.

Best regards,
Jakob

---

## #109093 — Mike Schinkel — 2020-03-17T03:01:31+00:00

URL: https://externals.io/message/109076#109093 · In reply to: #109084

> 
> 
> 
> > […]
> 
> Pretty strong no for me.

Thank you for your reply.  Let me start with the end of your reply, what you state was your biggest issue:

> And the big issue, where possibly I disagree with your reasons for wanting this:
> 
> > […]
> 
> 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.

Actually no.  You are assuming wrong.

If we had history we could better see the RFCs that had valid reasons for not passing and that should not be revisited vs. the ones that didn't pass for some technicality and didn't pass because the timing was not right that should be revisited.  

If we knew WHY RFCs were turned down then the next time someone brings the issue up again — which we they will — we could say "Here, read this. Chances are this idea will never pass for the reasons explained, so don't waste all of our bandwidth (unless you can counter all those objections, which you probably cannot.)"

So actually part of what I am asking for is a way to put the bad ones down, and for good.

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

I can certainly understand that perspective. But what's the proposal to improve that situation?  

Actually, I think you are under-appreciating what I proposed. Consider if instead of a "Yes/No" prompting people to vote, there was a list of reasons to vote "no" from those who already voted no. Isn't it likely that people who got to review that list would be more likely to vote "no" in the case of something that should not actually be accepted?

(To be fair, if we did that we'd probably need a list of reason why people votes "yes" too so that voters could see why others voted yes and no.)

(BTW, I do think having a good history of why things failed might keep bad ones from being approved in the future "accidentally.")

> > […]
> 
> I think this type of analysis belongs off-list. Which is why:
> https://github.com/Danack/RfcCodex/blob/master/rfc_codex.md

That's nice, but requires superhuman efforts on one individual's part, is contained on the GitHub account controlled by one individual, and is inherently slanted by one individual's bias, even if only unconscious bias.  

So it is really not a solution for the PHP community in general, notwithstanding that it is a nice resource that you have provided of your own industriousness.

> * Explaining exactly why you're voting no can be hard as there can be
> multiple overlapping reasons for voting no.

1. Nothing I proposed would stop someone from listing multiple reasons.  Free-form text would allow someone to write a dissertation, if they desire. 

2. If someone votes "no" but cannot put it into words, it is really fair that are driving the destiny of PHP used by ~5 million programmers?

3. There is nothing that In I am proposing that would stop you from just typing in "I really don't like this" and leave it at that.

> * It sets up arguments about what is and isn't a valid reason for voting no.

Not sure how this is relevant.  Once it is voted down it doesn't matter if people felt the reasons were valid or not, it would still be voted down.

BTW, I am not proposing that the reasons be tied to individuals. Those would be separated from the vote and displayed anonymously.  So who specifically would they argue with?  Unless of course you are earnestly concerned about this syndrome: https://imgur.com/gallery/91sn32Q

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

That is why I proposed that they could select from the list of all other things people have provided. If someone does not want to type a reason then just pick from one of the reasons other people already submitted.

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

Currently it takes herculean effort to get almost anything approved, but it takes effectively zero effort to stifle the hard work someone invests in trying to improve PHP. Is it really just that all their work can be nullified by a simple thumbs down like an emperor deciding the death of a gladiator? (sorry, couldn't resist using that analogy. ;-)

BTW, I am thinking of the outrageous amount of work Paul M Jones is putting into Server-Side Request and Response Objects (v2) and fear for him that all his effort will be for naught, and he won't even have a concise list of reasons why it was voted down. The best he will be able to do is infer from the comments in thousands of the messages why people voted down. But he still won't know. 

Frankly it also feels to me that people seeing that will be a lot more likely to be be driven away from the project than the fact that people who have already gotten the right to vote on the project actually have to write a sentence or two to go along with their votes. I know that if people vote down his work after all his effort I will feel less like contributing for fear of the same outcome. But being told that I am expected to help future people by recording my reason to vote? Hell, I'd feel like I was being granted an honor and I would want to rise to the occassion.

It is almost like you are arguing the with great power comes no responsibility (sorry, couldn't resist using allusion, either. ;-)

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

In which case we would be no worse off than we are now.

However, if even only 1/3 the people who voted actually did provide an intelligible reason then we'd be much farther along to know how and why we should reconsider something in the future, OR NOT.  

And this might stop a *lot* of wasted effort. Otherwise we continue to be "Those who are ignorant of the past are doomed to repeat it."  

-Mike

P.S. Some modifications to the proposal might include:

1. As Jakob Givoni proposed: a list of predetermined reasons even the first voter course pick from a list , OR they would write their own if they want.

2. Create a two (2) phase process.  

Phase 1: Solicit people enter a short concise reason to vote "no" or "yes", or to select to join one of the existing reasons. This is basically everyones way to lobby for yes or no.

Phase 2: Do the actually vote where people can select a reason from the list to go with their vote, or enter a new one.

---

## #109095 — Nikita Popov — 2020-03-17T08:26:26+00:00

URL: https://externals.io/message/109076#109095 · In reply to: #109080

> 
> > […]
> choose those reasons on the RFC for historical purposes.
>
> Thanks Mike, exactly what I was thinking when I started writing RFC:
> COPA (https://wiki.php.net/rfc/compact-object-property-assignment)!
>
> As you can see in my "Voting" section, I had the idea to capture
> reasons for no-votes, to document it in the outcome of the RFC, should
> it fail.
> It would have saved my research quite a bit if I had had the no-vote
> reasons for the RFCs I reference at the bottom.
>
> +1 on the idea from me!
>

FWIW this has been discussed a few times already, and I believe the
consensus is: We're happy to have *optional* reasons for votes, if someone
actually implements it.

For the number of times someone has brought this up on list, there has been
a distinct lack of volunteers for actually making it happen ;)

Nikita

---

## #109096 — Christoph M. Becker — 2020-03-17T08:44:43+00:00

URL: https://externals.io/message/109076#109096 · In reply to: #109095

> 
>
> > […]
>
> FWIW this has been discussed a few times already, and I believe the
> consensus is: We're happy to have *optional* reasons for votes, if someone
> actually implements it.
>
> For the number of times someone has brought this up on list, there has been
> a distinct lack of volunteers for actually making it happen ;)

If anybody wants to take a stab at this, patching the doodle plugin[1]
would be the way to go.

[1]
<https://github.com/php/web-wiki/tree/master/dokuwiki/lib/plugins/doodle>

--
Christoph M. Becker

---

## #109103 — Paul M. Jones — 2020-03-17T13:11:43+00:00

URL: https://externals.io/message/109076#109103 · In reply to: #109076

> 
> 
> Hi all,
> 
> It is a real shame that the PHP voting process has no way to capture a concise description of why people voted against an RFC.
...
> 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 OR select from the reasons that others have already given when voting down the specific RFC?  

I would be against making it a *requirement* but I sure would be happy to see it as an *option*.


-- 
Paul M. Jones
pmjones@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

---

## #109110 — Mike Schinkel — 2020-03-17T19:32:08+00:00

URL: https://externals.io/message/109076#109110 · In reply to: #109095

> 
> 
> 
> 
> > […]
> 
> Thanks Mike, exactly what I was thinking when I started writing RFC:
> COPA (https://wiki.php.net/rfc/compact-object-property-assignment)!
> 
> As you can see in my "Voting" section, I had the idea to capture
> reasons for no-votes, to document it in the outcome of the RFC, should
> it fail.
> It would have saved my research quite a bit if I had had the no-vote
> reasons for the RFCs I reference at the bottom.
> 
> +1 on the idea from me!
> 
> FWIW this has been discussed a few times already, and I believe the consensus is: We're happy to have *optional* reasons for votes, if someone actually implements it.
> 
> For the number of times someone has brought this up on list, there has been a distinct lack of volunteers for actually making it happen ;)
> 
> Nikita

Hi Nikita,

What would be required to implement it?  I assume it is in PHP code?  What access would be required?

-Mike

---

## #109111 — Mike Schinkel — 2020-03-17T19:33:31+00:00

URL: https://externals.io/message/109076#109111 · In reply to: #109096

> 
> 
> 
> 
> > […]
> 
> If anybody wants to take a stab at this, patching the doodle plugin[1]
> would be the way to go.
> 
> [1]
> <https://github.com/php/web-wiki/tree/master/dokuwiki/lib/plugins/doodle>

Ah, I see.  So set up https://github.com/php/web-wiki locally and I'd have what I need?

-Mike

---

## #109112 — Mike Schinkel — 2020-03-17T19:35:29+00:00

URL: https://externals.io/message/109076#109112 · In reply to: #109103

> 
> 
> 
> 
> > […]
> ...
> > […]
> 
> I would be against making it a *requirement* but I sure would be happy to see it as an *option*.

Just curious if the "requirement" was only "you have to enter in something" would that still be an issue for you?  

It is not like we could reasonably validate that they entered something intelligible.  

They could just say "I don't like" and that would meet the "requirement."

> -- 
> Paul M. Jones
> pmjones@pmjones.io
> http://paul-m-jones.com
> 
> Modernizing Legacy Applications in PHP
> https://leanpub.com/mlaphp
> 
> Solving the N+1 Problem in PHP
> https://leanpub.com/sn1php

---

## #109113 — Stanislav Malyshev — 2020-03-17T20:03:05+00:00

URL: https://externals.io/message/109076#109113 · In reply to: #109076

Hi!

> 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 OR select from the reasons that others have already given
> when voting down the specific RFC?

As an optional feature, it might be helpful. But it shouldn't be mandatory.
-- 
Stas Malyshev
smalyshev@gmail.com

---

## #109130 — Christoph M. Becker — 2020-03-18T21:52:51+00:00

URL: https://externals.io/message/109076#109130 · In reply to: #109111

> > […]
>
> Ah, I see.  So set up https://github.com/php/web-wiki locally and I'd have what I need?

It might work to install a plain DokuWiki, and to put the repo contents
on top.  Otherwise, see
<https://github.com/php/web-wiki/blob/master/docs/README.CONFIGURE>.

--
Christoph M. Becker

---

## #109131 — Kalle Sommer Nielsen — 2020-03-18T23:22:56+00:00

URL: https://externals.io/message/109076#109131 · In reply to: #109076

Den man. 16. mar. 2020 kl. 20.29 skrev Mike Schinkel <mike@newclarity.net>:
>
> Hi all,
>
> Seeing people referencing former RFCs that failed when someone brings up an RFC (which is a good thing to reference, BTW) I am finally compelled to comment in hope there would be will to improve it.
>
> When court justices rule on important decisions they write opinions, or join with the majority or minority opinion. That way judges and others in the future can know why things were decided a certain way.
>
> However in PHP we have no way of knowing why people voted against a proposal except maybe for those very few who commented negatively on the mailing list. Which is far from concise and frequently not conclusive.
>
> It is a real shame that the PHP voting process has no way to capture a concise description of why people voted against an RFC.  A "No" vote could mean any of the following, or something completely different, and their reasons are really important when it comes to future consideration of the same issue:
>
> 1. I hate the idea and never want to see it in PHP
> 2. I'm okay with the idea but
>         a. I have a small issue with "x"
>         b. I have a big issue with "y"
>         c. I prefer to see it implemented using "z" approach instead
> 3. I love the idea but
>         a. Can't support it given "x"
>         b. I want it to be implement using "y" approach instead
> 4. We can't do this until we do "x" first
> 5. We should do "x" instead
> 6. Or who knows what other reason?
>
> 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 OR select from the reasons that others have already given when voting down the specific RFC?
>
> If we had that we could list the reasons and the number of votes that choose those reasons on the RFC for historical purposes.

I am not gonna personally answer a survey everytime I vote against a
feature. This is why we have a discussion period to raise issues, of
course not everyone will raise all their concerns to each and every
RFC (me included, take the annotation RFCS posted over the years, they
are awesome but the one thing I dislike is the syntax). I doubt
everyone have time to go in details and understand to the teeth what
each and every feature does. I instead recommend that you look at Dan
Ackroyd's repository which he linked in his reply.

Similar to him, I'm also fairly against the development of such a feature.

-- 
regards,

Kalle Sommer Nielsen
kalle@php.net

---

## #109132 — Mark Randall — 2020-03-19T00:15:14+00:00

URL: https://externals.io/message/109076#109132 · In reply to: #109131

> I am not gonna personally answer a survey everytime I vote against a
> feature. This is why we have a discussion period to raise issues, of
> course not everyone will raise all their concerns to each and every
> RFC (me included, take the annotation RFCS posted over the years, they
> are awesome but the one thing I dislike is the syntax). I doubt
> everyone have time to go in details and understand to the teeth what
> each and every feature does. 

If a person doesn't have the time or inclination to read into the 
details of an RFC, and also doesn't have time or inclination to engage 
in discussion about it, and also doesn't have the time or inclination to 
give even the briefest of justification about why they are casting their 
vote a particular way to help inform future discussion...

Well, they shouldn't be casting a vote in the first place.

That's not to suggest everyone should need to be able to analyse the 
patch line by line, but if a person is cleary *that* disengaged then IMO 
they should do the honourable thing and refrain from voting.

MR.

---

## #109133 — Jakob Givoni — 2020-03-19T02:44:18+00:00

URL: https://externals.io/message/109076#109133

> Well, they shouldn't be casting a vote in the first place.
Hear! Hear!

Ok, I don't mean to be harsh, but rather to demonstrate a way that you can
express agreement with something someone else has said without repeating
it.
Maybe if more voters participated in discussions in this simple way, asking for
voting reasons post hoc would not come up time and time again...

Or to vary it:
- Ditto
- I agree
- True
- What (s)he said

---

## #109134 — Levi Morrison via internals — 2020-03-19T03:46:54+00:00

URL: https://externals.io/message/109076#109134

It is my opinion that voting "no" should not require any more effort
than voting "yes". Voting "no" is just as reasonable as voting "yes".
We do not need to justify our opinion.

The burden of documenting the historical reasons for "no" should be
placed on the RFC authors, not the voters.

---

## #109135 — Stanislav Malyshev — 2020-03-19T06:15:36+00:00

URL: https://externals.io/message/109076#109135

Hi!

> If a person doesn't have the time or inclination to read into the
> details of an RFC, and also doesn't have time or inclination to engage
> in discussion about it, and also doesn't have the time or inclination to
> give even the briefest of justification about why they are casting their
> vote a particular way to help inform future discussion...
> 
> Well, they shouldn't be casting a vote in the first place.

And how you intend to ensure that? You can't ask for a graded 500-word
essay proving the voters understand the issues. If somebody wants to
vote "no" or "yes" without reading, asking for reasons won't help.

-- 
Stas Malyshev
smalyshev@gmail.com

---

## #109138 — Mark Randall — 2020-03-19T08:41:36+00:00

URL: https://externals.io/message/109076#109138 · In reply to: #109134

> The burden of documenting the historical reasons for "no" should be
> placed on the RFC authors, not the voters.

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.

But saying no... without offering any kind of input or debate? How does 
that help anyone improve things?

Stas asks how I would intend to ensure people are engaged without a 500 
word essay? The answer SHOULD be that I nor someone else should have to. 
Each individual voter should have the self disipline to refrain if they 
haven't put in the necessary work.

In the absence of that self restraint, yes, requiring some kind of 
reasoning at the time of voting is entirely appropriate, and then it 
should be up to the community to decide if people are trying to 
deliberately flout the spirit of that requirement and take action 
accordingly.

I'm not suggesting anything exam-like to prove the voters knowledge, but 
it *should* provide at least some qualitative feedback for the RFC 
author and the wider community.

Mark Randall

---

## #109142 — Dan Ackroyd — 2020-03-19T10:57:53+00:00

URL: https://externals.io/message/109076#109142

Danack wrote:
>
> It sets up arguments about what is and isn't a valid reason for voting no.

In case anyone was wondering if this was a vague or actual concern:

Mark Randall wrote:
>
> it should be up to the community to decide if people are trying to
> deliberately flout the spirit of that requirement and take action
> accordingly.

This type of argument leads us on a path to personal attacks.

Optionally having some space to record people's reasons for voting
either way might be useful. Requiring people to justify their reasons
is going to lead to massive non-productive arguments, or even people
being harassed for voting 'wrong'.

And I agree with Levi, voting "no" should not require any more effort
than voting "yes".

This thread has focused on people voting no. Although I disagree with
some decisions people make, I can't see a large problem of RFCs that
have been declined without reasonable reasons. If anything, the
problem is the other way round, with people who are not core
maintainers, voting yes on things that they can't fully comprehend,
and won't be the ones doing the maintenance work for the RFC. But I
don't think asking people to prove that they've fully understood an
RFC is a useful thing to do.

cheers
Dan
Ack

---

## #109146 — Kalle Sommer Nielsen — 2020-03-19T14:25:29+00:00

URL: https://externals.io/message/109076#109146

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

---

## #109148 — Mark Randall — 2020-03-19T15:20:34+00:00

URL: https://externals.io/message/109076#109148 · In reply to: #109146

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


Well a significant part of the purpose of the RFC is to make the case 
for why it *should* be done, and the benefits in doing so, and only to 
bring it to vote once the negatives have either been resolved, or are 
just down to personal preference.

To vote yes is to state your overall agreement with the arguments made 
in the RFC. If you've read up and want to vote "no", I think that is 
perfectly fine and should be fully encouraged, but do the decent thing 
for your fellow developers and explain why so they're not left trying to 
guess.

Ultimately, how can an RFC ever be improved to be more widely acceptable 
if the people voting in the negative don't give feedback?

---

## #109150 — Mike Schinkel — 2020-03-19T15:36:56+00:00

URL: https://externals.io/message/109076#109150 · In reply to: #109142

> 
> 
> Mark Randall wrote:
> > […]
> 
> This type of argument leads us on a path to personal attacks.
> 
> Optionally having some space to record people's reasons for voting
> either way might be useful. Requiring people to justify their reasons
> is going to lead to massive non-productive arguments, or even people
> being harassed for voting 'wrong'.

Since I started this thread, please let me explain what I was envisioning.

I was envisioning that the list of reasons would be displayed *separately* from the voting results. 

I was not envision displaying any visible linkage between voters and who gave what reason. I was simply envisioning that the RFC page — for posterity — would just list the reasons and the number of people who selected that reason for their vote.  

The reasons could be multi-select, so it would be effectively impossible to guess who gave what reasons, unless someone used the same words in an email exchange at which point they already made their views public.

So I envisioned the proposal as a this way specifically to avoid setting up people for personal attacks.

To Mark's point, *if* the community sees that there are a lot of nonsense reasons — by which I mean real nonsense like "Because I don't like Mondays" — then people in the community can comment on it and make a generic plea to whomever is giving nonsense reasons anonymously to please stop. Since the goal of capturing these reasons is to capture legitimate history for the benefit of PHP and all who may contribute to it in the future, the request could be "Stop being a a jerk and instead please help the community."

Said a different way, I saw this as a way each person voting could help the collective community improve over time and NOT as a way for individuals to be put into any position of having to _justify_ their reasons, hence the anonymity.

If I may, please let me share this video which really captures the essence of how I am hoping everyone will view this, as a way to make things slightly better for everyone wanting to contribute to the PHP community and not as any kind of draconian imposition on any individual's rights:

https://www.youtube.com/watch?v=BdL91IMl7gc


> And I agree with Levi, voting "no" should not require any more effort
> than voting "yes".
> 
> This thread has focused on people voting no.

That is my fault for emphasizing "no."  

I emphasized "no" votes because they inevitably result in the topic resurfacing in the future, often again and again. 

For a successful RFC people do not constantly ask for the feature again and again, for obvious reasons.

OTOH, what about declined RFCs?  Having people's reasons for "yes" would be as helpful for future contributors as having people's reasons for "no."  

So I agree, there should not be a difference in effort required between "yes" or "no."


> Although I disagree with some decisions people make, I can't see a
> large problem of RFCs that have been declined without reasonable
> reasons. 

To be clear, the goal of my straw man proposal was *not* to allow seconding guessing or challenging of decisions made.  

The goal was to capture the decisions concisely in a single location for an RFC so that people in the future will have visibility into those collective reasons.  

> If anything, the problem is the other way round, with people who are
> not core maintainers, voting yes on things that they can't fully comprehend,
> and won't be the ones doing the maintenance work for the RFC. 


Look at it this way.  Consider you are a core maintainer and you feel strongly that many people asking for things don't fully comprehend the ramifications?  

For you being able to highlight a concise reason you voted "no" on an RFC that future readers will almost certainly see — vs. just commenting on the mailing list which requires a motivated person to find to — will allow you to point people in the future who ask for the same thing (yet again) to the reasons why it was voted down. And that list will include your reasons as well as others. 

Thus *hopefully* pointing people to the previously decided list of reasons will nip a potentially long, potentially contentious and potentially draining negative email thread in the bud because — for that feature request — it is already known for pretty damn certain that it simply won't happen in PHP.

Given the above, I think the people who vote "no" because they really do not want to ever see a proposal pass would *want* to document their reasons in hopes it would stop people in the future from trying to re-litigate the feature.

Why do I personally care about this?  Because I want to request things in PHP, but I know that doing so successfully requires a herculean effort, and I do not want to commit that time and effort to something that I know has already been decided against by those with a vote for reasons that are insurmountable.

> But I don't think asking people to prove that they've fully understood an
> RFC is a useful thing to do.

I complete agree.  

What I envisioned was to capture the reasons for the benefit of future contributors and not to provide a mechanism for passing judgements on those reasons or provide a mechanism for retaliation against voters who make a decision that someone else does not like.

-Mike

P.S. I am working on a critical project with a deadline in late April but after that I hope to try to create an update to the wiki that would let people see how this feature could work. (I have been looking for a way to contribute since I can't currently write C code for PHP core.)

---

## #109153 — Rowan Tommins — 2020-03-19T20:46:13+00:00

URL: https://externals.io/message/109076#109153 · In reply to: #109093

Hi Mike,


> Currently it takes herculean effort to get almost anything approved, but it takes effectively zero effort to stifle the hard work someone invests in trying to improve PHP. Is it really just that all their work can be nullified by a simple thumbs down like an emperor deciding the death of a gladiator? (sorry, couldn't resist using that analogy. ;-)
>
> BTW, I am thinking of the outrageous amount of work Paul M Jones is putting into Server-Side Request and Response Objects (v2) and fear for him that all his effort will be for naught, and he won't even have a concise list of reasons why it was voted down. The best he will be able to do is infer from the comments in thousands of the messages why people voted down. But he still won't know.


I wanted to pull this point out from further up the thread, because I 
think it's a very real concern, but I think it's about something more 
fundamental than how people vote.

Large RFCs, where there's significant implementation work, are 
essentially software projects. If we ran them that way, we'd all 
collaborate on some sequence of steps (or several agile iterations, or 
whatever), such as:

* Identifying the problem or aim
* Defining the scope
* Identifying risks
* Agreeing an approach
* Initial implementation or prototype
* Discovering problems based on the initial work
* Testing
* Final sign-off for release (this is what RFC votes should be)


The problem is that the RFC process only really covers a small fraction 
of that process, and mostly the later parts. Most of the effort, and 
crucially most of the decisions, are left to whoever is drafting the 
RFC. So we end up with a process that feels more like a sales pitch for 
a shrink-wrapped product:

* The RFC author identifies a problem, defines the scope, tries to 
identify risks, designs a solution, maybe builds an initial 
implementation or prototype, and starts refining and testing it
* This is pitched to the community
* There is some negotiation, usually over details rather than 
substantial rewrites, and often involving the author defending the 
decisions they've already made
* The community decides whether to "buy" the proposal (this is what RFC 
votes often turn into)

Some RFCs are rejected because the community doesn't actually agree on 
the definition of the problem or scope; capturing that in a reason for 
voting No might help someone later, but it's already far too late to 
save the effort of the author. Other RFCs are rejected because the 
community agrees on the problem, but not the details of the solution; 
writing that down encourages someone to try again, but repeatedly trying 
variations until one passes might not be the most efficient process.


Just to be clear, I am not blaming authors for bringing ready-made 
pitches like this - it's what the current process tells them to do. Nor 
do I have a brilliant proposal that would change it overnight. But I do 
think we need to spend more time collaborating on ideas, and less on 
saying "yes" or "no" to each other's ready-made solutions.


Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]

---

## #109155 — Mike Schinkel — 2020-03-19T21:25:39+00:00

URL: https://externals.io/message/109076#109155 · In reply to: #109153

> 
> 
> Hi Mike,
> 
> 
> > […]
> 
> 
> I wanted to pull this point out from further up the thread, because I think it's a very real concern, but I think it's about something more fundamental than how people vote.
> 
> Large RFCs, where there's significant implementation work, are essentially software projects. If we ran them that way, we'd all collaborate on some sequence of steps (or several agile iterations, or whatever), such as:
> 
> * Identifying the problem or aim
> * Defining the scope
> * Identifying risks
> * Agreeing an approach
> * Initial implementation or prototype
> * Discovering problems based on the initial work
> * Testing
> * Final sign-off for release (this is what RFC votes should be)
> 
> 
> The problem is that the RFC process only really covers a small fraction of that process, and mostly the later parts. Most of the effort, and crucially most of the decisions, are left to whoever is drafting the RFC. So we end up with a process that feels more like a sales pitch for a shrink-wrapped product:
> 
> * The RFC author identifies a problem, defines the scope, tries to identify risks, designs a solution, maybe builds an initial implementation or prototype, and starts refining and testing it
> * This is pitched to the community
> * There is some negotiation, usually over details rather than substantial rewrites, and often involving the author defending the decisions they've already made
> * The community decides whether to "buy" the proposal (this is what RFC votes often turn into)
> 
> Some RFCs are rejected because the community doesn't actually agree on the definition of the problem or scope; capturing that in a reason for voting No might help someone later, but it's already far too late to save the effort of the author. Other RFCs are rejected because the community agrees on the problem, but not the details of the solution; writing that down encourages someone to try again, but repeatedly trying variations until one passes might not be the most efficient process.
> 
> 
> Just to be clear, I am not blaming authors for bringing ready-made pitches like this - it's what the current process tells them to do. Nor do I have a brilliant proposal that would change it overnight. But I do think we need to spend more time collaborating on ideas, and less on saying "yes" or "no" to each other's ready-made solutions.

I completely agree that the current process is sub-optimal.  

It is basically like throwing a gladiator into the lion's den to see if they can survive.  If the person writing the RFC is good, they might get an upvote. If they have no experience with writing RFCs and/or can't implement the C code, they are most likely doomed to failure.  And PHP collectively is worse off because of this.

There is rarely if ever a collaborative process, except for what may happen ad-hoc between people off-list.

It would be great if instead of what we have know we could as a community discuss and determine a list of the top five (5) things we collectively want for PHP and put that out as a roadmap for PHP.  Maybe even plan a series of remote "conferences" over Zoom to collaborate on such a top five (5) list.

Ironically I just today read about Docker publishing their roadmap on Github:

- Docker Roadmap:  https://github.com/docker/roadmap/projects/1

From there we could solicit a working group for each of the five (5) areas to each go off to a GitHub repo to collaborate and come back with a proposal for implementing in PHP, with the proposal to include a plan for all aspects of the what's needed, not just the idea.

From there, we rinse and repeat.

Others:  Does this sound viable?

-Mike

P.S. However, even though I completely agree that the current process is suboptimal, that does not mean asking for reasons for voting for posterity should be tabled as the two concerns are orthogonal and some feedback would be more helpful to those looking to understand past votes than no feedback at all.  

More importantly, adding reasons for voting would only require an update implemented an then an vote to use it, but fixing the process is an open-ended concern that would require herded lots of cats and then to impose a much bigger change, so I wouldn't want perfect to be the enemy of the good here.

---

Next page: https://externals.io/message/109076.md?page=2