designseeddocs

Community

Contributing standards

2 min read

Every contribution — whether a library submission, an issue, or a code PR — passes through the same standards. They exist so the community stays high-signal and welcoming.

Code of conduct

Adapted from the Contributor Covenant:

  • Be respectful. Disagreement is fine; rudeness isn't.
  • Be specific. "This is broken" is unhelpful; "This breaks because X, expected Y" is gold.
  • Be patient. Reviewers are humans on their own schedules.
  • No bigotry, harassment, or personal attacks. Reported violations result in a warning; repeated violations get bans.

The full document is at github.com/designdrop-app/.github/CODE_OF_CONDUCT.md.

Technical standards

For any code or content contribution:

  • Tests must be green. PRs that fail CI are not reviewed until green.
  • Validator must be green. For library submissions: zero errors, warnings documented in the PR description.
  • Commits are conventional. feat: ..., fix: ..., docs: .... The release tooling parses these to generate changelogs.
  • Branch naming. feature/..., fix/..., docs/.... Keeps the issue graph navigable.

Library submission standards

See Submission guidelines for the full checklist. Briefly:

  • Complete required token roles (primary, ink, bg, accent, muted).
  • AA contrast everywhere (4.5:1 body, 3.0:1 large text).
  • Both light + dark themes when applicable.
  • Round-trip clean (DESIGN.md → CSS → DESIGN.md is identity).
  • Patterns section that actually helps an agent.
  • Brand fidelity (feels like the source brand).

Documentation standards

Docs PRs follow:

  • One topic per page. Don't mix the editor's typography panel with the CLI's validate command.
  • Show, don't tell. Code blocks > prose explanations. Inline examples > "see X".
  • Be honest about gaps. If a feature isn't shipped yet, mark it. We'd rather have honest stubs than aspirational lies.
  • Keep voice consistent. Direct, concise, second-person ("you do X"). No marketing breathlessness.

Filing issues

Good bug reports include:

  1. What you tried. Step-by-step.
  2. What happened. Actual behavior + screenshots / logs.
  3. What you expected. What should have happened instead.
  4. Environment. OS, Node version, CLI version (designdrop --version), browser if relevant.

Vague issues ("it doesn't work") get politely closed with a request for the above.