Contribute to Y2
Share useful briefings, report problems, propose documentation fixes, and build integrations safely
Choose the contribution path that matches what you want to improve. Product and documentation feedback goes to Y2; public briefing profiles are published inside the application; code changes belong in the repository that owns the relevant SDK or tool.
Choose a contribution path
| Your goal | Use this path | What to include |
|---|---|---|
| Publish a reusable briefing | Enable Share with Community on a workspace-owned profile | Clear topic, safe public instructions, useful tags, and reviewed output |
| Report a product or documentation problem | Use PostHog Support in the desktop app or email [email protected] | Route or docs URL, expected result, actual result, and reproduction details |
| Report unsafe or inaccurate public content | Email [email protected] | Profile name or URL, the specific concern, and supporting context |
| Build an integration | Use the OpenAPI contract, API keys, and webhooks | Least-privilege scopes, signature verification, retries, and idempotency |
| Change an SDK or CLI | Follow the contribution and license terms in that tool's own repository | Focused change, matching tests, documentation, and compatibility notes |
Publish a community briefing
Community sharing is the only in-product publication path documented here. It makes the original profile and its later reports discoverable to other signed-in Y2 users; it does not submit the profile to a review queue.
Prepare a focused profile
Use a clear name, topic, report structure, and compact set of tags. Generate and review at least one report before asking others to rely on it.
Remove private context
Review the custom instructions, sources, sections, and generated output. Remove credentials, customer data, internal names, and confidential research requirements.
Enable sharing
Open Advanced Configuration, enable Share with Community, and save the profile.
Verify the public result
Open InfoOps → Discover, search for the profile, and inspect its details as a reader would.
See Share a Profile for the complete visibility and subscriber model.
Report a product or documentation problem
The desktop application loads PostHog Support when analytics consent is enabled. The widget is hidden on mobile and while Copilot is open. Email [email protected] when the widget is unavailable or the report needs a private channel.
A useful report contains:
- The application route or documentation URL.
- The active workspace type and plan when the behavior is entitlement-related.
- A short, repeatable sequence of actions.
- The expected and actual result.
- Relevant timestamps, request IDs, HTTP status codes, or screenshots.
- Whether the issue is consistent or intermittent.
For a documentation correction, quote only the smallest inaccurate statement and point to the current UI, API response, or other evidence that contradicts it.
Keep secrets out of reports
Never include API keys, webhook signing secrets, one-time authentication codes, payment details, or unredacted personal data. Redact authorization headers and sensitive payload fields before attaching logs or screenshots.
Report a security concern privately
Send a security concern to [email protected]. Include the affected surface, impact, reproduction conditions, and a safe proof of concept. Do not publish exploit details, credentials, or another workspace's data in a community profile or public issue.
Y2's local product repository does not define a separate public security-policy file, so this page does not promise a public issue tracker, bounty, response time, or disclosure schedule.
Build an integration
Use the documented API contract rather than depending on application internals.
OpenAPI contract
Generate clients from the same specification used by the endpoint reference
Authentication
Create tenant-scoped keys and grant only the required scopes
Webhook delivery
Verify signatures and design receivers for retries and duplicate delivery
Integration recipes
Start from task-oriented API patterns
There is no documented public integration marketplace or automatic submission process in the current application. Contact support before presenting an integration as endorsed by Y2.
Work on an SDK or CLI
The SDK pages link to their current source and package locations. Before changing a tool, open its own repository and verify its README, contribution instructions, tests, release process, and license. Those repository-local rules take precedence over this general guide.
TypeScript client
Review the TypeScript package, examples, and linked source repository
Python client
Review the Python package, examples, and linked source repository
Command-line client
Review CLI installation, commands, and linked source repository
Licenses are artifact-specific
The Y2 platform repository identifies itself as proprietary, and the API contract uses proprietary terms. Do not assume that the platform, documentation, examples, and external SDK repositories share one license. Check the license attached to the exact artifact you plan to use or modify.
Contribution checklist
- Keep the change focused on one user problem.
- Verify examples against the current API contract or application behavior.
- Include tests when the target repository has a test suite.
- Update the documentation affected by a behavior or interface change.
- Avoid promising badges, editorial review, promotion, credits, or response times unless Y2 has confirmed them for the specific contribution.
- Use @y2_intel on X for public updates; use support channels for actionable reports.