# LAVS-001 community surface | | | |---|---| | **Status** | Adopted policy | | **Version** | 1.0 | | **Date** | 2026-05-27 | | **License** | CC BY 4.0 | | **Primary venue** | [GitHub Discussions on `guitargnarr/lavs-format`](https://github.com/guitargnarr/lavs-format/discussions) | This document defines where the LAVS-001 community lives, how to ask questions productively, and what response patterns to expect from Project Lavos LLC. The decision is **GitHub Discussions** on the `lavs-format` repository, not a separate Discord or mailing list. The reasoning is in §3; the practical setup is in §1. --- ## 1. The primary venue — GitHub Discussions All technical questions, implementation discussions, format design feedback, and conformance-suite reports happen at: **[github.com/guitargnarr/lavs-format/discussions](https://github.com/guitargnarr/lavs-format/discussions)** Discussions are organized into categories: - **Announcements** — read-only by community members; used for spec version releases, signing key rotations, and platform-level updates. - **Q&A** — implementer questions about the spec, the conformance suite, edge cases. Marked answered when resolved; serves as a searchable knowledge base. - **Show and tell** — community members sharing their own LAVS-001 implementations, third-party tools, articles, demos. Encouraged. - **Ideas** — proposals for v1.X minor extensions or v2.0 considerations. These are *discussion* of ideas, not formal proposals; formal proposals go through the issue tracker. - **General** — anything that doesn't fit elsewhere. A new community member should: 1. Search existing discussions before posting. Many questions are already answered. 2. Use Q&A category for "how do I" or "why does the spec do X" questions. 3. Use Ideas for "what if the spec did Y" suggestions. 4. Use Show and tell for sharing your own work. 5. Use Issues (not Discussions) for bug reports against the reference implementation or the spec text. --- ## 2. How to ask questions productively The community works better when questions are answerable. The pattern below maximizes the likelihood of a useful response. **Include:** - The version of the spec you're implementing against (`LAVS-001.0`, `LAVS-001.1`, `LAVS-001.2`). - The language and runtime stack you're using. - The specific section of the spec or tutorial that prompted the question, with a link. - The behavior you expected, the behavior you observed. - A minimal repro if your question is about the reference implementation behaving unexpectedly. **Avoid:** - Vague questions like "doesn't work, halp" without context. - Questions that are answered by the existing docs (search the spec, tutorial, IMPLEMENTER-FAQ, and conformance docs first). - Questions that are really feature requests phrased as questions. - Repeat-posts of the same question in multiple categories. **Good question template:** ``` Title: Decoding a v1.2 Environment object in a v1.1 decoder — what wire type to assume for property 358? I'm implementing a LAVS-001.1 decoder in Rust. When I encounter a v1.2 file with an Environment object (Type 19), I correctly skip the object type per the property dictionary. However, I'm not sure how my v1.1 reader should handle property 358 (skyAccentExponent) — the property table doesn't include it in my v1.1 build. I've read §6.5 and the wire-type tag table mechanism, and I think the answer is "read the wire type from the file's dictionary, not from my built-in property table" — but I want to confirm before shipping. Spec section: LAVS-001.md §5.2 + §6.5 Tutorial section: §4 (Property dictionary) ``` This question is answerable in 1-2 sentences. It demonstrates the asker has read the docs and identified the specific gap. --- ## 3. Why GitHub Discussions over Discord / mailing list / Discourse The decision considered four alternatives: **3.1 GitHub Discussions (CHOSEN).** - Zero infrastructure cost. - Lives where the code lives. A new community member doesn't have to learn a separate platform. - Searchable by Google. Q&A history accumulates and gets indexed. - Threaded discussions, code blocks, markdown rendering, GitHub identity integration. - Tightly coupled to issues and PRs, so a discussion that becomes a bug report converts cleanly. - No moderation infrastructure required initially; community is small enough that GitHub's default tools suffice. **3.2 Discord (rejected).** - High engagement, but ephemeral by default. Questions answered in chat don't accumulate as searchable knowledge. - Requires moderation infrastructure (channel structure, roles, anti-spam) before opening. - Separate identity from GitHub; community members maintain two presences. - Acceptable as a SECONDARY venue if engagement reaches a level where async chat is useful (typically 50+ active members). Not the primary at small scale. **3.3 Mailing list (rejected).** - Old-school but valid for academic / research communities. - Email lists fragment the conversation; threads are hard to follow across email clients. - Search is poor unless the list is mirrored to a web archive. - Acceptable for very-low-volume conversations but Q&A from implementers benefits from the threading model GitHub Discussions provides. **3.4 Self-hosted Discourse / forum (rejected).** - Significant infrastructure overhead (hosting, moderation, spam control). - Justifiable only at scale (hundreds of active members). - Premature at LAVS-001's current adoption stage. The decision is reversible. If GitHub Discussions becomes inadequate at higher scale, migration to Discord (real-time) or Discourse (forum) is straightforward; the discussion history can be archived and linked from the new venue. --- ## 4. Response expectations from Project Lavos LLC Project Lavos LLC (as the spec maintainer) commits to the following response patterns: | Discussion type | Target response time | Action | |---|---|---| | Bug in reference implementation | < 3 business days | Acknowledge; assign priority; track to resolution. | | Spec ambiguity question | < 3 business days | Clarify in the discussion; if material, follow up with a spec doc update. | | Implementation help question | < 1 week | Answer or redirect to docs. Best-effort. | | Feature request / extension idea | < 2 weeks | Acknowledge; explain how the idea fits (or doesn't) into the spec's evolution plan. | | General discussion | best effort | Engage when relevant. | Outside business hours, weekends, and travel windows, response times may extend. Project Lavos LLC is currently a one-person operation; community expectations should be calibrated accordingly. **Implementers and contributors are not obligated to respond to anything.** The community is built on best-effort goodwill, not contract. --- ## 5. Conduct expectations Standard open-source conduct: - Be respectful of other community members and their implementations. - Disagreements about format design are welcome; ad hominem attacks are not. - Questions from beginners are welcome; condescension toward them is not. - Code-of-conduct violations are addressed by the maintainer (Matthew Scott) directly; serious issues escalate to repo-level moderation tools. LAVS-001 attempts to be a small, civil community. Maintaining that takes ongoing effort from all participants. --- ## 6. Channels NOT for community questions These channels exist but are not the right place for general implementer questions: - **Direct email to `editions@projectlavos.com`** — reserved for commercial license inquiries (per [`LICENSING.md`](./LICENSING.md) §6). Implementer questions sent here will be redirected to GitHub Discussions. - **Direct Twitter / Bluesky DMs** to Matthew — reserved for personal contact. Not the venue for spec questions; the response will be "please post in GitHub Discussions." - **Issues on the reference implementation repo** — issues are for bug reports and verified spec divergences. Open-ended questions belong in Discussions. The reason for routing is search. A question answered in Discussions becomes a resource for future implementers; the same question answered in DMs disappears. --- ## 7. Operational setup GitHub Discussions on `guitargnarr/lavs-format` will be enabled with the following initial state: - Categories: Announcements, Q&A, Show and tell, Ideas, General (per §1). - Welcome message pinned in General linking to: this COMMUNITY.md, the spec, the tutorial, the conformance suite, and the implementer FAQ. - Read access: public. - Post access: any GitHub user. - Spam protection: GitHub's defaults; manual review of first-time posters' first post. This setup is intentionally low-friction. The cost of standing it up is roughly an hour of administrative work on the repository settings. --- ## 8. When to revisit This community surface decision should be revisited at the following milestones: - **50+ active monthly community members.** At this scale, Discord-style real-time chat becomes more valuable. Add Discord as a SECONDARY venue (not replacement) and link both directions. - **Confirmed need for sub-community sub-groups** (e.g., "LAVS for game engines," "LAVS for academic art research"). At this point a more structured forum (Discourse) may serve sub-community organization better than a single Discussions space. - **Volume of issues + discussions exceeds maintainer bandwidth.** This is the signal that the community needs additional maintainers — paid or volunteer — and the decision shifts to recruitment, not platform. Until those milestones, GitHub Discussions remains the primary venue. --- *This document is the community surface decision for LAVS-001 as of the date above. Cross-referenced from [`README.md`](../README.md) and from [`LAVS-001.md`](./LAVS-001.md) §1 (Conformance) for implementers seeking the right place to ask questions.*