Docs ownership

Product engineering teams are responsible for writing docs and ensuring they are up-to-date. This means:

• Documenting new features when they're launched
• Reviewing and merging docs PRs generated by Inkeep when your monorepo PRs are merged
• Add doc comments to SDKs to make them easier to understand
• Clarifying documentation where needed based on support tickets
• Ensuring public betas have docs that are linked to from the feature preview menu

Read writing docs as an engineer – it's really important!

The is responsible for improving the docs. This means:

• Building tools and systems to improve baseline quality and structure
• Shipping docs content based on prioritized feedback and emerging use cases
• Reviewing and improving draft documentation created by product teams
• Improving the subjective docs experience (navigation, discovery, interactivity, etc.)
• Creating context services that power agents like the AI wizard
• Working on large scale docs projects

Ownership within the Wizard & Docs team

We've previously assigned ownership to areas of the PostHog platform and product docs to individuals, but we're presently more project orientated.

You can view what we're working on right now by:

1. Reading our goals on the page
2. Dropping in on our #team-wizard-and-docs Slack channel

You can share ideas / requests for new docs in the #team-wizard-and-docs Slack channel, or by creating an issue on the posthog.com repo.

As ever, though, PRs > issues. ;)

Sources for inspiration

There are lots of places you can go to find inspiration for what to work on during your stint, such as:

• community questions
• open issues on our project board
• feedback in #brand-mentions
• #docs-feedback
• #content-docs-ideas
• #ask-max for questions missing content
• Inkeep chat sessions where there is a documentation gap
• Most unhelpful docs
• Most popular docs
• that annoying thing you saw that you keep meaning to go fix

FAQ

I'm really busy, can the team write docs for me?

We can help, but we can't do it all for you. We lack the context necessary to document new features. First drafts of documentation must always come from the relevant product team.

If you need help updating documentation:

• Write a draft that covers the basics, which the content team can then help review and polish.
• If multiple docs pages need updating, create an example of changes needed and then request help to complete the rest.

Bottom line: It's much easier for the content team to improve a draft than write completely new documentation, especially when documenting new features. Pull requests > Issues.

Who should review docs updates?

Tag the docs reviewers team on GitHub and someone will come running.

How do I add images to my docs?

If you need to add images to your docs, please upload them to Cloudinary first and then embed them into the document.

You can embed light mode and dark mode versions of the image using this code snippet:

<ProductScreenshot
  imageLight = "https://res.cloudinary.com/dmukukwp6/image/upload/add_holdout_light_ce0827be42.png"
  imageDark = "https://res.cloudinary.com/dmukukwp6/image/upload/add_holdout_dark_cc687f7688.png"
  classes="rounded"
  alt="Screenshot of the form to create a new holdout"
/>