[VOTE] PHP Technical Committee

Unnamed Person

3 years ago

On Fri, Apr 28, 2023 at 4:01 AM Jakub Zelenka <bukka@php.net> wrote:

>
> Hi,
>
> The vote is now open for the RFC about introduction of the PHP Technical
> Committee:
>
> https://wiki.php.net/rfc/php_technical_committee
>
> Regards
>
> Jakub

Do we really need this level of bureaucracy? 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. 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,
with some bad downsides if "the wrong people" get in there. You know,
the power-hungry egotistical kind of people.

Larry Garfield

3 years ago

On Fri, Apr 28, 2023, at 3:17 PM, Levi Morrison via internals wrote:

> On Fri, Apr 28, 2023 at 4:01 AM Jakub Zelenka <bukka@php.net> wrote:
>>
>> Hi,
>>
>> The vote is now open for the RFC about introduction of the PHP Technical
>> Committee:
>>
>> https://wiki.php.net/rfc/php_technical_committee
>>
>> Regards
>>
>> Jakub
>
> Do we really need this level of bureaucracy? 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. 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,
> with some bad downsides if "the wrong people" get in there. You know,
> the power-hungry egotistical kind of people.

It's not just about dealing with the occasional fights like over rearranged include statements, although it is partially that.  It's also about making it clear who the technical leaders are.  Right now, PHP badly suffers from the Tyranny of Structurelessness (https://www.jofreeman.com/joreen/tyranny.htm).  The TC provides a fairly low-effort way to help with that.

How does a new dev know "how things are done?" around here?  At a code level.  Basically they don't.  They have to ask people, but who to ask?  Whose answer is more trustworthy?  They don't know.

The TC is a clear place to "set the tone", technically speaking.  If it often doesn't do much, well, great.  That means things are moving smoothly.  But it's always good to have tools and processes in place *before* you need them.

> with some bad downsides if "the wrong people" get in there. You know,
> the power-hungry egotistical kind of people.

This is a common strawman argument, frankly.  Yes, any time you have a position of any authority, it's possible for it to be usurped by a malicious actor.  But malicious actors can take over unstructured systems just as well.  And benevolent actors have a harder time opposing them and doing good when hamstrung by a lack of structure or clear process.

There is a vast, vast range of possible structures between total anarchy (current PHP status quo) and a malevolent dictator lording over everyone.  Almost every major OSS project has some kind of structure and leadership and decision making process.  PHP is the only meaningful exception.

That's not because we're special.  PHP has succeeded thus far despite having an anarchic anti-pattern structure, not because of it.

The TC is a small, modest, but productive step forward to resolve practical issues.  That's exactly the sort of thing PHP keeps telling people is how to get things done.  So, let's get things done.

--Larry Garfield

Jakub Zelenka

3 years ago

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 AM Jakub Zelenka <bukka@php.net> wrote:
> >
> > Hi,
> >
> > The vote is now open for the RFC about introduction of the PHP Technical
> > 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

Rowan Collins

3 years ago

On 28 April 2023 21:03:26 BST, Jakub Zelenka <bukka@php.net> wrote:

>Hi,
>
>Thanks for the feedback even though it would be great to get it during the
>discussion period...

I was actually rather surprised to see this go to a vote. The initial thread only gathered a few replies, and then got swamped by a lot of other discussions, so it's quite possible people didn't see it, or forgot about it.

That's why it's common to send a "heads up" on the original thread, giving people a chance to revive the discussion, then only start the vote if it's still quiet, or going around in circles.

Regards,

--
Rowan Tommins
[IMSoP]

Jakub Zelenka

3 years ago

On Sat, Apr 29, 2023 at 9:54 AM Rowan Tommins <rowan.collins@gmail.com>
wrote:

> On 28 April 2023 21:03:26 BST, Jakub Zelenka <bukka@php.net> wrote:
> >Hi,
> >
> >Thanks for the feedback even though it would be great to get it during the
> >discussion period...
>
>
> I was actually rather surprised to see this go to a vote. The initial
> thread only gathered a few replies, and then got swamped by a lot of other
> discussions, so it's quite possible people didn't see it, or forgot about
> it.
>
> That's why it's common to send a "heads up" on the original thread, giving
> people a chance to revive the discussion, then only start the vote if it's
> still quiet, or going around in circles.
>
>

I agree and it's my fault as I have never done this semi step before and
completely missed it in https://wiki.php.net/rfc/howto when skimming
through it. It is kind of optional atm (just for considering) but I agree
that it's something that makes sense to do and I should have done it.

We should probably make it a separate step and have it as part of what
should be always done rather than optional bit that is part of the voting
step. I will try to improve that part and will definitely remember to do it
for the future RFCs.

Cheers

Jakub

Peter Kokot

3 years ago

On Fri, 28 Apr 2023 at 12:01, Jakub Zelenka <bukka@php.net> wrote:

>
> Hi,
>
> The vote is now open for the RFC about introduction of the PHP Technical
> Committee:
>
> https://wiki.php.net/rfc/php_technical_committee
>
> Regards
>
> Jakub

It would be also good to know why people vote no.

Clint Priest

3 years ago

> It would be also good to know why people vote no.

+1 for that, even if only a brief sentence.

Pedro Magalhães

3 years ago

On Fri, Apr 28, 2023 at 11:00 AM Jakub Zelenka <bukka@php.net> wrote:

> Hi,
>
> The vote is now open for the RFC about introduction of the PHP Technical
> Committee:
>
> https://wiki.php.net/rfc/php_technical_committee
>
> Regards
>
> Jakub
>

Hi Jakob.

Sorry for not participating in the discussion phase but I would like to
give my explanation on why I voted No.
You made a good job in distinguishing the user-facing from the technical
changes to say what can and can't be decided by the TC, but the first can't
live with the second.
Then, it allows the TC to have conversations and vote in private in matters
that until today have always been public. Of course developers are allowed
to talk to each other wherever they want, but what matters is said in
public.
"unless the provided implementation would result in introduction of new
bugs, side effects not mentioned in the RFC, significant performance
penalties not mentioned in RFC, or if there is an equivalent implementation
in progress that the TC finds more appropriate." is ample enough that it
can allow anything to be rejected.

Overall, the idea of having a group of people that developers can ask for
some guidance from is great, but that group shouldn't have any extra rights
to block anything whatsoever.

To demonstrate good faith and unequivocally show that this is not an
attempt at a power grab, it would be a nice gesture for the authors of the
RFC to include their withdrawal from ever holding a seat in the technical
council in the text of the RFC itself.

Best regards,
Pedro

Jakub Zelenka

3 years ago

Hi,

Thanks for the feedback and explaining your no vote. That's really
appreciated and would be great if other no voters could do so as well.

On Sun, Apr 30, 2023 at 10:36 PM Pedro Magalhães <mail@pmmaga.net> wrote:

> On Fri, Apr 28, 2023 at 11:00 AM Jakub Zelenka <bukka@php.net> wrote:
>
>> Hi,
>>
>> The vote is now open for the RFC about introduction of the PHP Technical
>> Committee:
>>
>> https://wiki.php.net/rfc/php_technical_committee
>>
>> Regards
>>
>> Jakub
>>
>
> Hi Jakob.
>
> Sorry for not participating in the discussion phase but I would like to
> give my explanation on why I voted No.
> You made a good job in distinguishing the user-facing from the technical
> changes to say what can and can't be decided by the TC, but the first can't
> live with the second.
>

Well obviously you cannot have user facing change without implementation.
But you can have a general idea accepted without the implementation (or
with just some base implementation showing that it might work). This is
actually how the spec based languages work. Firstly the spec is created and
then it is implemented. I know PHP is not a spec based language but there
is no requirement for the implementation in the current RFC process. It is
all just about the proposal. Of course there is a better chance to get it
accepted with a good implementation done but it is not a requirement.

Then, it allows the TC to have conversations and vote in private in matters

> that until today have always been public. Of course developers are allowed
> to talk to each other wherever they want, but what matters is said in
> public.
> "unless the provided implementation would result in introduction of new
> bugs, side effects not mentioned in the RFC, significant performance
> penalties not mentioned in RFC, or if there is an equivalent implementation
> in progress that the TC finds more appropriate." is ample enough that it
> can allow anything to be rejected.
>
>

So the fact that the RFC passes does not necessarily mean that the
implementation will be merged. It will most likely won't get merged if it
introduces some security issues or problems that were not envisioned during
the RFC process. This is just to make that decision about quality of the
implementation more formal and have some process to decide it.

> Overall, the idea of having a group of people that developers can ask for
> some guidance from is great, but that group shouldn't have any extra rights
> to block anything whatsoever.
>
> To demonstrate good faith and unequivocally show that this is not an
> attempt at a power grab, it would be a nice gesture for the authors of the
> RFC to include their withdrawal from ever holding a seat in the technical
> council in the text of the RFC itself.
>

Well this is a collaboration effort which you can see in the linked PR.
Being an author does not really mean anything here. The proposal is to have
5 people in the committee that need to be already a core developers and
they react only to issues raised by other core developers. So I can't
really imagine how this could significantly change things and be a "power
grab". It is purely about deciding the conflicts between people that have
got already powers to potentially block things. It is basically just about
finding an agreement between core developers.

I have just done some analysis of the current RFC process in
https://news-web.php.net/php.internals/120167 where you can hopefully see
that this does not take any powers from the current RFC process.

Cheers

Jakub

Benjamin Eberlei

3 years ago

On Fri, Apr 28, 2023 at 12:01 PM Jakub Zelenka <bukka@php.net> wrote:

> Hi,
>
> The vote is now open for the RFC about introduction of the PHP Technical
> 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 the
next election. However introducing these data points would make everything
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, but
the same would be true of the TC decisions.

Jakub Zelenka

3 years ago

Hi,

Thanks for the feedback.

On Mon, May 1, 2023 at 4:09 PM Benjamin Außenhofer <kontakt@beberlei.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 keep
> 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, but
> 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

Arvids Godjuks

3 years ago

On Mon, 1 May 2023 at 19:29, Jakub Zelenka <bukka@php.net> wrote:

> Hi,
>
> Thanks for the feedback.
>
> On Mon, May 1, 2023 at 4:09 PM Benjamin Außenhofer <kontakt@beberlei.de>
> wrote:
>
> 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
>

I do want to point out that framing what happened with that RFC as
"withdrawn" is analogous to "covering up a murder".

The Internals list basically bullied a new contributor to dropping it and
made them give up on ever committing their work to the PHP project.
Actually, multiple people, because if I understand it correctly, there was
at least one colleague of them who also was doing some work and they
dropped everything too.

--

Arvīds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius

Arvids Godjuks

3 years ago

On Mon, 1 May 2023 at 18:09, Benjamin Außenhofer <kontakt@beberlei.de>
wrote:

> On Fri, Apr 28, 2023 at 12:01 PM Jakub Zelenka <bukka@php.net> wrote:
>
> > Hi,
> >
> > The vote is now open for the RFC about introduction of the PHP Technical
> > 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 the
> next election. However introducing these data points would make everything
> 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, but
> 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?

--

Arvīds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius

Jakub Zelenka

3 years ago

On Fri, Apr 28, 2023 at 11:00 AM Jakub Zelenka <bukka@php.net> wrote:

> Hi,
>
> The vote is now open for the RFC about introduction of the PHP Technical
> Committee:
>
> https://wiki.php.net/rfc/php_technical_committee
>
> Regards
>
>

The voting ended with 10 yes votes and 21 no votes. It means that the RFC
has been declined. Thanks for voting.

Regards

Jakub

Larry Garfield

3 years ago

On Fri, May 12, 2023, at 11:57 AM, Jakub Zelenka wrote:

> On Fri, Apr 28, 2023 at 11:00 AM Jakub Zelenka <bukka@php.net> wrote:
>
>> Hi,
>>
>> The vote is now open for the RFC about introduction of the PHP Technical
>> Committee:
>>
>> https://wiki.php.net/rfc/php_technical_committee
>>
>> Regards
>>
>>
> The voting ended with 10 yes votes and 21 no votes. It means that the RFC
> has been declined. Thanks for voting.
>
> Regards
>
> Jakub

For those who voted no, I would kindly ask: What is your alternative?

We have an organizational/structural problem.  This isn't really debatable.  An eager new contributor was just bullied out of contributing, and the one process we have for dealing with it (RFCs) failed miserably to handle the situation.

Ignoring the problem is a bad option.  If the TC proposal isn't your preferred way to address it, OK, what is?  "Do nothing, it's OK if people occasionally get bullied out of contributing" is not an answer.

--Larry Garfield

Andreas Heigl

3 years ago

Hey Larry, Hey all

On 12.05.23 16:42, Larry Garfield wrote:

> On Fri, May 12, 2023, at 11:57 AM, Jakub Zelenka wrote:
>> On Fri, Apr 28, 2023 at 11:00 AM Jakub Zelenka <bukka@php.net> wrote:
>>
>>> Hi,
>>>
>>> The vote is now open for the RFC about introduction of the PHP Technical
>>> Committee:
>>>
>>> https://wiki.php.net/rfc/php_technical_committee
>>>
>>> Regards
>>>
>>>
>> The voting ended with 10 yes votes and 21 no votes. It means that the RFC
>> has been declined. Thanks for voting.
>>
>> Regards
>>
>> Jakub
>
> For those who voted no, I would kindly ask: What is your alternative?
>
> We have an organizational/structural problem.  This isn't really debatable.  An eager new contributor was just bullied out of contributing, and the one process we have for dealing with it (RFCs) failed miserably to handle the situation.
>
> Ignoring the problem is a bad option.  If the TC proposal isn't your preferred way to address it, OK, what is?  "Do nothing, it's OK if people occasionally get bullied out of contributing" is not an answer.

The internals list has not only recently "failed" miserably. That is not
to say that it has been like that since time immemoriable and should
therefore stay like that. On the contrary.

But we already have a group that has "the say" in PHP. The PHP Group is
mentioned in each and every source-file as they are the licence-holder.

Instead of adding another group I would rather see that existing group
to be filled with new life.

Whether that is the right group to tell people in the internals list off
is IMO questionable.

In essence to me the internals list is a group that discusses technical
topics regarding PHPs sources. The outcome and the vote whether
something will become part of the code is then voted on in an RFC. That
is a rather democratic process. When people are not able to convince the
majority of the voters that their idea is a good idea for the PHP
sources then it might not be a good idea. Having a group of people with
elevated privileges in that process is against that long lived and
established current process. And it looks like internals is not yet at
that point.

Having a group of people that make sure that the tone on the list is
civil, on-topic and inviting to newcomers is a different story. But that
was not what the vote was about.

So for me there already is an elevated group that has a bit more to say
regarding the PHP-sources as they are the once "owning" the licence.
Adding a second group with elevated privileges regarding code-decissions
will not help in keeping the mailinglist civilised and welcoming.

On a sidenote: I'd rather try to find a new solution for the PHP Group
as licence holder. So the idea of having an elected comitee that coupd
perhaps replace the PHP Group was tempting!

So my alternative would be for everyone to every now and then reread
https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md

And as a second step to make internals more welcoming and inclusive
might be to have people keep an eye on the tone that can intervene when
the debate gets too heated. Those IMO need to be respected people and
their influence is in those matters purely on keeping the tone civilized
and not have a veto right in regards to code. The internals list and in
the end the vote on an RFC should have the last say in regards to code.

My 0.02€

Cheers

Andreas

--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl                                                       |
| mailto:andreas@heigl.org                  N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org                                           |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas                               |
+---------------------------------------------------------------------+
| GPG-Key: https://hei.gl/keyandreasheiglorg                          |
+---------------------------------------------------------------------+

Larry Garfield

3 years ago

On Fri, May 12, 2023, at 3:12 PM, Andreas Heigl wrote:

>> For those who voted no, I would kindly ask: What is your alternative?
>>
>> We have an organizational/structural problem.  This isn't really debatable.  An eager new contributor was just bullied out of contributing, and the one process we have for dealing with it (RFCs) failed miserably to handle the situation.
>>
>> Ignoring the problem is a bad option.  If the TC proposal isn't your preferred way to address it, OK, what is?  "Do nothing, it's OK if people occasionally get bullied out of contributing" is not an answer.
>
> The internals list has not only recently "failed" miserably. That is not
> to say that it has been like that since time immemoriable and should
> therefore stay like that. On the contrary.
>
> But we already have a group that has "the say" in PHP. The PHP Group is
> mentioned in each and every source-file as they are the licence-holder.
>
> Instead of adding another group I would rather see that existing group
> to be filled with new life.

That's an interesting idea.  However, the PHP Group consists, AFAIK, of a half dozen people, none of whom are still active in PHP in any meaningful way.  Or maybe one.  Its legal status is... I don't even know, honestly.  Is it an actual registered organization?  Or is it just "we say we're the PHP Group so we are" (like most OSS groups)?

That said, I'm not sure if the legal side of PHP (which is important, no doubt) should be the same as the technical side of PHP.  Those are separate concerns.

> Whether that is the right group to tell people in the internals list off
> is IMO questionable.

Which is also not quite the topic at hand.  "People were mean" isn't the problem the TC proposal was trying to solve.  "There is no mechanism to resolve purely technical issues that doesn't involve people being mean" is the issue being addressed.  When there is a structure vacuum, it gets filled by the loudest and most brash voice that has the least regard for decorum.  That's just the nature of humans.  Rather than try to fix the loudest and most brash voice, the intent is to fix the structure vacuum.

> In essence to me the internals list is a group that discusses technical
> topics regarding PHPs sources. The outcome and the vote whether
> something will become part of the code is then voted on in an RFC. That
> is a rather democratic process. When people are not able to convince the
> majority of the voters that their idea is a good idea for the PHP
> sources then it might not be a good idea. Having a group of people with
> elevated privileges in that process is against that long lived and
> established current process. And it looks like internals is not yet at
> that point.

Again, not the topic at hand.  The TC proposal did not change the feature approval RFC process, at all.  It was very explicit about that.  It was about non-feature decisions that are highly technical.  Those simply do not make sense to apply casual direct democracy to.  To take the recent example, there's probably only about 10 people who have any meaningful input to give on "should this include statement be here or over here."  The other 990 or so RFC voters, quite honestly, do not have anything meaningful or useful to say, and most probably don't even understand the question.  And I include myself in that category.  On decisions like that, *please do not ask me, I have nothing useful to contribute*.

But the selection of those limited people to deal with matters that are, quite frankly, over the head of and below the radar of 99% of us, was proposed to be democratic.  It was basically the same process as Release Manager selection.

> So for me there already is an elevated group that has a bit more to say
> regarding the PHP-sources as they are the once "owning" the licence.
> Adding a second group with elevated privileges regarding code-decissions
> will not help in keeping the mailinglist civilised and welcoming.

Again, separate issues needing separate discussions.  (I'm not getting into the CoC topic right now. My skin isn't *that* thick.)  We're specifically talking about the "technical matters mediators", to avoid revert-fights like we just had.  Keep the topic narrow.

> On a sidenote: I'd rather try to find a new solution for the PHP Group
> as licence holder. So the idea of having an elected comitee that coupd
> perhaps replace the PHP Group was tempting!

The license holder needs to be a legal entity, so the TC isn't really that.  Whether the PHP Group should be redesigned to be a legal entity is a separate matter that bears discussion, but isn't the topic at hand.

--Larry Garfield

Andreas Heigl

3 years ago

Hey Larry, hey all

On 12.05.23 17:36, Larry Garfield wrote:

> On Fri, May 12, 2023, at 3:12 PM, Andreas Heigl wrote:
>

[...]

>
>> In essence to me the internals list is a group that discusses technical
>> topics regarding PHPs sources. The outcome and the vote whether
>> something will become part of the code is then voted on in an RFC. That
>> is a rather democratic process. When people are not able to convince the
>> majority of the voters that their idea is a good idea for the PHP
>> sources then it might not be a good idea. Having a group of people with
>> elevated privileges in that process is against that long lived and
>> established current process. And it looks like internals is not yet at
>> that point.
>
> Again, not the topic at hand.  The TC proposal did not change the feature approval RFC process, at all.  It was very explicit about that.  It was about non-feature decisions that are highly technical.  Those simply do not make sense to apply casual direct democracy to.  To take the recent example, there's probably only about 10 people who have any meaningful input to give on "should this include statement be here or over here."  The other 990 or so RFC voters, quite honestly, do not have anything meaningful or useful to say, and most probably don't even understand the question.  And I include myself in that category.  On decisions like that, *please do not ask me, I have nothing useful to contribute*.

In other projects I work on these purely technical decissions and
discussions are solved using CodeReviews (or Pair/MobProgramming).

That doesn't indeed require an RFC.

But in the specific case that we seem to try to solve here - at least
from what I have seen and read - I doubt that any CodeReview or entity
could have made that less messy.

So I'm still not convinced that we need a special group of people -
apart from the already special group of amazing people that are doing a
shitload of great stuff for the language.

And the rest is pretty already nicely described in the
CONTRIBUTING.md[1] file.

For example:

> Discuss any significant changes on the list before committing and get

confirmation from the release manager for the given branch.

or

> If you "strongly disagree" about something another person did, don't

start fighting publicly - take it up in private email.

So in essence we already have the group of people - and they are even
elected: The release-managers.

So no need to elect another body

My 0.02€

Cheers

Andreas

[1]
https://github.com/php/php-src/blob/master/CONTRIBUTING.md#git-commit-rules

--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl                                                       |
| mailto:andreas@heigl.org                  N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org                                           |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas                               |
+---------------------------------------------------------------------+
| GPG-Key: https://hei.gl/keyandreasheiglorg                          |
+---------------------------------------------------------------------+

Jakub Zelenka

3 years ago

>
>
> And the rest is pretty already nicely described in the
> CONTRIBUTING.md[1] file.
>
>

This is just a random document that has no weight in decision. Anyone can
change it without asking. Except the actual voting, then only voted in
proposal that was accepted is the one for the release process [1].

> For example:
>
>  > Discuss any significant changes on the list before committing and get
> confirmation from the release manager for the given branch.
>
> or
>
>  > If you "strongly disagree" about something another person did, don't
> start fighting publicly - take it up in private email.
>
> So in essence we already have the group of people - and they are even
> elected: The release-managers.
>
>

So it means that this is not exactly correct. Release manager can decide
only about bugs. Specifically see RMs role in [1]:

> But they are not:
>     Decide which features, extension or SAPI get in a release or not

[1] https://wiki.php.net/rfc/releaseprocess

Regards

Jakub

Arvids Godjuks

3 years ago

On Fri, 12 May 2023 at 18:12, Andreas Heigl <andreas@heigl.org> wrote:

> Hey Larry, Hey all
>
> On 12.05.23 16:42, Larry Garfield wrote:
> > On Fri, May 12, 2023, at 11:57 AM, Jakub Zelenka wrote:
> >> On Fri, Apr 28, 2023 at 11:00 AM Jakub Zelenka <bukka@php.net> wrote:
> >>
> >>> Hi,
> >>>
> >>> The vote is now open for the RFC about introduction of the PHP
> Technical
> >>> Committee:
> >>>
> >>> https://wiki.php.net/rfc/php_technical_committee
> >>>
> >>> Regards
> >>>
> >>>
> >> The voting ended with 10 yes votes and 21 no votes. It means that the
> RFC
> >> has been declined. Thanks for voting.
> >>
> >> Regards
> >>
> >> Jakub
> >
> > For those who voted no, I would kindly ask: What is your alternative?
> >
> > We have an organizational/structural problem.  This isn't really
> debatable.  An eager new contributor was just bullied out of contributing,
> and the one process we have for dealing with it (RFCs) failed miserably to
> handle the situation.
> >
> > Ignoring the problem is a bad option.  If the TC proposal isn't your
> preferred way to address it, OK, what is?  "Do nothing, it's OK if people
> occasionally get bullied out of contributing" is not an answer.
>
> The internals list has not only recently "failed" miserably. That is not
> to say that it has been like that since time immemoriable and should
> therefore stay like that. On the contrary.
>
> But we already have a group that has "the say" in PHP. The PHP Group is
> mentioned in each and every source-file as they are the licence-holder.
>
> Instead of adding another group I would rather see that existing group
> to be filled with new life.
>
> Whether that is the right group to tell people in the internals list off
> is IMO questionable.
>
> In essence to me the internals list is a group that discusses technical
> topics regarding PHPs sources. The outcome and the vote whether
> something will become part of the code is then voted on in an RFC. That
> is a rather democratic process. When people are not able to convince the
> majority of the voters that their idea is a good idea for the PHP
> sources then it might not be a good idea. Having a group of people with
> elevated privileges in that process is against that long lived and
> established current process. And it looks like internals is not yet at
> that point.
>
> Having a group of people that make sure that the tone on the list is
> civil, on-topic and inviting to newcomers is a different story. But that
> was not what the vote was about.
>
> So for me there already is an elevated group that has a bit more to say
> regarding the PHP-sources as they are the once "owning" the licence.
> Adding a second group with elevated privileges regarding code-decissions
> will not help in keeping the mailinglist civilised and welcoming.
>
> On a sidenote: I'd rather try to find a new solution for the PHP Group
> as licence holder. So the idea of having an elected comitee that coupd
> perhaps replace the PHP Group was tempting!
>
> So my alternative would be for everyone to every now and then reread
> https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md
>
> And as a second step to make internals more welcoming and inclusive
> might be to have people keep an eye on the tone that can intervene when
> the debate gets too heated. Those IMO need to be respected people and
> their influence is in those matters purely on keeping the tone civilized
> and not have a veto right in regards to code. The internals list and in
> the end the vote on an RFC should have the last say in regards to code.
>
> My 0.02€
>
> Cheers
>
> Andreas
>
> --
>                                                                ,,,
>                                                               (o o)
> +---------------------------------------------------------ooO-(_)-Ooo-+
> | Andreas Heigl                                                       |
> | mailto:andreas@heigl.org                  N 50°22'59.5" E 08°23'58" |
> | https://andreas.heigl.org                                           |
> +---------------------------------------------------------------------+
> | https://hei.gl/appointmentwithandreas                               |
> +---------------------------------------------------------------------+
> | GPG-Key: https://hei.gl/keyandreasheiglorg                          |
> +---------------------------------------------------------------------+
>

Hello Andreas!

I think what Larry is asking are ideas on actual solutions,  what steps
should be made and working out how those recent situations should have been
solved/handled. Really it does not matter if will it be PHP Group or some
called something else. There has been a lot of discussion off the list in
communities among PHP developers and nobody considers the recent events as
something that should have happened.

The time to "let's throw around some ideas" has passed. The current
situation highly reminds me of the year prior to the introduction of the
RFC process: this going down a hill at a rapid pace and a lot of people
yelling "la la la la" while plugging their ears.
The world has changed, and the new breed of developers has grown up in a
very different environment. I personally as a developer am a completely
different person and I do not accept what has been a norm 5-10 years ago
today. The development world moved on, it changed radically.
It's time to be the big boys and accept that what worked past 10-20 years
is not acceptable any more and the project has to adapt to the modern
times. I already wrote about how ridiculous the decision not to include
cleanup is. It's like a "birds against flying" campaign...


I've personally have been talking to a few people with core dev access
about figuring out a way to introduce some kind of communication and
coordination type people to the project, whose role is to filter out "the
noise", communicate with the community, put concisely feedback for the
technical people so they don't have to be forced to communicate when they
don't want to (and I see a lot of RFC's basically being ignored by a
majority of the voters then to suddenly speak up after the fact). And those
people could help mediate the process - making sure things just don't get
abandoned just because everybody flipped over their tables and stormed off.

In the modern day, people expect a very different style of communication.
And, sadly, those are the people who make decisions like "should we abandon
PHP and move to Go or JavaScript" and so on.
The other part that irks me a lot how php.net is developed - while it is
fine and it works, I have seen people lose all interest as soon as they
open the code. Nobody wants to touch it. And nobody wants to be responsible
for it too as far as I can tell.
The windows build machine.... I really don't have to explain anything here,
do I?

--

Arvīds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius

Andreas Heigl

3 years ago

Hey Arvids, Hey all

On 12.05.23 17:48, Arvids Godjuks wrote:

> On Fri, 12 May 2023 at 18:12, Andreas Heigl <andreas@heigl.org> wrote:
>
>> Hey Larry, Hey all
>>
>> On 12.05.23 16:42, Larry Garfield wrote:
>>> On Fri, May 12, 2023, at 11:57 AM, Jakub Zelenka wrote:
>>>> On Fri, Apr 28, 2023 at 11:00 AM Jakub Zelenka <bukka@php.net> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> The vote is now open for the RFC about introduction of the PHP
>> Technical
>>>>> Committee:
>>>>>
>>>>> https://wiki.php.net/rfc/php_technical_committee
>>>>>
>>>>> Regards
>>>>>
>>>>>
>>>> The voting ended with 10 yes votes and 21 no votes. It means that the
>> RFC
>>>> has been declined. Thanks for voting.
>>>>
>>>> Regards
>>>>
>>>> Jakub
>>>
>>> For those who voted no, I would kindly ask: What is your alternative?
>>>
>>> We have an organizational/structural problem.  This isn't really
>> debatable.  An eager new contributor was just bullied out of contributing,
>> and the one process we have for dealing with it (RFCs) failed miserably to
>> handle the situation.
>>>
>>> Ignoring the problem is a bad option.  If the TC proposal isn't your
>> preferred way to address it, OK, what is?  "Do nothing, it's OK if people
>> occasionally get bullied out of contributing" is not an answer.
>>
>> The internals list has not only recently "failed" miserably. That is not
>> to say that it has been like that since time immemoriable and should
>> therefore stay like that. On the contrary.
>>
>> But we already have a group that has "the say" in PHP. The PHP Group is
>> mentioned in each and every source-file as they are the licence-holder.
>>
>> Instead of adding another group I would rather see that existing group
>> to be filled with new life.
>>
>> Whether that is the right group to tell people in the internals list off
>> is IMO questionable.
>>
>> In essence to me the internals list is a group that discusses technical
>> topics regarding PHPs sources. The outcome and the vote whether
>> something will become part of the code is then voted on in an RFC. That
>> is a rather democratic process. When people are not able to convince the
>> majority of the voters that their idea is a good idea for the PHP
>> sources then it might not be a good idea. Having a group of people with
>> elevated privileges in that process is against that long lived and
>> established current process. And it looks like internals is not yet at
>> that point.
>>
>> Having a group of people that make sure that the tone on the list is
>> civil, on-topic and inviting to newcomers is a different story. But that
>> was not what the vote was about.
>>
>> So for me there already is an elevated group that has a bit more to say
>> regarding the PHP-sources as they are the once "owning" the licence.
>> Adding a second group with elevated privileges regarding code-decissions
>> will not help in keeping the mailinglist civilised and welcoming.
>>
>> On a sidenote: I'd rather try to find a new solution for the PHP Group
>> as licence holder. So the idea of having an elected comitee that coupd
>> perhaps replace the PHP Group was tempting!
>>
>> So my alternative would be for everyone to every now and then reread
>> https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md
>>
>> And as a second step to make internals more welcoming and inclusive
>> might be to have people keep an eye on the tone that can intervene when
>> the debate gets too heated. Those IMO need to be respected people and
>> their influence is in those matters purely on keeping the tone civilized
>> and not have a veto right in regards to code. The internals list and in
>> the end the vote on an RFC should have the last say in regards to code.
>>
>> My 0.02€
>>
>> Cheers
>>
>> Andreas
>>
>> --
>>                                                                 ,,,
>>                                                                (o o)
>> +---------------------------------------------------------ooO-(_)-Ooo-+
>> | Andreas Heigl                                                       |
>> | mailto:andreas@heigl.org                  N 50°22'59.5" E 08°23'58" |
>> | https://andreas.heigl.org                                           |
>> +---------------------------------------------------------------------+
>> | https://hei.gl/appointmentwithandreas                               |
>> +---------------------------------------------------------------------+
>> | GPG-Key: https://hei.gl/keyandreasheiglorg                          |
>> +---------------------------------------------------------------------+
>>
>
> Hello Andreas!
>
> I think what Larry is asking are ideas on actual solutions,  what steps
> should be made and working out how those recent situations should have been
> solved/handled. Really it does not matter if will it be PHP Group or some
> called something else. There has been a lot of discussion off the list in
> communities among PHP developers and nobody considers the recent events as
> something that should have happened.
>
> The time to "let's throw around some ideas" has passed. The current
> situation highly reminds me of the year prior to the introduction of the
> RFC process: this going down a hill at a rapid pace and a lot of people
> yelling "la la la la" while plugging their ears.
> The world has changed, and the new breed of developers has grown up in a
> very different environment. I personally as a developer am a completely
> different person and I do not accept what has been a norm 5-10 years ago
> today. The development world moved on, it changed radically.
> It's time to be the big boys and accept that what worked past 10-20 years
> is not acceptable any more and the project has to adapt to the modern
> times. I already wrote about how ridiculous the decision not to include
> cleanup is. It's like a "birds against flying" campaign...
>
>
> I've personally have been talking to a few people with core dev access
> about figuring out a way to introduce some kind of communication and
> coordination type people to the project, whose role is to filter out "the
> noise", communicate with the community, put concisely feedback for the
> technical people so they don't have to be forced to communicate when they
> don't want to (and I see a lot of RFC's basically being ignored by a
> majority of the voters then to suddenly speak up after the fact). And those
> people could help mediate the process - making sure things just don't get
> abandoned just because everybody flipped over their tables and stormed off.
>
> In the modern day, people expect a very different style of communication.
> And, sadly, those are the people who make decisions like "should we abandon
> PHP and move to Go or JavaScript" and so on.
> The other part that irks me a lot how php.net is developed - while it is
> fine and it works, I have seen people lose all interest as soon as they
> open the code. Nobody wants to touch it. And nobody wants to be responsible
> for it too as far as I can tell.
> The windows build machine.... I really don't have to explain anything here,
> do I?
>

Larry asked what alternatives those who voted "No" see.

My main topic that I seem not to have been able to get across is that to
me there is no need to implement alternatives as everything is already
there.

* We have rules for the list.
* We have a workflow that should prohibit stuff getting into the core
from new developers without at least a second set of eyes and in case of
strong disagreement a separate discussion
* We have an elected group of people that has the say about the part of
the source that they are responsible for

That is my personal opinion and the reason why I did vote the way I voted.

This is not "throwing around some ideas".

If you want to know what my next steps would be (now we are throwing
around ideas): Hire someone that makes sure that we are actually
observing the rules that are already there?

Which brings us to another point that you mentioned: PHP is solely based
on voluntary development. Some core-devs are paid by the community via
the PHPFoundation. But in essence that is still based on voluntary work.
People volunteer to do stuff and get paid for that.

That is a bit like Python but definitely different to languages like
Java, C or even JavaScript.

So getting a stronger organizational background for PHP along with a
more structured approach to infrastructure is definitely a good idea.
But that is not the question that was asked by Larry.

Cheers

Andreas

--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl                                                       |
| mailto:andreas@heigl.org                  N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org                                           |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas                               |
+---------------------------------------------------------------------+
| GPG-Key: https://hei.gl/keyandreasheiglorg                          |
+---------------------------------------------------------------------+

Larry Garfield

3 years ago

On Fri, May 12, 2023, at 4:10 PM, Andreas Heigl wrote:

> Hey Arvids, Hey all

>> In the modern day, people expect a very different style of communication.
>> And, sadly, those are the people who make decisions like "should we abandon
>> PHP and move to Go or JavaScript" and so on.
>> The other part that irks me a lot how php.net is developed - while it is
>> fine and it works, I have seen people lose all interest as soon as they
>> open the code. Nobody wants to touch it. And nobody wants to be responsible
>> for it too as far as I can tell.
>> The windows build machine.... I really don't have to explain anything here,
>> do I?
>>
> Larry asked what alternatives those who voted "No" see.
>
> My main topic that I seem not to have been able to get across is that to
> me there is no need to implement alternatives as everything is already
> there.
>
> * We have rules for the list.
> * We have a workflow that should prohibit stuff getting into the core
> from new developers without at least a second set of eyes and in case of
> strong disagreement a separate discussion
> * We have an elected group of people that has the say about the part of
> the source that they are responsible for

So you're basically arguing that it's an "implementation problem", not a rule problem.  I cannot agree.

Primarily because this

> * We have a workflow that should prohibit stuff getting into the core
> from new developers without at least a second set of eyes and in case of
> strong disagreement a separate discussion

isnt' true.  We have a workflow for new functionality that warrants an RFC.  "What should the process be to re-optimize the way C includes work" is not something the RFC process is in any way suited for.  That sort of decision *needs* to have a clear voice on it, from some small, mostly agreeable set of voices.  (Which, again, does not include mine.  That's the point.)

That is a process gap right now, and it leads to other problems.

Expanding the role of the Release Managers to include that responsibility is one possibility.  I would be open to that, if others (including the RMs) are.  However, for that to work, we'd need to elect RMs much sooner, say, October/November range so that they're ready to "take over leadership of HEAD" as soon as the branch is open for development.  Maybe sooner.

This is an approach I'm open to exploring, but as noted, would be  a scope change and rule change for the RMs.

--Larry Garfield