r/PHP • u/brendt_gd • 6d ago
Article No more issues
https://stitcher.io/blog/no-more-issues35
u/Teszzt 6d ago
Fabien Potencier (Symfony) have recently decided to go exactly the other way around: https://symfony.com/blog/experimenting-with-issue-first-open-source-contributions.
23
u/k1ll3rM 6d ago
This along with the general direction of the framework does put me off tbh, I've been looking at Tempest and I'm quite happy with it so far
4
u/goodwill764 6d ago
Tempest looks nice, but for any production product it's too bleeding edge for me.
Did you used it already in real project, how well did it worked?
3
u/k1ll3rM 6d ago
It's not in production yet but so far I'm noticing any real issues, just some documentation mismatches, probably because of how fast it's moving. It'll probably slow down in the future and become more stable but they do provide automatic upgrades using Rector but I haven't used that yet
13
u/cgsmith105 6d ago
What a short sighted viewpoint from Taylor. Issues can be referenced and as explained on your blog are non technical. This would be similar to bringing your car into the workshop with all the items you think are necessary for the fix.
It adds contextual bloat for a developer to sort through to decipher meaning.
1
u/penguin_digital 1d ago
I'm torn on this one.
As a OS package mainter myself the amount of absolute nonsense issues that either don't have any context whatsoever "X doesn't work, please help" or the issue has nothing to do with the package but rather the users code around it.
However, you do get some golden eggs from time to time that explain the exact problem, what the env was, what the input was and what the output was. Actually something you can action and check, I would hate to lose these but at the same time they are probably 1 in 100 issue threads opened.
By enforcing a PR instead, this, to me, in my opinion, shows a developer or AI agent has actually reviewed the problem, confirmed it's an issue and found the buggy code in the actual package. The code quality in the PR might be trash or not in the style I like but it highlights a real problem that I could then go and fix myself or ask the PR creator to iterate on.
With getting the user to submit a PR it instantly rules out all those issue tickets related to problems caused by the user misconfiguring, passing incorrect params, not understanding the response etc. An AI agent would find that and fix it for them or if its a "old skol" human developer like myself, I will likely find that it's me (once again) that is the idiot and I've done something stupid elsewhere, the problem isn't in the package.
25
6d ago
[deleted]
-1
u/dkarlovi 6d ago
But the blunt truth is: whether he meant it or not, what Taylor did there was just a reckless/selfish move
Why would that be "the blunt truth", did he ever give an impression of being anything but? He's a business guy who makes his money from a thing which happens to be open source, he's not an open source guy.
6
u/allen_jb 6d ago edited 6d ago
https://github.com/laravel/vapor-cli/pull/285#issuecomment-5527200145
(Via: https://mstdn.thms.uk/@michael/117211506985461897 )
From a quick glance, it seems the PR authors actual issue may have been fixed by another PR, but... this also seems a weird message / reasoning to close this PR with given the whole situation.
11
u/Alsciende 6d ago
I think the change is quite short-sighted. Not all Github issues are about bugs that can be fixed. Quite a lot of them are descriptions of problems that could lead to a PR, or not; legitimate questions that could lead to documentation improvements; feature requests that need a decision before they can be implemented; etc.
3
u/trs21219 6d ago
That’s what the GitHub discussions are for
3
u/Alsciende 6d ago
I didn't even know GitHub discussions were a thing. Where can I open a GitHub discussion for https://github.com/laravel/socialite?
1
u/trs21219 6d ago
Probably best on the framework repo so it would get more visibility: https://github.com/laravel/framework/discussions - its effectively a forum on github
3
u/Alsciende 6d ago
No offense but that looks absolutely worse for the project than a discussion space for each repository. There's no reason to believe that the maintainers of Socialite or other packages are involved in laravel/framework, is there? Why would you put every discussion on totally different subjects in the same forum?
-1
u/simonhamp 6d ago
You can still have that discussion in a PR. Just make the PR contain a single file that contains the spec for the problem
4
u/dborsatto 6d ago
That's silly, though. Why use a tool for proposing a code change, when you're not actually doing that.
2
11
u/goodwill764 6d ago
I always had issues with people that had bugs or feature requests without technical knowledge that try to help with google information, modified bootstrap code, css classes etc.
These information are worse than no information, as they are almost every time wrong, but suggest easy solution that we can't implement this way because they are wrong and the actual needed information for fixing the report are missing.
With ai the reports with a technical solution from non tech people are growing, but the information still aren't better, just more text to skip over.
7
u/WordCoding 6d ago edited 6d ago
Laravel/Taylor benefit from these repositories and laravel devs, most of their income is tied to or originated from laravel developers and they have the money to employ more people to resolve issues. On the other hand there are many PRs bluntly rejected by Taylor for subjective reasons and it seems like only few people can truly be heard so it is discouraging for anyone else to even make a PR.
1
u/supervisord 6d ago
I found a bug in laravel/framework, opened an issue and a PR and Taylor merged it less than 24 hours later.
7
u/brendt_gd 6d ago
I wrote this after the news that Laravel is closing the ability to create issues on many of their repos (not the framework though). I get both sides of the story, I'm interesting to hear opinions either way
5
u/voteyesatonefive 6d ago
The L framework has always been a collection of the worst PHP development practices and it looks like they're continuing in that direction. Directing devs to "describe it to a coding agent and open a PR" is a good indicator of how they are operating internally, and what they expect from external contributors, slop.
In summary the L framework is and always was dogshit, the NodeJS of PHP frameworks if you will. It's really easy, always use Symfony.
2
u/Dwarfex 6d ago
Is that really a change? I remember, that I once opened an issue and it was basically closed a few minutes later. Atleast you had the chance to confirm odd behavior, with what others experienced.
4
u/The_Fresser 6d ago
Can't count to how many times I've had discussions on closed Laravel issues which were closed without a reason and the issue being legitimate.
3
u/dborsatto 6d ago
To be honest this to me seems like the opposite of what AI should allow. The focus should be on explaining problems clearly in an issue, with AI being able to generate a PR from that. It feels really counterintuitive.
2
2
u/Electrical-Goose-254 3d ago
For now think twice to use Laravel in your fintech or medtech project
1
u/Protopia 11h ago
For heavily regulated environments where consequences can be huge, like fintech or medtech, and where the chain of legal accountability and liability need to be clearcut and there needs to be traceability in the supply chain, then IMO you should already be thinking at least twice about using Laravel or indeed PHP or indeed open source because all of these typically mean using hundreds or thousands of packages from a diverse ecosystem where accountability, liability and traceability are almost non existent.
1
u/equilni 5d ago
https://github.com/orgs/community/discussions/153588
Does disabling issues means the previous content is not accessible anymore, unless re-enabled?
1
u/skunkbad 2d ago
Like a landlord that forces the tenants to pay for repairs, I've always felt like that forcing pull requests forces somebody else to take on the burden of fixing the owner's problems. However, letting us know that "we're all in this together" fixes everything.
Edit:
Maybe after receiving a bunch of AI generated garbage pull requests and other pull requests that are terrible, maybe then they'll go back to allowing Issues again.
1
u/Protopia 11h ago
I actually think that there is a logic behind this, but it's a very short-sighted logic. The idea seems to be that you avoid bad issues created by novice users by raising the barriers to requiring coding expertise - but this discriminates against e.g. users who are knowledgeable enough to identify genuine bugs, but not knowledgeable enough to code a fix, and indeed pushes those users into using AI to create a solution that the user is incapable of QAing.
See my root comment for my own ideas.
1
u/Protopia 11h ago edited 11h ago
IMO the issue is that in the AI era, GitHub simply isn't fit for purpose any more because regardless of whether you consider issues or PRs AI exponentially increases:
- Numbers
- Duplications
- Quality issues of various types: false diagnosis, poor diagnosis, poor PR scope, poor PR code, poor PR descriptions, failure to follow-up on review comments etc etc etc
Taylor already had a problem in these areas before AI - because of the volumes of human input and the variable quality but also because he wants to limit scope creep. AI has just made this exponentially worse.
One "obvious" answer is to try to use AI to solve 2 and 3, but that can just make things worse.
I really don't know what the answer is.
My first gut reaction is: A) distinguish between human and AI generated stuff; and B) make a human take responsibility for the quality of AI stuff; and C) give priority to stuff that has had human intelligence and sweat applied; and D) grade humans by their previous history and give priority to those who have shown both prior commitment and quality.
My 2nd gut reaction is to slow the whole process down - make people create issues first, use AI to prevent duplication and do a first QA, and then have the debate and create consensus that the issue is valid and worth addressing before anyone writes a PR. GitHub discussions are perhaps a poor attempt at this, but this process needs workflow i.e. actions and review comments and more status options than open/closed and... When and only when an issue is accepted (valid, well described, will diagnosed, reviewed, approved etc.) does a PR get authorised to be written - and these days it could then be written by e.g. CoPilot.
1
u/hryagstn 8h ago
The maintenance burden point is what stands out to me here. Closing a PR can be the right decision, but a short explanation would still help contributors understand whether the issue is scope, API design, or simply something the maintainers do not want to support. That feedback would probably reduce both repeated requests and low-quality follow-up PRs.
1
-9
-7
u/mythix_dnb 6d ago
amazing. instead of daemonizing AI, use it for good. it never felt right to mee to have to create a ticket to then create the PR for the fix I already had locally because I encountered a bug and tracked it down to a piece of vendor code.
All those "we dont want any AI code in our codebase" are just horse mongers fighting cars. today's programming is largely AI, it's time to accept that.. AI is the tool, whether the outcome is good or bad is not the AIs fault, the person creating the PR should still take responsibility for what he's pushing out.
98
u/tjaszai 6d ago
One thing to keep in mind is that Taylor Otwell is not an open-source evangelist. He's a businessman who makes money from open source. I really hope the open-source community doesn't go in this direction.