Documentation Governance
Ownership
Assign one product owner and one engineering reviewer for each app. Legal pages must also have an authorized business/legal approver.
Source-of-truth order
When documents disagree, resolve the conflict in this order:
- The exact production source and manifest.
- Verified production behavior on a Jira Cloud test site.
- Customer documentation.
- Marketplace listing copy and Privacy/Security answers.
- Public legal pages.
- Historical ADRs, work logs, and old submission drafts.
Historical notes explain why a decision was made; they do not override the current build.
Changes that require documentation review
A pull request must trigger a documentation and privacy review when it changes:
- Forge modules or scopes;
asUser versus asApp access;- external egress, analytics, or remote services;
- KVS, SQL, object store, caching, or record schemas;
- logging fields or debug behavior;
- license state or plan limits;
- issue-field types read or written;
- exported data or export limits;
- support contacts, legal URLs, or retention behavior.
Release evidence
For every Marketplace release, retain:
- source commit SHA;
- manifest and
forge lint output;
- test and clean-build results;
- screenshots of Free/Paid behavior where applicable;
- production log samples with sensitive values removed;
- stored-data schema review;
- submitted Marketplace privacy answers;
- link-check results for documentation, support, privacy, and terms.
Writing rules
- State product limits as exact numbers when they are fixed in code.
- Distinguish “not stored” from “not logged” and from “not sent outside Atlassian”.
- Never say “Totesoft cannot access” when authorized Totesoft developers can access Forge logs.
- Never describe a diagnostic tail as an audit log.
- Explain partial datasets wherever totals or aggregates may be incomplete.
- Keep internal remediation notes out of public customer pages.