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