Hi Joe, > We have a spam problem on bugsnet
I would snarkily say "maybe accept the PRs from people wanting to work on it?", but I realise that ignores the underlying problem, that PHP lacks people. And particularly lacks people who can dedicate time to understanding, reviewing and saying no to things. Even if the plan is to move to a different platform, I'd like to take the time to document what is lacking about bugs.php.net currently. Please can someone turn on issues for php/web-bugs? My two concerns with moving to using other systems would be: * it'd be really useful to be able to authenticate php.net account holders on other systems, rather than having to set everyone's permissions up on each system by hand. I believe Saif may have been thinking about this a bit. * the low barrier to 'chipping in' through github issues and PRs have not been a joyous occasion for me. There is a really high proportion of "non-productive" contributions e.g. people 'approving PRs' for libraries they are not involved with, or flaming other users. Although moving to github issues will solve some annoying problems, that might be balanced by a larger number of slightly less annoying problems. But sure, the current situation is rubbish and moving issue tracking to github seems at least worth trying. Rowan Tommins wrote: > In terms of "SaaS vs custom code", it's notable that all three run > custom bots to add functionality not offered by Github, Yeah, unfortunately Github has focused more on making the barrier to using Github low, rather than making it easy to implement access control for non-enterprise customers. > It might just be an illusion, but it feels like all three projects have > a lot more resources to spend on all this than PHP does; I know for various reasons PHP doesn't have a foundation behind it, but if there was one, it's the boring stuff that a foundation should be looking at doing: * maintaining and improving infrastructure. * writing documentation and helping people learn PHP internals. * gathering feedback and summarising it. * maintaining a list of items that could be worked on. None of those things are a good fit for being maintained long-term on an ad-hoc basis. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
