Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120226
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: Wed, 10 May 2023 18:58:57 +0300
Message-ID: <CAL0xaBG_X0rJkW=5SzM6br+g1YaKVPEwB5C_nD7YtG_jBnVYjQ@mail.gmail.com>
To: =?UTF-8?Q?Benjamin_Au=C3=9Fenhofer?= <kontakt@beberlei.de>
Cc: Jakub Zelenka <bukka@php.net>, PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000044c5e205fb58f593"
Subject: Re: [PHP-DEV] [VOTE] PHP Technical Committee
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--00000000000044c5e205fb58f593
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 1 May 2023 at 18:09, Benjamin Au=C3=9Fenhofer <kontakt@beberlei.de>
wrote:

> On Fri, Apr 28, 2023 at 12:01=E2=80=AFPM Jakub Zelenka <bukka@php.net> wr=
ote:
>
> > Hi,
> >
> > The vote is now open for the RFC about introduction of the PHP Technica=
l
> > Committee:
> >
> > https://wiki.php.net/rfc/php_technical_committee
>
>
> 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
> b.) potentially harmful depending on who is on the TC.
> 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 keep in th=
e
> next election. However introducing these data points would make everythin=
g
> even more complicated.
>
> 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.
>

So, basically what you have said: "Let's kick the can down the road and let
somebody else deal with the issue in the future"?

The problem this RFC is trying to solve has happened multiple times. There
are numerous cases where a technical committee should have been involved,
preventing problematic implementations being put into a release (read-only
ended up, by the admission of the authors and multiple other devs, being a
mistake in the form it is now) or prevented much-needed maintenance work be
done on the code base that has nothing to do with public-facing changes.

Also, the point c) is a contradiction. The TC is meant to break indecision,
the byproduct of that is that half the people are not getting their way.
It's the nature of any decision-making, where you must make a judgement
call. So what you are saying here, is you want the decisions not to be made
at all, unless everybody sings kumbaya and drinks beer until lights out?

--=20

Arv=C4=ABds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius

--00000000000044c5e205fb58f593--