On Monday, 26 February 2024 at 11:53, Daniil Gentili <dan...@daniil.it> wrote:
> > IMO sending an email is not a gigantic barrier to entry, as can be seen by > the often low (technical and overall) quality of the replies to many of the > threads on this list. Yet people complain about it being a barrier to entry, and a barrier to contributing to the project. > I really don't think that a modern discussion system can afford to randomly > loose messages: mailing lists should not be used in 2024. This is a take and a half, a lot of self-hosted modern discussion system still require an email server and list. Moreover, internals is far from the only mailing list that contributors/core devs rely on. > Large projects like PHP will still inevitably attract attention, regardless > of whether github or mailing lists are used; I personally dislike mailing > lists not because they are difficult to use, but because they are simply > broken: every time I had to deal with any mailing list, including this one, I > had both incoming and outgoing deliverability issues related either to > DKIM/DMARC, or some other issue caused by modern anti-spam measures that > mailing lists do not account for. I'm sorry this has been your experience, but I never really had any issues with mailing lists, and they have always just worked TM Part of the issue is that we were forced to migrate the mailing list on short notice. And I do agree that certain things the list does about DKIM/DMARC is less than optimal. However, demanding to change the workflow of core developers for _your_ convenience is, not a good way of moving change forward. I find it akin to being a new hire at a large, established company and storming into a meeting of the board of directors within your first week of working to demand change because the way it is currently being operated is "shit". I can let you imagine the fallout of such an action if attempted in real life. Yes, the list is far from ideal, but it is an established process that has somewhat worked and people have integrated this into their workflow. Are there better options? Sure. But shouting "just use GitHub discussion", or whatever $myPreferedPlatformOrMethod is not conducive to change. For us to move away from the internals list you *must* have core developer endorsement for the new solution. And, with people I have talked to, me included, find GitHub discussions to be ill-suited. It probably works perfectly for a library, tooling, or projects built with PHP and I'm happy for projects where it is a good fit. What is the purpose of the list, and internals? I'm not exactly sure, as it seems to have morphed and shifted over the course of its existence. Is the objective is to have core developers interact on it willingly by having technical discussion which might go over most people head? Is the objective just for people to be able spit ball ideas as an initial stage on a wide-reaching platform with minimal interaction from core developers? Is the objective to just propose, announce, and discuss RFCs and vote on them? etc. Probably each of these objectives require different solutions, and this would probably be a more useful conversation to have. Best regards, Gina P. Banyard
