41 lines
2.4 KiB
Markdown
41 lines
2.4 KiB
Markdown
# Contributing
|
|
|
|
Explain the observed problem and the proposed behavior in an issue or pull request.
|
|
Include a small authored fixture that reproduces a correctness or security failure.
|
|
Keep each module focused, preserve existing Rust style and run `bash scripts/check.sh`
|
|
after `cargo fetch --locked`. Changes to contracts or normalization need a documented
|
|
migration and proof that stale approvals cannot silently survive changed evidence.
|
|
|
|
## Code and dependency changes
|
|
|
|
Submit code you are authorized to contribute under AGPL-3.0-or-later. Preserve
|
|
copyright/license notices for reused material and identify its origin. Do not
|
|
submit private datasets, credentials, signing keys, production configuration or
|
|
real user query logs. Synthetic fixtures should say that they are synthetic.
|
|
|
|
Dependency changes must include the lockfile diff, reason, source/license review
|
|
and complete offline gates. Keep builds practical on limited CPU and memory.
|
|
Do not replace an existing algorithm or lower a threshold simply to pass a test.
|
|
|
|
## Source adapters and website corrections
|
|
|
|
A new source requires primary documentation of commercial reuse rights, exact
|
|
consumed fields, required attribution, documented current format and distribution
|
|
URLs. Add a common-interface adapter, bounded streaming/resume behavior, input
|
|
validation and adversarial fixtures. Update LICENSE_SOURCES and attribution before
|
|
acceptance. An attractive dataset with unverified terms is not admissible.
|
|
|
|
For a website correction, include the entity ID, exact URL, relation/role, country
|
|
or locale scope, source record/revision, conflicting claims and dated immutable
|
|
evidence. Explain how the evidence supports identity and scope. Popularity, TLS,
|
|
hostname resemblance and an unauthenticated ownership claim are insufficient alone.
|
|
Do not include executable HTML, authenticated sessions or unnecessary personal data.
|
|
|
|
Submissions are proposals. The software repository does not contain a production
|
|
approval log or publisher keys. A publisher must independently review evidence,
|
|
append an expiring decision, build and inspect the candidate, then sign and activate
|
|
it under its own trust policy. Source changes cannot silently renew an approval.
|
|
|
|
Disclose relevant ownership or commercial conflicts. A reviewer should not approve
|
|
their own disputed website claim. Explain disagreements with evidence; preserve
|
|
prior decisions and corrections. Report exploitable failures through SECURITY.md.
|