Key details

  1. Taylor Otwell says GitHub Issues were disabled on most Laravel open-source package repositories in early September 2026.
  2. Users encountering bugs are asked to use a coding agent and open a pull request.
  3. Otwell says an imperfect initial PR is acceptable as a starting point for maintainers.
  4. The main `laravel/framework` repository still keeps Issues enabled.
  5. The policy applies to package repositories such as Socialite rather than every Laravel repository.
  6. The change is a maintainer workflow decision, not a GitHub platform requirement.

What builders should take away

  1. If you maintain small open-source packages, test whether patch-first intake actually reduces triage time before removing a familiar support channel.
  2. Require tests and clear reproduction notes even when contributors use coding agents; a generated diff is not evidence the root cause is understood.
  3. Provide a path for security reports and bugs from users who cannot safely generate a patch.
  4. Measure whether closing Issues changes contributor participation, duplicate reports and maintainer workload rather than assuming agent-assisted intake is automatically better.

What changed

Laravel creator Taylor Otwell said on September 4, 2026 that he disabled GitHub Issues on most Laravel open-source package repositories. When users hit a bug, his requested workflow is to describe it to a coding agent and open a pull request instead of first filing an Issue. Otwell explicitly says an imperfect first patch is acceptable because the pull request can document the failure and give maintainers code to review. He later clarified that the central `laravel/framework` repository still has Issues enabled; examples such as Socialite are among the package repositories using the new approach.

Why it matters

Coding agents are changing more than how code is written: they can alter what maintainers expect from bug reporters. Asking for a patch first can reduce reproduction and triage work for a small maintainer team and turn a bug report into something directly testable. It can also raise the contribution barrier for users who cannot produce a safe patch, and AI-generated changes still require maintainer review. The significant development is the contribution-policy experiment itself, not a claim that issue trackers are obsolete.

The change applies to most packages, not the main framework repository

Otwell clarified that `laravel/framework` still keeps GitHub Issues enabled. The new policy targets package repositories where he says issue volume was relatively low, including examples such as Socialite.

A pull request becomes the bug report

Users are being encouraged to give a coding agent the failure context and open a PR with the attempted fix. Even when the code is incomplete, the diff, tests and PR discussion can give maintainers a more concrete starting point than a prose-only report.

Agent output does not remove maintainer review

The workflow shifts effort toward contributors and coding agents but does not establish that generated patches are trustworthy. Maintainers still need reproduction, tests, security review and architectural judgment before accepting a change.

The broader claim is still an opinion

Otwell has suggested this contribution pattern may become more common as coding agents improve. BTN treats that as his forecast, not evidence that other major open-source projects are following the same policy.

What to watch next

  • Whether Laravel keeps the policy after enough real package bugs pass through it.
  • Whether issue volume moves to discussions, social channels or low-quality pull requests instead of disappearing.
  • Other open-source maintainers adopting or rejecting patch-first agent workflows.
  • New GitHub or coding-agent tooling that turns reproduction reports into governed PR workflows without removing issue intake.

Still unclear

  • There is not yet enough public data to know whether the policy reduces total maintainer workload.
  • Otwell's statements describe Laravel's chosen workflow; they do not establish a general open-source trend.
  • Repository-level settings may change as maintainers learn from the experiment.

Sources

Direct reading behind this dossier.

2 sources

Discussion

Discussion is reader-contributed. Comments are not part of the BTN dossier or its editorial evidence.

0 visible comments

Join the discussion

Keep comments useful and relevant. Reader contributions may be moderated and are not BTN editorial evidence.

Sign in to comment