Experimenting with Issue-First Open Source Contributions

Why Try This?

For years, contributing to an Open Source project has often meant opening a pull request.

Then coding agents arrived.

I have built Symfony Language Tools with coding agents from the beginning. Working this way changed what I value most in a contribution. The implementation is important, but an agent can often produce it quickly. Understanding the problem is harder.

Only you know the exact application where something failed. You know the editor, the Symfony version, the configuration, the container setup, the source file you were editing and the action that triggered the problem. For a feature, you know the workflow you are trying to improve and why the current behavior gets in the way.

That context is precious. It gives the maintainer and the coding agent the data they need to steer the implementation in the right direction.

Reviewing a pull request also takes more than reading a diff. I need to understand the intent, check that the change fits the architecture, verify the tests and consider compatibility, privacy and performance. For this young project, starting again from a good issue can be faster than reviewing and reshaping an external patch.

Issues Are Contributions

Contributions remain open, and they are very welcome. For Symfony Language Tools, they now start with an issue.

There is no mandatory template. A minimal reproducer is wonderful when it is practical, but creating one for an editor integration can be difficult. A report with the actual workspace configuration, relevant logs, screenshots and a description of what happened can be more useful.

The same applies to feature requests. A proposed API or design can help, but the real use case matters more. Describe the problem in whatever form feels natural. Let the information from your project guide the report.

Bring Your Agent

Issues prepared with an agent are welcome. As a matter of fact, they can be excellent.

Point your agent to the contribution guide and ask it to help. If it can read the affected project, it can inspect Composer metadata, editor settings, source files and logs. It can identify package versions, explain the exact failing context and create a reproduction when that makes sense.

On my side, the agent does not start from a clean checkout. It knows much more than what is recorded in the public repository. Local memory records past decisions, failed experiments, benchmark results and project constraints. Internal tooling runs the server against all private Symfony applications powering symfony.com and the *.symfony.com websites. It boots each application, builds its indexes and exercises completion, navigation, diagnostics and other LSP features.

The context from the reporter completes that knowledge. It gives the agent a much better starting point for implementing and validating the right change.

Review the result before publishing it. Agent-generated analysis is useful when it describes something you actually observed. Mass-generated speculative issues are not.

What Happens Next?

Maintainers will triage each issue and ask for more context when needed. When an issue is selected, it becomes the brief for the implementation. Coding agents can then write the code, tests and documentation.

A maintainer still reviews and validates every change. Agents do not decide the scope of the project, and they do not get the final word.

Not every issue will be implemented. Some will be duplicates, some will be outside the project's scope and some will reveal that the current behavior is intentional. That part of Open Source maintenance does not change.

Why Only Symfony Language Tools?

Symfony Language Tools is a good place for this experiment. It is a young project, still in beta, and coding agents have written most of its code under my direction. The development workflow is already built around them.

The main Symfony repository is different. It has a mature contribution model, a large community and established review and release processes. Pull requests are an essential part of that community. I am not proposing to change that.

Learning in Public

I will look at the quality of the issues, the time needed to turn them into fixes and the experience for people reporting real problems. I also want to see what gets lost when contributors cannot submit a pull request.

If the model works, I will keep it or adapt it. If it does not, I will reopen pull requests. There is no ideology here, only a workflow worth trying.

Open Source contribution workflows have changed before. Email patches gave way to pull requests. Perhaps issues combined with coding agents can become another useful option for some projects.