Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120170
MIME-Version: 1.0
References: <CAEKnhAEzEBRHO+=3KSLCveEWZ7ZwxtD0MJL-=VG6nz2xMcvbMA@mail.gmail.com>
 <CAEPJdumVSyuKgUT7J1oLfP901E393L7A_qwf0dMNjV3z5wThGA@mail.gmail.com>
In-Reply-To: <CAEPJdumVSyuKgUT7J1oLfP901E393L7A_qwf0dMNjV3z5wThGA@mail.gmail.com>
Date: Mon, 1 May 2023 17:29:14 +0100
Message-ID: <CAEKnhAEV7oEcgFAMu7ZuFq19ohMPWd-+VsGjmkr1tEcRNcDUAg@mail.gmail.com>
To: =?UTF-8?Q?Benjamin_Au=C3=9Fenhofer?= <kontakt@beberlei.de>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000079d38105faa45349"
Subject: Re: [PHP-DEV] [VOTE] PHP Technical Committee
From: bukka@php.net (Jakub Zelenka)

--00000000000079d38105faa45349
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

Thanks for the feedback.

On Mon, May 1, 2023 at 4:09=E2=80=AFPM Benjamin Au=C3=9Fenhofer <kontakt@be=
berlei.de>
wrote:

>
> I found this idea of a TC interesting on the outset, but after carefully
> consideirng I voted no on this RFC because
>
> a.) i believe it to be too much bearucracy for the little benefit
>

I wouldn't say that having some rules in place is a little benefit but what
I gather is that you and Levi, who also mentioned it, don't like forming
some new entity with bunch of new rules so I guess it's probably a fair
point even though I don't agree with it.


> b.) potentially harmful depending on who is on the TC.
>

This point really saddens me as it was mentioned in all no votes reasoning
and it shows that there is obviously not much trust in core devs (people
that can candidate). This is not a format that would be something new and
it works well for other projects (NodeJS, Python and many others) so
apparently they trust more their candidates. Also the scope here is even
more limited than elsewhere as I mentioned before.

It's good that you provided such feedback though as it is clear that model
based on maintainers wouldn't most likely work either as such risk is much
higher in such model.


> c.) There is also no process of overuling the TC, or voting a TC out due
> to no confidence or something. Without the votes known of TC members,
> voters of the TC have no insights into who they might want to boot or kee=
p
> in the next election. However introducing these data points would make
> everything even more complicated.
>

This is a valid point and probably something that should be there.

Ultimately, already at the moment each controversial change can be asked to
> be RFCed and then the voters can decide with arguments made by people
> knowledgable in the area. Yes, there is always some politics involved, bu=
t
> the same would be true of the TC decisions.
>

Just to clarify this is actually not exactly correct as RFC is not meant to
be used for those decisions and it has no weight unless I'm
misunderstanding the currently voted rules (see my analysis in other
thread). So technically RFC is just a poll for such decisions. But yeah we
currently use it in such way which effectively makes some sort of undefined
process.

However the main problem with the RFC process is that for purely technical
changes it could result in a set of rules that will limit core development.
When the previous disagreement happened, it ended up with this sort of RFC:
https://wiki.php.net/rfc/code_optimizations . I know that it was later
withdrawn but just imaging the impact of this being accepted and honoured.
And also why should something like this be decided by people that have
nothing to do with a core development? That was actually one of the main
triggers for this initiative and we wanted come up with something sensible
that would decide those sort of things in a better way.

Cheers

Jakub

--00000000000079d38105faa45349--