Open pkgs to external contributions: CLA rollout

[bryan-minimal]

Summary

pkgs is opening to external contributions. Before we can accept pull requests from outside contributors, the Contributor License Agreement (CLA) machinery and contributor-facing documentation need to be in place. This issue tracks that rollout.

Background

Accepting work from outside contributors raises a question separate from the project's outbound license: on what terms has the contributor granted the right to include, distribute, and maintain their work. A CLA answers that once, up front, for every contributor — the standard instrument used by many large open-source projects. We use CLA Assistant for click-through Individual CLA signing, with a Corporate CLA available for contributions made on behalf of an employer.

Tasks

The steps below are in rough execution order — the CLA documents must be committed before CLA Assistant can be pointed at them.

Repository documentation

• Add CONTRIBUTING.md to the repo root; replace the [PROJECT NAME] placeholder with the repository's display name.
• Add legal/ICLA.md (Individual CLA) and legal/CCLA.md (Corporate CLA). Paths matter — CONTRIBUTING.md links to ./legal/ICLA.md and ./legal/CCLA.md.
• Update README.md to state that contributions are open, and to mention opening an issue as an alternative way to request a package.

CLA Assistant

• Sign in to cla-assistant.io with a GitHub account that has admin access to the organization/repository. Grant the OAuth permissions it requests — it needs write access to post status checks and comment on pull requests.
• Create a CLA configuration for this repository, pointing it at the raw URL of legal/ICLA.md on main (e.g. https://raw.githubusercontent.com/gominimal/pkgs/main/legal/ICLA.md). This makes the in-repo document the single source of truth. Note: CLA Assistant detects changes to the text and requires contributors to re-sign on their next PR — treat the file as versioned, don't edit it in place once live.
• Configure the signature custom fields (full name, email, etc.).
• Allowlist automation accounts (dependabot[bot], etc.) so the gate doesn't block them.
• Run it once against a test PR and note the exact name of the status check CLA Assistant posts — that string is what the merge-gate task needs.

Merge gate

• Add the CLA Assistant status check (the exact context name captured above) as a required status check, so a pull request cannot merge until every committer on it has signed the CLA. Already-signed contributors and allowlisted accounts pass automatically.

Validation

• Open a test pull request from a personal (non-organization) GitHub account; confirm the CLA gate triggers, the signing flow completes, and the check clears.

Coordination

Two ordering facts shape this:

1. The CLA text must be committed before CLA Assistant can read it — legal/ICLA.md has to be on main before the CLA Assistant configuration step.
2. CLA Assistant goes live the moment it's configured — there is no staged or dry-run mode; it begins commenting on open pull requests and posting checks immediately.

So the contributor-facing change should land as one coordinated step: documents merged, README updated, then CLA Assistant configured. A half-rolled-out state — docs inviting contributions with no CLA gate, or a gate active with no CONTRIBUTING.md to explain it — is confusing for contributors.

[bryan-minimal]

First merges in from an external contributor! 8cc4045 133db0c