feat: Update documentation to clarify Nix usage and enhance onboarding for non-Nix contributors

2026-05-23 18:17:47 -05:00
parent 94c7cadcd7
commit 2ecab4db12
4 changed files with 21 additions and 8 deletions
@@ -21,12 +21,12 @@ Out of scope for early phases:

 FeDIY is intended to be shipped and operated through a small set of first-class packaging targets so instance operators can choose the deployment style that fits their environment:

- **Nix flake/devShell**: reproducible development and build environment for contributors and operators who prefer Nix.
+- **Nix flake/devShell**: reproducible development and build environment for contributors and operators who prefer Nix. It is a convenience path, not a requirement for contributing.
 - **Flatpak**: desktop-friendly distribution path for bundled client or companion tooling where applicable.
 - **OCI/Docker container image**: a standard containerized deployment path for managed hosting, Kubernetes, and simple `docker compose` installs.
 - **NixOS module**: optional system integration for operators already using NixOS.

-These targets should share the same application artifact and configuration model where possible. Packaging differences should be limited to how the binary is delivered, configured, and run; they should not fork the core runtime behavior.
+These targets should share the same application artifact and configuration model where possible. Packaging differences should be limited to how the binary is delivered, configured, and run; they should not fork the core runtime behavior. Contributors should be able to work productively with standard Rust tooling even if they never enter the Nix shell.

 The flake and related packaging shells should be reviewed periodically so the included tools stay aligned with current phase needs. The default posture is to keep the dev environment lean and add tools only when they directly support active work such as building, testing, localization, accessibility validation, container packaging, or release tasks.

@@ -10,7 +10,7 @@ Build a federated DIY project-hosting platform in Rust, inspired by the utility

 Goals:

- Stabilize development environment and reproducible tooling.
+- Stabilize development environment and reproducible tooling, while keeping the contributor path usable for people who do not use Nix.
 - Define domain language and baseline architecture docs.
 - Establish quality process (TDD/BDD + GitHub Flow).
 - Clarify the core-plus-extension project contract before implementation.
@@ -21,6 +21,7 @@ Exit criteria:
 - Agreed glossary and architecture baseline.
 - Documented contribution and branch workflow.
 - CI skeleton in place for formatting, linting, and tests.
+- Documented onboarding path for non-Nix contributors using standard Rust toolchain commands.
 - ADR for project revision lifecycle (draft/publish/supersede).
 - ADR for composable extension mechanism (shape, namespacing, discovery).
 - ADR for persistence layer architecture (PostgreSQL as primary target; repository abstraction pattern; query library selection; SQLite future-option strategy).