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 <m...@pmmaga.net> wrote: > On Fri, Apr 28, 2023 at 11:00 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 >> > > 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
