Add contribution standards and partner integration guide

[Juminstock]

Summary

Establishes a clear, public standard for how external contributors, partners, and tooling projects can contribute to or request inclusion in the Astar documentation.

Changes

• Added CONTRIBUTING.md with eligibility criteria, a two-stage proposal process (issue before PR), documentation standards, writing style guide, and review SLA
• Added .github/ISSUE_TEMPLATE/new-integration-request.yml — structured form for partners requesting inclusion, with an eligibility checklist and focus on Astar EVM mainnet deployments
• Added .github/ISSUE_TEMPLATE/content-update-request.yml — form for reporting incorrect or outdated content
• Added .github/pull_request_template.md — mandatory checklist applied to every PR opened against this repository
• Updated README.md with a new "Partner and Tooling Contributions" section explaining the eligibility criteria and the three-step process in a collapsible block, consistent with the existing README format

Notes

All references are scoped to Astar EVM. Shiden Network and Soneium are not mentioned. The two-stage process (open an issue first, then a PR only if approved) is the standard used by Polkadot, Ethereum.org, and Avalanche docs to maintain quality and prevent unreviewed entries.

[github-actions]

Visit the preview URL for this PR (updated for commit da0c0b6):

https://astar-docs--pr795-feat-add-contributio-cuw6g8h5.web.app

_{(expires Fri, 12 Jun 2026 15:55:07 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: f2f13e9b593d211faae6343d67a88fac3fd7268d}

[Gunit2481]

Hi Carlos, thanks for this, it's a clean and well-structured contribution. The writing is tight and it matches our repo conventions: yarn build is correct, the <Figure> import path and props line up with existing usage, and the docs/build docs/use docs/learn structure is accurate. A few things to address before we merge.

1. Scope it to Astar Network, not Astar EVM (main change request)

Astar is an L1 with an EVM, but that doesn't mean only EVM projects belong in the docs. Infra and tooling are often chain-agnostic: RPC providers, nodes, indexers, block explorers, wallets, analytics. The form itself offers Infrastructure / RPC, Developer Tooling, Analytics, Wallet, and Oracle as categories, but then forces a required "live on Astar EVM mainnet" checkbox. An RPC provider or indexer can't truthfully tick that box, so we'd be blocking exactly the kind of integrations we want.

Please replace "Astar EVM" with "Astar Network" across the eligibility and scope wording. The occurrences:

• CONTRIBUTING.md line 25 ("deployed and functional on Astar EVM") and line 40 ("Live deployment URL on Astar EVM")
• README.md lines 210, 219, 230
• .github/ISSUE_TEMPLATE/new-integration-request.yml lines 11, 45, 85, 95
• .github/pull_request_template.md line 28

For the URL field and the eligibility checkbox, "live on Astar Network mainnet" reads fine for infra, so the swap alone fixes it. If you want, soften "deployment URL" to "deployment or service URL" so it doesn't feel contract-specific.

2. The build CI claim doesn't hold for forks

The guide tells partners to open a PR from a fork and says CI build must pass. But firebase-hosting-pull-request.yml is gated with if: head.repo.full_name == github.repository, so the build/preview job only runs on same-repo branch PRs, not forks. The markdown link check does run on forks, so "links must resolve" is fine, but the build line overpromises. Either soften it ("a maintainer will verify the build passes") or drop the fork instruction.

3. Labels (done on our side)

The two labels your forms reference, integration request and content update, didn't exist yet so they would have been dropped silently. I've created both, so the forms will now attach them correctly. No action needed from you.

Minor / optional

• CONTRIBUTING.md ends by pointing to a #documentation Discord channel and GitHub Discussions. Can you confirm both exist / Discussions is enabled? Otherwise let's point somewhere live.
• The Page Structure section says every page needs a title in frontmatter. Most of our existing pages rely on the H1 instead (only ~68 of 284 set title), so consider wording it as recommended rather than required.
• Inside CONTRIBUTING.md the links go to the raw .yml template files. The README correctly uses the issues/new/choose chooser; worth matching that so contributors land on the form, not raw YAML.

Nothing here is structural, mostly the EVM scoping and the CI wording. Once those are in I'm happy to approve. Thanks again.

[Gunit2481]

Approving. Thanks for the quick turnaround, Carlos, all the feedback is addressed cleanly:

• Scope now reads "Astar Network" throughout, and the deployment field accepts a "deployment or service" URL so chain-agnostic infra and tooling (RPC, indexers, wallets, explorers) are no longer excluded.
• CI wording no longer overpromises automated build checks on forks; it now correctly frames the build as a local check that a maintainer verifies before merge.
• Minor items handled too: frontmatter title is now "recommended but not required," and the CONTRIBUTING links point to the issue chooser instead of raw YAML.

The labels are created on our side, so the issue forms will attach them correctly. Good work on this.