Enforce issue-first contribution workflow

[nabinchha]

What

• add a CONTRIBUTING.md with an issue-first workflow for external contributors
• define the triaged label as the signal that an issue is reviewed, approved, and ready to be worked on
• link the contribution guide from the README
• require a linked triaged issue in the pull request template, with an exemption for repository collaborators performing routine maintenance or already-planned work
• add a Linked Issue Check workflow that validates the linked issue and triaged label for external pull requests

The triaged repository label was created with the same color and description used by DataDesigner.

Why

The repository did not document or enforce that community contributors should align with maintainers before beginning implementation or opening a pull request. A concrete triaged label makes the ready-to-work state visible and unambiguous, while an automated check keeps the policy consistent.

Usage

• External contributors open an issue and wait for a maintainer to apply triaged.
• Their pull request body links the issue with Fixes #NNN, Closes #NNN, or Resolves #NNN.
• The workflow verifies that the reference is an issue and that it carries triaged.
• Repository collaborators and Dependabot are exempt.
• Adding triaged to an issue automatically re-evaluates open pull requests that reference it.

How

The workflow uses pull_request_target so it can report failures on fork pull requests, but it never checks out or executes contributor-controlled code. It reads PR metadata through GitHub APIs, posts or updates one marked status comment, and fails the check when the issue reference is absent, invalid, or untriaged.

Validation

• make check
• git diff --check
• parsed the workflow YAML and ran bash -n against all seven embedded shell blocks
• verified the triaged label exists with description: Issue reviewed and approved by a maintainer

---

Description updated with AI

[andreatnvidia]

One repository-setting follow-up: the current protect ruleset requires one approval but no status checks. This workflow’s exit 1 is therefore advisory and does not technically prevent merging, while CONTRIBUTING.md and the bot comment describe it as a merge requirement. Do we also want to add Linked Issue Check / check as a required status after the workflow lands? Otherwise, we may want to soften the wording so it does not imply a hard merge gate.

[nabinchha]

Thanks for flagging this. I took the wording option in 94a7ae9 rather than changing repository settings in this PR: the contributor guidance and template now use “expected”/“should,” the bot says “for this check to pass” instead of “before the PR can be merged,” and CONTRIBUTING.md explicitly notes that repository rules must require Linked Issue Check / check for a hard merge gate. The ruleset itself is unchanged.