Contributing
You can contribute to Dayu without a project appointment or institutional affiliation. Start with a task you can explain and verify, and follow the Code of Conduct.
What to contribute
- Feedback and tests: reproduce an issue, describe expected behavior, add a missing test, or check an example.
- System improvements: improve the framework, an application, a deployment template, or an extension using existing interfaces.
- Documentation and translation: clarify a tutorial, update a screenshot, fix a link, or improve the English and Chinese pages.
- Review and research: review a proposal, validate a result, or help another user understand the system.
Choose a repository
| Your contribution | Repository and guide |
|---|---|
| System code, applications, hooks, scheduling policies, tests, implementation docs, or examples | Dayu system · Contribution guide |
| Public tutorials, homepage, blog, navigation, or translations | Documentation website · Website contribution guide |
For system code navigation, start with the repository quickstart and development guide. For help choosing a task or finding a reviewer, use Support & Contact.
Your first contribution
- Explain the problem and intended result in an issue or PR. Comment on an existing issue to express interest.
- Fork the appropriate repository and create a focused branch from its default branch.
- Make the change and update affected examples, documentation, translations, or tests.
- Open a PR describing the change, related issues, validation results, and any checks you could not run.
- Address review feedback and request renewed review after substantive changes.
Routine contributions can start directly with a PR. Significant changes to shared system interfaces or sensitive behavior require the short design discussion described below.
System review requirements
| Change | Review path |
|---|---|
| Routine fixes, documentation, tests, or extensions within existing interfaces | Relevant checks and at least one independent Maintainer approval. |
| Significant changes to shared Task/DAG or API contracts, install/cleanup behavior, compatibility, security boundaries, or release permissions | A short design issue and two independent technical approvals of the implementation, including at least one Maintainer. |
| Project direction, governance, or an unresolved dispute | Public discussion and a recorded TSC decision; implementation receives the applicable technical review. |
A qualified Contributor without write access can provide the second technical approval for a significant change. Reviewers must be distinct people who did not author the change. TSC offices add no extra approval stage. An extension using existing processor, hook, scheduler, or visualization interfaces normally follows routine review.
Use GitHub's Review changes → Approve / Request changes controls. Review requests help route work; labels, ordinary comments, bots, and AI reviews do not replace the required human approvals. A Maintainer can help request a reviewer when needed. The full rules are in GOVERNANCE.md; maintainers can consult the OWNERS guide.
Website contributions follow the website's own review process. Technical explanations may also need review from a system maintainer familiar with the affected behavior.
Local documentation setup
In the website repository, use Node.js 20:
npm ci
npm start
Build both languages and preview the production result before requesting review:
npm run build
npm run serve
The build checks community data, document links, MDX, and site configuration. System contributions use the system validation guide; choose checks relevant to the behavior you change.
Documentation workflow
Update English content and its Chinese translation together. Community pages describe current project people, participation, and governance; their shared member data comes from the system roster. See the website contribution guide for content locations and roster synchronization.
Version lifecycle
Technical documentation has release snapshots. Community content is maintained independently of those snapshots. Keep release-specific instructions in Documentation and community information in Community.
Commit messages
Use a concise subject that identifies the area and change, such as
docs: clarify installation prerequisites or i18n: translate the contribution guide.
Explain the reason and validation in the PR.