docs: add CONTRIBUTING, code of conduct, and Forgejo templates

Contributor onboarding for the self-hosted toolchain (issue #37):

- `CONTRIBUTING.md`: prerequisites, the bootstrap one-liner, the dev loop
  (`bin/x reseed` -> `bin/x bootstrap-cfree` -> `bin/x test`), stdlib-addition
  guidance, and the code/commit conventions (Conventional Commits, ludic-fmt,
  one-job-per-file, Ludic-not-C/Python/JS for new tooling).
- `.forgejo/issue_template/`: bug, proposal, and cleanup/DX templates.
- `.forgejo/pull_request_template.md`: a checklist covering tests, the
  bootstrap fixpoint, formatting, docs/inventory, and commit style.
- `.forgejo/CODEOWNERS` and a short `CODE_OF_CONDUCT.md`.

Closes #37

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Orkun ÇAKILKAYA 2026-08-30 16:46:30 +03:00
parent 3bab2d2d4c
commit 7d64a617d4
7 changed files with 238 additions and 0 deletions

4
.forgejo/CODEOWNERS Normal file
View file

@ -0,0 +1,4 @@
# Default owner for everything in the repo. Forgejo requests review from these
# owners on matching pull requests. See:
# https://forgejo.org/docs/latest/user/code-owners/
* @orkun

View file

@ -0,0 +1,34 @@
---
name: "Bug report"
about: "Something in the compiler, runtime, or tooling behaves incorrectly"
title: "bug: "
labels:
- bug
---
## What happened
<!-- A clear description of the incorrect behaviour. -->
## Minimal reproduction
<!-- The smallest .ludic program (or command) that triggers it. -->
```ludic
```
## Expected vs actual
- **Expected:**
- **Actual:**
## Environment
- Command used (e.g. `bin/x app foo.ludic --headless`):
- Target (native macOS / headless / web-wasm):
- Commit (`git rev-parse --short HEAD`):
- OS / arch:
## Notes
<!-- Stack traces, generated IR, or anything else that helps. -->

View file

@ -0,0 +1,21 @@
---
name: "Cleanup / DX"
about: "Repo hygiene, tooling, docs, or developer-experience improvements"
title: ""
labels:
- cleanup
- dx
---
## Problem
<!-- What friction or inconsistency exists today? -->
## Proposal
<!-- What to change. Keep it scoped and low-risk. -->
## Acceptance criteria
- [ ]
- [ ]

View file

@ -0,0 +1,31 @@
---
name: "Proposal"
about: "Propose new language, stdlib, or runtime surface"
title: "Proposal: "
labels:
- proposal
---
## Summary
<!-- One or two sentences: what should exist that doesn't today. -->
## Motivation
<!-- What can't be done cleanly now? Who needs this and why? -->
## Proposed surface
<!-- The namespace/API or syntax you propose. Show it in use. -->
```ludic
```
## Determinism & backends
<!-- Ludic's runtime is deterministic fixed-point. Does this proposal stay
replay-safe? Does it work on native AND web-wasm, or is it host-gated? -->
## Alternatives considered
## Open questions

View file

@ -0,0 +1,24 @@
<!-- Thanks for contributing to Ludic! Please fill in the checklist below. -->
## What & why
<!-- What does this change and why? Link the issue: Closes #NN -->
Closes #
## Checklist
- [ ] `bin/x test` passes.
- [ ] For compiler/runtime changes: `bin/x reseed && bin/x bootstrap-cfree`
still reaches the self-hosting fixpoint with no C compiler in the loop.
- [ ] `ludic-fmt` leaves the touched files unchanged (2-space, LF, UTF-8).
- [ ] New/changed stdlib symbols are documented under `docs/language/**` and
registered in `tools/docgen/inventory.json`
(`python3 tools/docgen/check.py` passes).
- [ ] Commits follow [Conventional Commits](https://www.conventionalcommits.org).
- [ ] No new C / Python / JS in tooling (Ludic only), and no generated
artifacts committed outside `build/` / `bin/`.
## Notes for reviewers
<!-- Anything reviewers should look at closely, or follow-ups deferred. -->