Thank you for your interest in contributing. WorkProof is an open specification and community input is essential to making it good.
Open a GitHub Discussion. This is the right place for: "why does the spec do X?", "what's the intended behaviour of Y?", and "I'm implementing Z, is this correct?"
Open a GitHub Issue. Label it spec-bug if the spec is
internally inconsistent or ambiguous, typo for editorial errors.
- Open a Discussion first — schema changes need community input before a PR makes sense
- Once there's rough consensus in the Discussion, open a PR referencing it
- Schema changes to v0.x are fair game; changes that would break v1.0 compatibility require stronger justification
PRs welcome without prior Discussion. Good examples are always needed.
- Real implementation experience: "I implemented WorkProof and found that X was ambiguous" is extremely valuable
- Evidence model feedback: are the weight ranges reasonable? Are there evidence types missing?
- Attestation format: feedback from anyone with W3C VC implementation experience
- Consent gate: is L0–L4 the right granularity? What's missing?
- Full protocol rewrites
- Competing schema proposals without working implementations
- Bike-shedding on field names without substantive reasoning
Be direct. Be honest. Be kind. Spec work benefits from disagreement expressed clearly and without personal attack.