Documentation

Build with Plavist

Plavist is open source. Self-host the stack, contribute features, or use the managed cloud when you want interviews that scale without losing the human plan.

Issues, PRs, and merges

This is how we keep Plavist shippable while staying open to contributors.

Opening an issue

  1. Search existing issues first (open and closed).
  2. Use a template: Bug or Feature.
  3. Bugs need: steps to reproduce, expected vs actual, environment (OS/Node/browser), and logs with secrets redacted.
  4. Features need: problem, proposed approach, and why it fits Plavist’s interview-plan thesis.

Claiming work

Comment “I’d like to take this” on the issue. Maintainers assign when possible. If there’s no update for 7+ days, the issue may be reopened for others.

Pull request checklist

  • Title matches intent (`feat:`, `fix:`, `docs:`)
  • Linked issue (`Closes #123`)
  • Summary of what changed and why
  • How you tested (commands + expected result)
  • Screenshots for UI changes
  • Secrets scan / CI must pass

Review & merge

  1. Maintainer reviews for correctness, scope, and security.
  2. Address review comments with new commits (no force-push to shared PR branches unless asked).
  3. Squash-merge to main once approved and green.
  4. Deploy happens from main (server CI deploys production; client via your hosting pipeline).

Labels we use

good first issue   — onboarding-friendly
bug                — broken behavior
enhancement        — new capability
docs               — documentation
security           — vuln / secret / auth
needs reproduction — waiting on reporter
blocked            — external dependency
bounty             — eligible for cloud-funded reward

Bug bounties (cloud-funded)

High-impact security and reliability issues may be labeled bounty. Terms will live in SECURITY.md. Report vulnerabilities privately first — never open a public issue with an exploit.