PR (Taylor)

[pari-sadegh-80]

Why does @taylorotwell not give any answer after closing the PR?

[Sophist-UK]

Too many PRs, not enough time in the day. You may disagree with this approach (many do) and maybe even disagree whether this is best for Laravel, but he is the BDfL and - so long as he acts consistently which he does, and so long as his reasons are rational which they are - that is his prerogative.

As far as I can tell from those PRs I have looked at, the general reasons for PRs not being merged are:

a. The change is not core to Laravel;
b. The change will increase the size of the code base that the core team needs to support but doesn't do enough to justify it;
c. The change is not consistent in approach with existing ways that Laravel does things;
d. The change will be a breaking change;
e. There are not enough tests or documentation.

Many PRs end up being delivered by an add-on package instead - and PHP/Laravel's architecture (e.g. OO, macroable) allows this to be possible.

The bad news is that this does lead to a fragmented marketplace for add-on packages, and a difficulty in finding suitable packages, evaluating their pros and cons, guessing about whether the package will be maintained for the lifetime of your development etc. Like most marketplaces, this ends up being time-consuming and hit and miss, but IMO (and apparently in the opinion of Taylor) this is better than accepting non-core PRs into the core codebase in order to try to be everything-to-everyone.

[parallels999]

Too many PRs, not enough time in the day.

This is mostly correct, if you are not a regular contributor they don't waste valuable time reviewing, most of the issues and PRs are wrong for not reading the documentation, unfortunately some valid PRs are lost for this reason

[Sophist-UK]

Yes - but you have to look at this from a distance - overall I believe this is the best approach despite having had my own PRs dismissed.