Contribution policy update: open an issue first, PRs by assignment only

[ZhiyuCircle]

We're making a change to how contributions to arc-node work. Starting now, every pull request must reference an issue that you have been assigned to. Pull requests that don't meet this requirement will be closed automatically.

Why

For us, the issue is ultimately more valuable than the submitted code. It captures the problem, expected behavior, impact, and acceptance criteria independently of any particular implementation.

This is especially relevant for upstream pull requests such as PR #361. By the time we review an upstream PR, its implementation may be outdated, conflict with changes in our private repository, or no longer match our preferred approach. In many cases, it would be easier for us to take a well-defined issue (e.g. #360) and use our internal tooling—including AI-assisted development—to implement and test the fix directly against the current private codebase.

What this means

• Every PR must reference an existing issue.
• The issue should be reviewed and accepted before implementation starts.
• External contributors should begin by reporting the problem or proposing the change as an issue.
• An accepted issue does not guarantee that a contributor's implementation will be merged; maintainers may implement it internally.
• Small documentation fixes and urgent production fixes may be exempt.

This would help us:

• Preserve the problem statement even when an implementation becomes stale.
• Prioritize work before contributors invest time in code.
• Reduce the effort required to review and update outdated upstream PRs.
• Implement fixes against the latest private repository state.
• Set clearer expectations for contributors.

Where this is written down

The full policy lives in CONTRIBUTING.md.

To everyone who has filed issues and PRs over the past few weeks: thank you. Several of your reports surfaced genuine bugs and are being fixed. This change is about making that effort count, not about shutting the door.

Questions about the policy are welcome in the comments below.

[antosec00]

Thanks for clarifying the new issue-first contribution policy.

I have one related question about the private reporting process for security vulnerabilities.

The new policy says that external contributors should begin by opening an issue. However, arc-node's SECURITY.md explicitly says not to file public GitHub issues for security vulnerabilities and instead directs researchers to Circle's HackerOne Bug Bounty Program.

At the moment, however, circlefin/arc-node no longer appears as a selectable asset in the Circle BBP submission form or in its current structured scope.

Could you please clarify the intended private reporting route for security vulnerabilities affecting arc-node?

Specifically:

• Are security vulnerabilities exempt from the public issue-first and assignment requirements?
• Should researchers now use GitHub's private “Report a vulnerability” flow?
• Is there another HackerOne asset or private Circle channel intended for arc-node security reports?
• Will reports submitted through that alternative route still be reviewed by the appropriate security team?

It would be helpful to update SECURITY.md and CONTRIBUTING.md with the current private route, so researchers do not accidentally disclose security issues publicly or submit them under an unrelated asset.

I am asking only for process clarification, thanks.