Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120155
MIME-Version: 1.0
References: <CAEKnhAEzEBRHO+=3KSLCveEWZ7ZwxtD0MJL-=VG6nz2xMcvbMA@mail.gmail.com>
 <CAAKU0unGGoN4-u0kUHB7DvjKHZgSgSTRkUywbx==Uzzt+skNxQ@mail.gmail.com>
In-Reply-To: <CAAKU0unGGoN4-u0kUHB7DvjKHZgSgSTRkUywbx==Uzzt+skNxQ@mail.gmail.com>
Date: Fri, 28 Apr 2023 21:03:26 +0100
Message-ID: <CAEKnhAEPY2SVf7Stum01FxF7MB3MY=sgoncsdKu5nvfajH5-2g@mail.gmail.com>
To: Levi Morrison <levi.morrison@datadoghq.com>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000fdb1a005fa6af7eb"
Subject: Re: [PHP-DEV] [VOTE] PHP Technical Committee
From: bukka@php.net (Jakub Zelenka)

--000000000000fdb1a005fa6af7eb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

Thanks for the feedback even though it would be great to get it during the
discussion period...

Just want to add few points in addition to what Larry wrote.

On Fri, 28 Apr 2023, 16:17 Levi Morrison, <levi.morrison@datadoghq.com>
wrote:

> On Fri, Apr 28, 2023 at 4:01=E2=80=AFAM Jakub Zelenka <bukka@php.net> wro=
te:
> >
> > 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
> >
> > Regards
> >
> > Jakub
>
> Do we really need this level of bureaucracy?


I should mention that this is something what we properly discussed between
some of the currently most active core developers and the actual scope is
pretty minimal. It just covers the conflict resolution which is currently
very frustrating for the core devs that participated on this. We mostly
tried to cover all edge cases and most parts are just theoretical and won't
likely ever be needed. It was done in this way just to prevent some future
disagreements.

I mean... I know
> someone's work got rejected and that wasn't a great situation, and I
> feel for them because it was handled poorly IMO.


Even though there are more reasons for this RFC as Larry wrote, this was a
trigger for it. The main point here is that it couldn't have been handled
correctly because we do not have any process how to resolve such situation.
Read the core devs don't have any powers to reject anything or even merge
anything that other core devs don't agree with. We don't even have formally
defined what maintainers can do even though there is some sort of respect
between core devs so maintainers opinions are mostly respected. But again
it's all a bit grey area and anyone can challenge it.

But this committee

seems like a lot of work for... what? Being able to solve an
> occasional disagreement? This seems like more work than it solves,
>

I have to disagree with this part. To be honest it is kind of contradicting
as occasional disagreement cannot by definition trigger a lot of work for
the committee because it is occasional. It means that it will be
just occasional work for the committee. In addition I would say this will
actually save time to other core devs as the decision can be delegated to
handful of them and other core devs can still concentrate on their work.
The good example was the previous situation when Dmitry had to spend way
more time than he probably wanted on trying to prevent getting those
changes in. If the decision was delegated to the TC, it could be resolved
in a much quicker way without sacrificing too much core devs time.


> with some bad downsides if "the wrong people" get in there. You know,
> the power-hungry egotistical kind of people.
>

This is exactly what we wanted to prevent and the reason why we went for
the committee instead of trying to leave decisions on maintainers. First of
all there are more people in the committee so it is quite unlikely that 5
power hungry core devs would be voted in. Secondly the powers of the TC are
pretty limited as it can decide only about technical topics and its
decision on RFC changes is also specifically limited and can happen only if
the technical issues are not specifically mentioned in the RFC - it means
they are not known to the voters. This is in no way attempt to reduce
powers of the current RFC process though.

I would like to ask all voters to try to think about this proposal from the
core developer point of view. It is absolutely fine if you don't agree with
the model (e.g. you would prefer maintainer model instead) but please try
to not reject this just based on the statements that this will be likely a
lot of work for nothing because it is likely exactly the opposite and it
might actually save time for most core developers.

Cheers

Jakub

--000000000000fdb1a005fa6af7eb--