Day

Contributing to Day

Day is a young project. Its architecture is still moving, and the most useful contribution right now is a conversation, not a patch.

Start with a conversation

  • For an idea, a question, or a design concern, open a thread in GitHub Discussions.
  • For a bug, file a GitHub Issue with the target platform, the Day version, and steps to reproduce — a failing dayscript file is the best reproduction there is.

Please do not open a pull request without a discussion or issue that concluded a patch is wanted. A change that looks small on the surface often crosses nine backends, the docs, and the design record, and reviewing an unexpected patch costs more than talking the change through first. PRs without a linked conversation are likely to be closed with a pointer to this file.

When a patch is agreed on

Once a discussion lands on “yes, send a patch”:

  1. Reference the discussion or issue in the PR description.
  2. Build and run through the day CLI (day build, day launch), not bare cargo.
  3. To exercise your change in a real app (the showcase, or your own), build that app against your checkout with day patch --local — Developing Day and an app together covers the workflow. A framework feature usually lands with a Day-Showcase screen that demonstrates it, as a second PR that follows the framework change.
  4. Before reporting work ready to commit or push, run cargo fmt --all and bash scripts/ci/check-ready.sh against all outstanding changes. This checks generated matrices, formatting, and host Clippy with test targets and warnings denied. Regenerate stale tables using their scripts/ci/*-matrix.sh generators, then rerun the gate. The checks accept correct uncommitted tables and never rewrite them. Run scripts/ci/lint.sh for the full available platform Clippy matrix and cargo test for the crates you touched; report skipped platform checks when handing off work. Install the tracked hook once per clone with bash scripts/install-hooks.sh: it formats, checks the generated matrices, and separately checks staged matrix inputs, so an unstaged correction cannot hide stale generated content in the commit. The hook skips host Clippy to keep commits fast, so it does not replace check-ready.sh. Builds and tests do not replace lint validation.
  5. Update the documentation the change affects in the same PR: the relevant docs/*.md page, and the DESIGN.md section that describes what you changed.

Documentation authoring

Follow the writing style guide, documentation conventions, authoring workflow and checks, and page templates. Use the existing shared glossary as the terminology source. Use the documentation maintenance checklist for review, freshness, platform-claim changes, and publication checks. Named documentation ownership remains deferred; record the reviewer and evidence for each change without assigning a permanent owner.

Platform support tiers

Every (OS, toolkit) target sits in a support tier, from Tier 1 (supported: thoroughly tested, highest attention to quality) down to Tier 4 (development: compatibility combinations no app ships on). The Platform support page defines all four and says where each target stands today.

A tier records the maintenance a target has, not a verdict on the platform, so a target moves up when people show up to keep it there. Taking a platform up a tier means taking on the work that tier promises:

  • an owner for the backend who reviews the patches that touch it;
  • the showcase walkthrough run on real hardware before a release, not only in CI;
  • triage for that platform’s bug reports, with reproductions the rest of us can run;
  • its toolchain kept green in CI as SDKs, signing, and packaging move.

If you or your team can commit to that, open a Discussion naming the target and what you can cover. Tiers move down the same way: a target whose maintainer moves on, or whose CI leg stays red, drops until someone picks it up.

Contribution terms

By submitting a contribution to this repository — a pull request, a patch, or any other material intended for inclusion — you agree to the following:

  1. The contribution is your own work, or you otherwise have the right to submit it under these terms.
  2. Copyright in the contribution is transferred to The Daybrite Project upon submission.
  3. Your contribution is published under the project’s licenses (below), and the submission record is public and permanent.

A single copyright holder keeps the licensing of every file uniform and lets the project act on license questions for the work as a whole. If you cannot agree to the transfer, say so in the discussion before any code is written — do not open a PR.

Licenses

  • Code is licensed under the Mozilla Public License 2.0 — see LICENSE.
  • The documentation (docs/) and the website (website/) are licensed under Creative Commons Attribution-ShareAlike 4.0 — see docs/LICENSE and website/LICENSE.
  • Source files carry a Copyright © The Daybrite Project line and an SPDX-License-Identifier header naming the license that applies to them.