Contribution guide

Join the work with enough context to ship something useful on your first pass.

OpenCorex is easier to contribute to when the public story, the design language, and the implementation details stay aligned. This page focuses on the practical working rhythm rather than live vanity metrics.

See the tracks first Review the docs hub

Start here this week

contribution lanes

quality pillars

Working note

The public UI is now static-first. We do not rely on runtime GitHub API calls to populate contributor stats, project lists, or team content.

Choose a lane

Contributions are organized around clear output, not vague requests for help.

UI and front-end polish

Refine layout, interaction states, accessibility, and responsive behavior across the public experience.

Ideal for: Front-end engineers and interface-minded generalists.

Output: Page improvements, reusable sections, and cleaner responsive behavior.

Project storytelling

Turn complex platform work into short, understandable descriptions that help new visitors know why each track matters.

Ideal for: Technical writers, product thinkers, and maintainers who enjoy synthesis.

Output: Clearer summaries, case studies, and contributor guidance.

Docs and onboarding

Improve setup guides, review expectations, contribution rituals, and maintenance checklists.

Ideal for: Documentation contributors and developer experience advocates.

Output: Faster onboarding and fewer repeated support questions.

Research and field validation

Pressure-test ideas with realistic usage scenarios, accessibility reviews, and operational assumptions.

Ideal for: Researchers, QA contributors, and people close to response workflows.

Output: Better edge-case coverage and more grounded product decisions.

Design systems and visuals

Strengthen visual consistency, reusable components, and presentation quality across the ecosystem.

Ideal for: Designers, front-end engineers, and brand stewards.

Output: Sharper hierarchy, stronger cohesion, and more durable patterns.

Community support

Help newcomers orient themselves, route questions, and keep discussion spaces warm, clear, and useful.

Ideal for: Community builders and contributors who enjoy facilitation.

Output: A healthier contributor experience from first visit to first merged update.

Working rhythm

Start with the story

Read the project and documentation pages first so implementation work lands in the right context and uses the same language as the rest of the platform.

Run the site locally

Install dependencies, start the Next.js app, and review your change across the homepage, navigation, and footer before polishing a single section in isolation.

Ship a small durable slice

Prefer one reviewable improvement at a time: a content refinement, a layout fix, a stronger component, or a clearer support path.

Leave the next person context

Document assumptions, test the responsive flow, and make sure labels, links, and supporting copy explain why the change exists.

Local setup

Run the site, review the shared content, and keep changes small enough to verify well.

git clone https://github.com/OpenCorex-org/OpenCorex-org.github.io.git
cd OpenCorex-org.github.io
pnpm install
pnpm dev

pnpm install

Install the workspace dependencies defined by the lockfile.

pnpm dev

Run the local development server for layout and content review.

pnpm build

Verify that the site compiles cleanly before handoff or release.

pnpm lint

Run the configured lint checks for TypeScript and React code.

Install dependencies

Use the existing package manager lockfile and run the local dev server before making layout changes.

Edit shared content

Update the canonical content module first whenever multiple pages reuse the same story or metadata.

Review in context

Check navigation, page flow, and footer handoff so the whole site feels coordinated after each change.

Quality expectations

Design quality

Accessible contrast

Intentional spacing

Clear hierarchy

Consistent interaction states

Code quality

Typed data structures

Reusable sections

Build-ready pages

No unnecessary runtime fetches

Content quality

Specific messaging

Short paragraphs

Actionable labels

Honest, non-inflated claims

Release quality

Responsive review

Link checks

Metadata updates

Visible follow-up notes

Review checklist

Before handing work over, make sure the whole site still feels coordinated.

Keep sections readable on small screens before polishing desktop details.

Prefer plain language over internal jargon whenever content faces the public.

Pair visual changes with spacing, contrast, and keyboard-flow checks.

Keep content in shared data structures when multiple pages depend on it.

Document follow-up work clearly instead of hiding unfinished assumptions in the UI.

Support routes

Ask for help in the right place so the next contributor can learn from the answer too.

GitHub organization

Review repositories, issue history, and implementation context once you know which track you want to improve.

Community chat

Ask orientation questions, share work in progress, and coordinate with contributors in public.

Maintainer contact

Use a direct route for onboarding help, collaboration requests, or questions that need a project owner.

Security contact

Route vulnerabilities or sensitive operational concerns through a private channel instead of posting them in public discussion threads.