Team and collaboration
This page focuses on ownership, cadence, and the kind of contributors each lane is looking for. That makes the collaboration model more honest and more useful than a list of invented titles or vanity biographies.
Collaboration snapshot
5
working groups
5
disciplines in play
4
shared operating principles
The people behind OpenCorex collaborate across product, engineering, design, community, and operations with shared context in public.
Working groups
Shapes the public experience, information architecture, and how visitors move from interest to action.
Ownership
Homepage narrative, section structure, and site-level conversion paths.
Cadence
Weekly review with async design notes between sessions.
Looking for: Product writers, UX thinkers, and front-end contributors.
Owns the technical patterns that keep project tracks coherent, maintainable, and easy to extend.
Ownership
Shared data models, implementation patterns, and release confidence.
Cadence
Short build-oriented check-ins with practical issue slices.
Looking for: TypeScript contributors, maintainers, and systems-minded reviewers.
Maintains visual consistency across cards, sections, responsive layouts, and supporting documentation.
Ownership
Color system, typography hierarchy, reusable surfaces, and interaction polish.
Cadence
Design critique every two weeks plus lightweight async comments.
Looking for: UI designers, accessibility reviewers, and design-system contributors.
Keeps onboarding, contribution guidance, and public support channels welcoming and understandable.
Ownership
Contributor pathways, starter issues, and public-facing support content.
Cadence
Open office-hour rhythm backed by written follow-up notes.
Looking for: Maintainers, facilitators, documentation writers, and moderators.
Grounds product direction in realistic operational needs so polished interfaces still hold up during actual use.
Ownership
Scenario validation, checklist logic, and field-oriented content review.
Cadence
Scenario-based reviews anchored in practical workflows.
Looking for: Researchers, field partners, and contributors with response experience.
Shared principles
We treat contributor experience and operating clarity as first-class work, not side effects of the code.
We document decisions where contributors can actually find them and respond with context, not mystery.
We prefer focused improvements that can be reviewed well over giant rewrites with vague impact.
Design and engineering decisions stay tethered to the people who need calm, reliable tools under pressure.
Clear contributor pathways and kind review habits are essential to the experience, not extras.
Collaboration routes
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.
