Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124122
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\))
Subject: Re: [PHP-DEV] [RFC] Static class
In-Reply-To: <e587554b-f24c-49fe-8658-3c15b15cc615@bastelstu.be>
Date: Sun, 30 Jun 2024 21:54:30 -0400
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <90E305AC-0D19-4E04-A12B-58A1B75E8AE8@newclarity.net>
References: <eb3f59cc-3ed8-461a-a3a4-f6ba10ed31e1@scriptfusion.com>
 <88D83E92-94BE-4548-B398-8F5C74765FFD@gmail.com>
 <882BD9E0-42E9-4C84-A144-7C1DFC4CE5EB@newclarity.net>
 <DB280533-7FBE-41CD-B841-9BB163A75280@koalephant.com>
 <9d3e9063-aecf-4c56-a17d-782e7a60fed2@bastelstu.be>
 <d075222b-0c71-4ec6-8a2d-fdaba8a727c2@scriptfusion.com>
 <e587554b-f24c-49fe-8658-3c15b15cc615@bastelstu.be>
To: =?utf-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
From: mike@newclarity.net (Mike Schinkel)

> On Jun 30, 2024, at 11:10 AM, Tim D=C3=BCsterhus <tim@bastelstu.be> =
wrote:
> I strongly favor an opinionated RFC where the RFC author did their =
research and makes it clear why the proposal is the right choice and =
backs this up by proper arguments. Of course this doesn't mean that the =
RFC author should not listen to the list discussion, but the high level =
details should be clear right from the beginning. As of now the RFC =
still has some open questions regarding "core functionality" and even =
intents to leave them as a secondary vote.

With respect, I completely support your right to choose what you favor.=20=


However, I would like to suggest there might be some negative =
consequences to your approach and request that you reconsider your what =
you favor.

Yes, if an RFC author does their research and makes it clear why the =
proposal is the right choice and backs this up by proper arguments then =
it makes for a better RFC which can more easily be reviewed.

OTOH, it limits the pool of RFC authors who can successfully achieve =
that bar to only those who know what research needs to be done and which =
arguments resonate well resonate with list members. Effectively it =
limits the successful pool of RFC authors to the list of prior =
successful RFC authors who =E2=80=94 through experience =E2=80=94 have =
developed enough knowledge about what research needs to be done and =
which arguments resonate well with list members.=20

Yes someone can overcome these experience barriers by submitting =
numerous RFCs that fail and over years of time eventually gain enough =
knowledge and experience to succeed, but realistically how many people =
will go through that gauntlet?

The problem with the approach is there over time there becomes is a =
diminishing number of individuals who can and will submit RFCs, and the =
language slowly dies:

=
https://thenewstack.io/why-php-usage-has-declined-by-40-in-just-over-2-yea=
rs/

Currently the culture of this list is people submit an RFC and if they =
can endure the crucible to come out the other side their RFC may be =
adopted. But few can endure that crucible. Further, brainstorming on the =
list =E2=80=94 as recent evidence has shown =E2=80=94 is effectively =
impossible.

The experienced RFC submitters know to go off list and work with other =
experienced RFC submitters to prepare an RFC prior to having to endure =
an onslaught of criticism from this list. The problem for new RFC =
writers is they don't know who to ask nor have the clout to approach =
people to get such collaborators.

IMO it would be better if the culture here approached would-be RFC =
writers differently.  I instead experienced RFC writers provided a bit =
of mentoring to new RFC writers, encourage them to cultivate their ideas =
in a version-controlled repo off this list, but also have the mentor =
call for list members to collaborate with the would-be RFC writer in a =
discussion forum on their repo. Once those collaborators feel the RFC is =
fully-baked then they could present to the list.=20

If that culture existed, your strongly favored well-researched and =
clearly-argued RFC could be the norm rather than the exception.

Food for thought?

-Mike
P.S. I currently have a repo for an RFC where I want to make a call for =
collaboration, but I do not know how to call for help on the list =
without attracting those who would immediately swarm the discussion =
forum to flood the channel with criticism before the ideas are even =
fully baked.