Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109150
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <CA+kxMuRoLyd6KKuBwGnrkAd-=zNnsM6NdvCZKpYgLgWCF2tuNQ@mail.gmail.com>
Date: Thu, 19 Mar 2020 11:36:56 -0400
Cc: Mark Randall <marandall@php.net>,
 PHP internals <internals@lists.php.net>,
 Kalle Sommer Nielsen <kalle@php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <7085DB1C-6145-469F-8D6E-03880A57D0A7@newclarity.net>
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>
 <5e733048.1c69fb81.553c1.7610SMTPIN_ADDED_MISSING@mx.google.com>
 <CA+kxMuRoLyd6KKuBwGnrkAd-=zNnsM6NdvCZKpYgLgWCF2tuNQ@mail.gmail.com>
To: Dan Ackroyd <Danack@basereality.com>
Subject: Re: [PHP-DEV] Capturing reasons for votes for historical sake?
From: mike@newclarity.net (Mike Schinkel)

> On Mar 19, 2020, at 6:57 AM, Dan Ackroyd <Danack@basereality.com> =
wrote:
>=20
> Mark Randall wrote:
>>=20
>> 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.
>=20
> This type of argument leads us on a path to personal attacks.
>=20
> 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.=20

I was not envision displaying any visible linkage between voters and who =
gave what reason. I was simply envisioning that the RFC page =E2=80=94 =
for posterity =E2=80=94 would just list the reasons and the number of =
people who selected that reason for their vote. =20

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 =E2=80=94 by which I mean real nonsense like "Because I =
don't like Mondays" =E2=80=94 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=3DBdL91IMl7gc


> And I agree with Levi, voting "no" should not require any more effort
> than voting "yes".
>=20
> This thread has focused on people voting no.

That is my fault for emphasizing "no." =20

I emphasized "no" votes because they inevitably result in the topic =
resurfacing in the future, often again and again.=20

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." =20

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.=20

To be clear, the goal of my straw man proposal was *not* to allow =
seconding guessing or challenging of decisions made. =20

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. =20

> 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.=20


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? =20

For you being able to highlight a concise reason you voted "no" on an =
RFC that future readers will almost certainly see =E2=80=94 vs. just =
commenting on the mailing list which requires a motivated person to find =
to =E2=80=94 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.=20

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 =E2=80=94 =
for that feature request =E2=80=94 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. =20

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.)=