This repository is a good place to contribute if you understand one principle early: the highest-value changes are often the ones that make public claims narrower, safer, and easier to verify. In a privacy-focused project, a careful docs correction can be more important than a flashy new page because it changes what readers trust.

What Counts As A Good Contribution Here

Useful contributions in this repo include:

The common thread is evidence. Good contributions make the next reader less likely to leave with the wrong mental model.

Ground Rules Before You Edit

The local repo rules matter:

• keep public artifacts in English;
• prefer local repo evidence first and whitepaper evidence second;
• back up full rewrites of text-like files before replacing them;
• avoid destructive edits and unsupported assumptions;
• finish with the repo verification path.

Those rules are not ceremony. They protect planning files, public docs, and trust boundaries from accidental damage.

A Practical Contribution Loop

For most repo-local changes, the contribution loop is:

1. read the target page and nearby navigation files;
2. find the content/whitepapers/ passages that justify the claim;
3. edit the content or workflow asset;
4. run npm run lint;
5. run npm run verify;
6. submit the change through the repo workflow attached to github.com/z00z-labs/z00z-website.

If the change is large, add a review note or summary that explains what boundary was tightened or clarified.

What Maintainers Will Usually Reject

Expect pushback on contributions that:

• add claims not supported by local files or the corpus;
• present target architecture as already shipped;
• introduce commands not supported by package.json or repo scripts;
• post sensitive security details in a public contribution thread;
• widen support or contact claims beyond what the repo can currently prove.

That rejection standard is healthy. The docs become safer when contributors know that polished overreach still counts as a bug.

Where To Ask Before Opening A Large Change

For uncertain builder questions, start with Developer Support. For ordinary repo-local issues, use the public issue tracker attached to github.com/z00z-labs/z00z-website. For security-sensitive findings, switch to Responsible Disclosure instead of posting the details in a normal contribution thread.

This separation keeps contribution channels productive and keeps security channels from being diluted by ordinary support traffic.

Why Useful Work Still Needs Evidence

The broader Z00Z corpus includes strong language about contribution quality, evidence, and challengeability. That matters here too. A helpful contribution is not judged only by enthusiasm or volume. It should leave behind something another reviewer can inspect: a cleaner page, a fixed route, a clearer claim boundary, a passing verify run, or a more accurate evidence trail. That is as true for documentation work as it is for code.

The Best First Contribution

If you are unsure where to start, pick a page that still reads like a scaffold, or find a place where the current wording is stronger than the evidence. Those contributions are small enough to review and meaningful enough to improve the project immediately.

Contribution Flow

The flow starts with source authority because many bad contributions are well written but unsupported. A new docs claim needs a whitepaper section. A repo workflow change needs a script, package, or instruction source. A security recommendation needs threat-model or disclosure authority. A useful-work framing needs evidence discipline rather than enthusiasm alone.

The best first contribution is small, evidence-linked, and easy to review. Fix a stale source link, improve an evidence block, clarify a maturity boundary, add a missing Read Next path, or tighten a troubleshooting step against scripts/verify.sh. These changes make the docs safer without creating new architecture. Avoid starting with broad rewrites, token claims, legal claims, or security instructions unless you already have the exact source and review path.

Security And Useful-Work Boundaries

Security reports are contributions, but they should not be posted through ordinary public contribution channels when they contain exploit details or secrets. Route those through responsible disclosure. Useful-work-aligned tasks also need evidence. A contribution should be inspectable, challengeable, and bounded by the relevant program rules before anyone treats it as rewardable work. The Proof-of-Useful-Work and DAO papers are useful here because they separate fact evidence, value judgment, authorization, challenge windows, and private payout.

Writing Standards

Good docs contributions are precise, source-linked, and conservative. Use English technical content. Keep index.md files frontmatter-only. Put body explanations in child pages. Use the current mdi:alphabet-*-box-outline icon contract. Add Read Next and evidence sections to non-index docs pages. Cite whitepaper sections for architecture claims and local repo files for implementation claims. Do not use old drafts to widen current authority.

Review Loop

Large contributions should include a review loop: inspect source authority, apply the change, run local verification, scan for overclaims, and update any planning or summary evidence if the change belongs to a GSD phase. If the change affects security or support, include no-secret and disclosure-boundary checks. If it affects useful-work framing, include evidence and challengeability checks rather than reward slogans.

What Not To Contribute Publicly

Do not contribute live exploit details, private keys, seed phrases, decrypted wallet exports, personal data, or third-party confidential material through public channels. Do not add fake commands, fake API examples, or unsupported product promises. Do not turn target architecture into present-tense deployment. The project is better served by a smaller accurate contribution than by a broad impressive one that weakens trust boundaries.

Review Notes

Contribution pages should make quality cheaper than volume. A small correction with a source and passing verification is better than a large rewrite that weakens maturity language. A useful example should run locally or clearly label itself conceptual. A security contribution should choose the disclosure path before publishing details. A useful-work contribution should preserve evidence and challengeability.

Reviewers should reject contributions that create parallel documentation authority. If a page needs a new claim, update the owning source or cite it correctly. If a contribution adds a new route, update metadata and search expectations. If it changes support behavior, re-check wallet and disclosure safety.

Final Boundary

Contributions should reduce future ambiguity. A good change leaves behind a clearer source path, safer wording, stronger verification, or a narrower trust boundary. If a change creates a new claim that future reviewers cannot verify, it should be revised before it is celebrated.

Contribution channels are also public trust surfaces. Keep sensitive findings out of normal contribution threads, and keep unsupported product language out of ordinary docs improvements, even when the proposed text sounds helpful or urgent.

Small verified changes are preferred.

Evidence should travel with every change.

Read Next

Read Developer Support for repo help, Responsible Disclosure before submitting sensitive security material, and Proof Of Useful Work before framing contribution rewards.

Evidence and Further Reading

• README.md, package.json, and scripts/verify.sh define the local contribution and validation flow referenced on this page.
• .github/copilot-instructions.md, .github/skills/, and .github/requirements/Z00Z_WEB_DESIGN_FOUNDATION.md contain the repo-local editing, backup, design, skill, and verification rules contributors are expected to follow.
• Main Whitepaper sections 10 and 12 explain why public wording and maturity discipline are core contribution concerns rather than optional polish.
• Legal Architecture Whitepaper sections 4, 17, and Appendix A define the role boundaries and safe public-claim formulas that contribution reviews should preserve.
• Proof-of-Useful-Work Whitepaper sections 3 through 8 and section 11 reinforce the evidence-first contribution mindset: work should be reviewable, scoped, and challengeable rather than justified by enthusiasm alone.
• DAO Whitepaper sections 7 through 9 anchor AI-assisted review, private rewards, challenges, bonds, and failure handling for contribution-related governance claims.