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.morri...@datadoghq.com> wrote: > On Fri, Apr 28, 2023 at 4:01 AM Jakub Zelenka <bu...@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
