Community Infrastructure: Website, Playground, RFC Process, And Roadmap

Order

Recommended implementation order: 15 (community infrastructure is important once the language is usable).

Goal

Build the community-facing infrastructure needed to grow the NG ecosystem: a project website, online playground, RFC process for language changes, and a public roadmap.

Motivation

NG currently has no outward-facing community presence. There is no:

• Project website or landing page
• Online playground to try NG without installing
• Documented RFC or proposal process for language changes
• Public roadmap or milestone tracking
• Official communication channels (Discord, forum, mailing list)
• Contribution ladder (good-first-issues, mentorship)

Proposed Components

1. Project Website

ng-lang.org/
├── index.html                 # Landing page: hero, features, quick start
├── install.html               # Download and installation guide
├── learn/                     # Tutorials and guides
│   ├── getting-started.html
│   ├── basic-syntax.html
│   └── ...
├── doc/                       # Full API documentation (generated by ng doc)
│   ├── std/
│   └── ...
├── playground/                # Online code editor (see below)
├── community/                 # Community resources
│   ├── roadmap.html
│   ├── rfc/                   # RFC index
│   ├── contributing.html
│   └── code-of-conduct.html
├── blog/                      # Release announcements, design notes
└── search.html                # Site-wide search

Content:

• Feature overview with code snippets
• Installation instructions for all platforms
• Quick start tutorial
• Full language reference (from this guide)
• Standard library API reference
• Comparison to other languages (Rust, Go, Python, Kotlin)

2. Online Playground

Chosen approach: Server-side execution (MVP). Rationale: No WASM compilation needed. Works with existing ngi binary. Easy to deploy.

Architecture

Browser (Monaco Editor)  ←HTTP→  Playground API Server  ←subprocess→  ngi

API

POST /api/run
{
  "code": "print(\"Hello\");",
  "timeout_ms": 5000
}

Response 200:
{
  "stdout": "Hello",
  "stderr": "",
  "exit_code": 0,
  "duration_ms": 12
}

Response 422 (error):
{
  "stdout": "",
  "stderr": "Type error: ...",
  "exit_code": 1,
  "error": {"line": 1, "column": 8, "message": "..."}
}

Implementation

# playground/server.py (MVP: ~100 lines of Python)

import subprocess, json, tempfile, os

app = Flask(__name__)

@app.route("/api/run", methods=["POST"])
def run_code():
    data = request.json
    code = data["code"]
    
    with tempfile.NamedTemporaryFile(suffix=".ng", mode="w", delete=False) as f:
        f.write(code)
        fpath = f.name
    
    try:
        result = subprocess.run(
            ["./build/ngi", fpath],
            capture_output=True,
            text=True,
            timeout=data.get("timeout_ms", 5000) / 1000
        )
        return jsonify({
            "stdout": result.stdout,
            "stderr": result.stderr,
            "exit_code": result.returncode,
        })
    except subprocess.TimeoutExpired:
        return jsonify({"error": "timeout"}), 408
    finally:
        os.unlink(fpath)

Security sandboxing (MVP):

• Run ngi in a Linux container (Docker) with no network and read-only filesystem
• Kill subprocess after timeout
• Limit output size to 1MB
• Rate limit: 10 requests/minute per IP

Tech Stack (Website)

Component	Technology
Static site generator	Hugo (Go) — fast, single binary
Theme	Custom (or Docsy for Hugo)
Hosting	GitHub Pages + Cloudflare CDN
Playground server	Python Flask → Node.js/Go (future)
Code editor	Monaco Editor (VS Code's editor, browser-based)

Automation

• GitHub Action: on push to main, rebuild website and deploy to GitHub Pages
• GitHub Action: on release, regenerate API docs and

3. RFC Process

A formal process for proposing, discussing, and deciding on language changes:

rfcs/
├── 0000-template.md            # RFC template
├── 0001-error-handling.md      # Accepted RFCs
├── 0002-concurrency.md
├── ...
└── README.md                   # Process documentation

RFC lifecycle:

1. Pre-RFC — Informal discussion on GitHub Discussions
2. RFC — Formal proposal submitted as a PR to the RFCs repository
3. Review — Core team reviews, community feedback period (2 weeks)
4. Decision — Accepted, rejected, or postponed
5. Implementation — Tracked on the roadmap

RFC template sections:

• Summary
• Motivation
• Detailed Design
• Drawbacks
• Rationale and Alternatives
• Unresolved Questions
• Future Possibilities

4. Public Roadmap

NG Roadmap 2026-2027

Q3 2026: Foundation
  - [x] Documentation rewrite
  - [ ] Error handling (Result, ?, try/catch)
  - [ ] HashMap, JSON, DateTime stdlib

Q4 2026: Tooling
  - [ ] LSP server (diagnostics, autocomplete)
  - [ ] ng fmt (code formatter)
  - [ ] ng test (testing framework)

Q1 2027: Ecosystem
  - [ ] Package manager (ngpkg)
  - [ ] Playground
  - [ ] C FFI

Q2 2027: Performance
  - [ ] LLVM AOT compilation
  - [ ] WASM target
  - [ ] JIT compilation

5. Community Channels

Channel	Purpose
GitHub Discussions	Questions, ideas, show-and-tell
Discord	Real-time chat, help, community
Stack Overflow tag	Q&A (once critical mass reached)
Monthly newsletter	Release notes, highlights
Contributor mentorship	Good-first-issue program, office hours

6. Governance

• BDFL model initially (single project lead)
• Core team (3–5 active contributors) for RFC decisions
• Working groups for specific areas (stdlib, tooling, compiler)
• Code review requirements for all changes
• Code of Conduct (Contributor Covenant)

Dependencies

• Requires all core language features to be documented.
• Website can be built with any static site generator (Hugo, Zola, Jekyll).
• Playground requires WASM compilation or server-side ngi.
• RFC process is process-only, no code dependencies.
• Unblocks: community growth, contributor onboarding, language evolution.

Scope

In scope:

• Static website with documentation and guides
• Online playground (server-side MVP)
• RFC repository and process documentation
• Public roadmap
• GitHub Discussions enabled
• Code of Conduct

Out of scope:

• Package registry web interface (separate from package manager)
• CI/CD for the playground
• Localization (English only for MVP)
• Mobile app

Acceptance Criteria

• Website is live at a public URL
• Website documents installation, basic usage, and all language features
• Playground executes simple NG programs and shows output
• RFC template exists and at least one RFC has been submitted
• Roadmap is published and updated quarterly
• New contributors report that the website and docs helped them get started

Potential Challenges

• Website maintenance is ongoing work — no "finish line"
• Playground moderation: need to prevent abuse (infinite loops, resource exhaustion)
• RFC process requires discipline to maintain — easy to bypass
• Community management requires active moderation
• Measuring success: metrics (visitors, playground runs, contributors, packages) need to be tracked early