---
name: SOLNIX-CONTRIBUTOR
description: Contribute to Solnix via the email-patch workflow. Use when sending a patch, joining the discussion, or reporting a bug/security issue the right way.
---

# Contributing to Solnix

Solnix uses an **email-patch workflow** — like the Linux kernel and PostgreSQL,
not forge pull requests. This is a deliberate choice; see
[email-patch-governance](community/steering/email-patch-governance.md).

## Where things go

- **Patches & discussion** → `hackers@solnix.io` (public, archived; NNTP/IMAP read).
- **Security / embargoed** → `security@solnix.io` (private). See
  [report-a-cve](generic/workflows/report-a-cve.md).
- **Announcements** → `announce@solnix.io` (read-mostly).

## Send a patch

1. Clone the source:
   `git clone https://git.solnix.io/solnix.git` (or `solnix-pkgs.git` for the
   bootstrap overlay).
2. Make your change against the right branch (usually `unstable`).
3. `git format-patch` and send to `hackers@solnix.io` (git-send-email style).
4. Sign your email (SSH or GPG) — committer identity matters for trust.
5. Expect `+1`/`0`/`-1` review and a **reproducibility quorum** on anything that
   changes a built artifact. See [reproduce-and-vote](generic/workflows/reproduce-and-vote.md).

## Report a bug

Open it on `hackers@`. Include: the package attr, the edition/rev, the exact
command, and the full error. Check first via `solnix_search` whether it's known.

## Write docs

Documentation patches are first-class. See
[SOLNIX-HANDBOOK-WRITER](SOLNIX-HANDBOOK-WRITER.md) and
[write-a-handbook-chapter](generic/workflows/write-a-handbook-chapter.md).

## The one rule

Be honest about status. Don't describe something as working that isn't. See
[honesty-over-hype](community/steering/honesty-over-hype.md).