As we approach the 1.1.0 release and external reviewers / contributors start interacting with the repo, we should think through how we want to handle:
- Outside contributions — what's our process for accepting PRs from people we don't know? Do we want a
CONTRIBUTING.md explaining the test/lint expectations, the commit-message style, where to discuss design before coding?
- Security disclosures — where should someone send a bug report that contains a vulnerability? Without a
SECURITY.md the default GitHub UX is "file a public issue", which is the wrong channel for security-relevant findings. NC and Etherpad both have a documented disclosure process; we should pick one.
Open questions, not decisions yet
- Is a single maintainer (Jacob) enough, or do we want a small group of named maintainers before the App Store listing goes live?
- For security: private GitHub issue ("security advisory"), email alias, or following NC's own coordinated-disclosure track?
- For contributions: do we want a CLA / DCO sign-off, or are we comfortable accepting straight PRs under AGPL?
- What's the bar for "review-worthy" — small typo fixes self-merge by the maintainer? Or always second-pair-of-eyes from a contributor?
What this issue is
A holding pen for the discussion. Not an action item yet — the goal is to have an opinion before we start getting external traffic, not to ship a perfect process up front.
Done when
- A short
CONTRIBUTING.md exists at the repo root with the agreed conventions (test/lint, commit style, how to propose larger changes).
- A short
SECURITY.md exists at the repo root pointing at the chosen disclosure channel.
- Both files are referenced from
README.md.
Out of scope
- GitHub issue / PR templates — explicitly skipped for now.
- A formal governance document — we're not big enough for that yet.
As we approach the 1.1.0 release and external reviewers / contributors start interacting with the repo, we should think through how we want to handle:
CONTRIBUTING.mdexplaining the test/lint expectations, the commit-message style, where to discuss design before coding?SECURITY.mdthe default GitHub UX is "file a public issue", which is the wrong channel for security-relevant findings. NC and Etherpad both have a documented disclosure process; we should pick one.Open questions, not decisions yet
What this issue is
A holding pen for the discussion. Not an action item yet — the goal is to have an opinion before we start getting external traffic, not to ship a perfect process up front.
Done when
CONTRIBUTING.mdexists at the repo root with the agreed conventions (test/lint, commit style, how to propose larger changes).SECURITY.mdexists at the repo root pointing at the chosen disclosure channel.README.md.Out of scope