yindo/posthog.com
1
0
Fork 0
mirror of https://github.com/BillyOutlast/posthog.com.git synced 2026-02-04 03:11:21 +01:00
Code Issues Packages Projects Releases Wiki Activity

Sentence case titles (#1321)

Browse Source 
* Changed Branding to sentence case

* Changed Communication to sentence case

* Changed Security to sentence case

* Delete standups.md

* Changed Working with Design to sentence case

* Changed Common issues to sentence case

* Changed Development process to sentence case

* Changed Setting up EE to sentence case

* Changed Onboarding customers to sentence case

* Changed Release new version to sentence case

* Changed Releasing Python to sentence case

* Changed Demos to sentence case

* Changed Sales Ops to sentence case

* Changed YC onboarding to sentence case

* Changed Growth strategy to sentence case

* Changed Benefits to sentence case

* Converted Compensation page to sentence case

* Converted Hiring process page to sentence case

* Converted Offboarding page to sentence case

* Converted Onboarding page to sentence case

* Converted side gigs page to sentence case

* Converted spending money page to sentence case

* Converted Team page to sentence case

* Converted Time off page to sentence case

* Update business-model.md

* Delete investor-updates.md

* Update strategy.md

* Update STYLEGUIDE

Change to sentence case for titles

* remove duplicate Strategy menu, only link Investors from Company section

* fix a bunch of stragglers

* even more Sentence Case stragglers!

Co-authored-by: Cory Watilo <corywatilo@gmail.com>
This commit is contained in:
Charles Cook
2021-05-12 15:20:33 +01:00
committed by GitHub
parent 455aff26e7
commit b61e6681e4
45 changed files with 221 additions and 330 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
STYLEGUIDE.md
View File

@@ -1,4 +1,4 @@
# Documentation Style Guide
# Documentation style guide
## Purpose
@@ -10,7 +10,7 @@ Hence, this guide aims to provide some basic guidelines for those wishing to con
## Guidelines
### Golden Rule: Assume Nothing (Almost)
### Golden rule: assume (almost) nothing
Assume as little as possible about your reader regarding the topic at hand. Whenever possible, you should provide links to other Docs and pages which describe how to download, update, and debug certain tools, so that your reader can easily solve an issue without having to go out searching on their own.
@@ -18,7 +18,7 @@ Regarding this point, there is a tradeoff. You do not want your text to get too
It is dangerous to assume that because something is obvious to you, it will also be obvious to your reader - just keep that in mind.
### Additional Suggestions
### Additional suggestions
**Use American English**
@@ -38,11 +38,9 @@ Example: Write "URLs", not "urls".
On another note, try to avoid acronyms unless they're so common that it's weird not to. For example, Hyper Text Transfer Protocol is a weird way to say HTTP.
**Capitalize every word in a title (except for prepositions)**
**Use sentence case for titles**
Example: Write "Documentation Style Guide" instead of "Documentation style guide".
"Style Guide **for** Documentation" is fine, however.
Example: Write "Documentation style guide" instead of "Documentation Style Guide".
**Adhere to the style standards of each programming language**
@@ -50,7 +48,7 @@ In code snippets, you should follow the conventions of the language the code is
Example: Use `camelCase` for JavaScript, and `snake_case` for Python variables names.
**Where there is a Call to Action, always provide a link**
**Where there is a call to action, always provide a link**
When you write: "You can contact us to learn more", make sure to provide the reader with the means to do so immediately. This could be a link to another page or an email address, for example.

46
contents/handbook/company/branding.md
View File

@@ -10,7 +10,7 @@ showTitle: true
## Resources
#### Figma: PostHog Branding
#### Figma: PostHog branding
Refer to this [Figma Project](https://www.figma.com/file/8iM3Damgbl4PyHq6x8JJbu/PostHog-Branding?node-id=1%3A661) for a comprehensive overview of our colors, fonts, logos, and related resources.
@@ -50,7 +50,7 @@ If possible, all artwork is to be made with these colours, as well as typography
# H1
###### Font Specifications
###### Font specifications
* Family: Gosha Sans (Regular)
* Size: 64px
@@ -60,7 +60,7 @@ If possible, all artwork is to be made with these colours, as well as typography
## H2
###### Font Specifications
###### Font specifications
* Family: Gosha Sans (Regular)
* Size: 48px
@@ -70,7 +70,7 @@ If possible, all artwork is to be made with these colours, as well as typography
### H3
###### Font Specifications
###### Font specifications
* Family: Gosha Sans (Regular)
* Size: 36px
@@ -80,7 +80,7 @@ If possible, all artwork is to be made with these colours, as well as typography
#### H4
###### Font Specifications
###### Font specifications
* Family: Gosha Sans (Regular)
* Size: 30px
@@ -90,7 +90,7 @@ If possible, all artwork is to be made with these colours, as well as typography
##### H5
###### Font Specifications
###### Font specifications
* Family: Gosha Sans (Regular)
* Size: 20px
@@ -100,7 +100,7 @@ If possible, all artwork is to be made with these colours, as well as typography
###### H6
###### Font Specifications
###### Font specifications
* Family: Gosha Sans (Regular)
* Size: 18px
@@ -108,9 +108,9 @@ If possible, all artwork is to be made with these colours, as well as typography
* Color: Black
* Opacity: 100%
#### Normal Text
#### Normal text
###### Font Specifications
###### Font specifications
* Family: Gosha Sans (Regular)
* Size: 16px
@@ -118,9 +118,9 @@ If possible, all artwork is to be made with these colours, as well as typography
* Color: Black
* Opacity: 100%
#### Small Text
#### Small text
###### Font Specifications
###### Font specifications
* Family: Gosha Sans (Regular)
* Size: 16px
@@ -138,7 +138,7 @@ The color of text should always be black - with the occasional lowered opacity t
For numbers you have two options, the first being *statement* and the second being *subtle*.
#### Statement Numbers
#### Statement numbers
Statement numbers tend to be used on the landing page or pages where the product is being explained. Usually accompanied by visuals and a small amount of text.
@@ -146,7 +146,7 @@ Statement numbers tend to be used on the landing page or pages where the product
Statement No. Gosha Sans, bold, size 64px, colour - Blue (#1D4AFF), Orange (#F54E00), Yellow (#F9BD2B) alternating, opacity 100%.
#### Subtle Numbers
#### Subtle numbers
Subtle numbers are seen within docs and blogs, usually employed to give instructions or list things.
@@ -180,7 +180,7 @@ On the landing page the dividers alternate between the three PostHog colours, Bl
These dividers should be 35px below H2 text, and any body copy text below should be 35px from the divider.
## Background Textures and Color
## Background textures and color
To stop the website from looking dull we have employed the use of color and texture to give it some depth.
@@ -190,7 +190,7 @@ Color blocks can be any size, but they must not fill more than one third of the
On top of the color blocks (or on its own) you could also use the halftone grey panel on opacity 20%. This gives the page some texture without distracting the USER from the text.
## Menus and Sidebars
## Menus and sidebars
Most of the menus on PostHog will be in tones of grey with pops of color for clicked pages. The most common menu featured on the bottom of the website page holds 5 sections for users to navigate the website. This menu is Mid Grey (#BEBEBE), and its size is 315px in height, while occupying the entire length of the screen in width.
@@ -212,7 +212,7 @@ Alongside the text on the left is a line with a small circle to indicate the par
Depending on what section of the text you are reading, the text will turn orange and the circle will be aligned with that selected text.
## Mobile Content
## Mobile content
When transforming any desktop page to mobile please use the iPhone 8 frame on Figma.
@@ -224,7 +224,7 @@ The header consists of the logo (206 W x 40.13 H) centered, a menu bar (36 W x 3
#### H1
###### Font Specifications
###### Font specifications
* Family: Gosha Sans (Regular)
* Size: 18px
@@ -234,7 +234,7 @@ The header consists of the logo (206 W x 40.13 H) centered, a menu bar (36 W x 3
#### H2
###### Font Specifications
###### Font specifications
* Family: Gosha Sans (Regular)
* Size: 14px
@@ -244,7 +244,7 @@ The header consists of the logo (206 W x 40.13 H) centered, a menu bar (36 W x 3
#### H3
###### Font Specifications
###### Font specifications
* Family: Gosha Sans (Regular)
* Size: 12px
@@ -254,7 +254,7 @@ The header consists of the logo (206 W x 40.13 H) centered, a menu bar (36 W x 3
#### H4
###### Font Specifications
###### Font specifications
* Family: Gosha Sans (Regular)
* Size: 10px
@@ -266,15 +266,15 @@ The header consists of the logo (206 W x 40.13 H) centered, a menu bar (36 W x 3
Follows the same principles as the Desktop format, using Statement and Subtle numbers.
**Statement Numbers**
**Statement numbers**
Gosha Sans | Regular | Size 20 | Line Height 20 | Color: Yellow, Orange, or Blue | Opacity: 100%
**Subtle Numbers**
**Subtle numbers**
Helvetica Neue | Bold | Size 14 | Line Height 20 | Color: Yellow | Opacity: 100%
## Shapes and Dividers
## Shapes and dividers
Curved rectangle backgrounds, size (203 W x 170 H), with a curved radius of 20, in either Yellow (#F9BD2B), Orange (#F96132), or Navy (#35416B). These can be overlaid with halftone dots, at 20% pass through.

17
contents/handbook/company/communication.md
View File

@@ -10,7 +10,7 @@ With team members across several countries, it's important for us to practice cl
To accomplish this, we use **asynchronous communication as a starting point** and stay as open and transparent as we can by communicating on GitHub through public issues and pull requests, as well as in our PostHog User and internal Slack.
## Our Communication Values
## Our communication values
1. **Assume Positive Intent.** Always coming from a position of positivity and grace.
1. **Form An Opinion.** We live in different locations and often have very different perspectives. We want to know your thoughts, opinions, and feelings on things.
@@ -84,11 +84,11 @@ Please be sure to read the README of the repo for guidelines on how to file spec
- ❌ Any internal information that does not fall under the scope of purely engineering, product, growth or design. This should go in the [Company Internal](#company-internal) repo.
- ❌ Bug reports that don't contain any PII or where the PII only contains supporting information. In this case, file the bug under the relevant public repo and add a protected link to the additional information (e.g. a private Slack link, or a link to this repo).
## Written Communication
## Written communication
### GitHub
#### Everything Starts with a Pull Request
#### Everything starts with a pull request
It's best practice to start a discussion where possible with a Pull Request (PR) instead of an issue. A PR is associated with a specific change that is proposed and transparent for everyone to review and openly discuss. The nature of PRs facilitate discussions around a proposed solution to a problem that is actionable. A PR is actionable, while an issue will inevitably lead to a longer period before the problem is addressed.
@@ -128,9 +128,9 @@ Slack is used differently in different organizations. Here are some guidelines f
1. Make use of threads when responding to a post. This allows informal discussion to take place without notifications being sent to everyone in the channel on every reply.
1. When possible, summarize multiple thoughts into a single message instead of sending multiple messages sequentially.
### Google Docs and presentations
### Google Docs and Slides
Never use a Google Doc / presentation for something non-confidential that has to end up on the website or this handbook. Work on these edits via commits to a pull request. Then link to the pull request or diff to present the change to people. This prevents a duplication of effort and/or an out of date handbook.
Never use a Google Doc / Slides for something non-confidential that has to end up on the website or this handbook. Work on these edits via commits to a pull request. Then link to the pull request or diff to present the change to people. This prevents a duplication of effort and/or an out of date handbook.
We mainly use Google Docs to capture internal information like meeting notes or to share company updates and metrics. We always make the doc accessible so you can comment and ask questions.
@@ -144,14 +144,15 @@ Please avoid using presentations for internal use. They are a poor substitute fo
- Sending some types of more official company documents (e.g. job offers, payroll forms)
- Communicating with external partners
### Writing Style
### Writing style
1. We use American English as the standard written language in our public-facing comms, including this handbook.
1. Do not use acronyms when you can avoid them. Acronyms have the effect of excluding people from the conversation if they are not familiar with a particular term.
1. We use the [Oxford comma](https://www.grammarly.com/blog/what-is-the-oxford-comma-and-why-do-people-care-so-much-about-it/).
1. Do not create links like "here" or "click here". All links should have relevant anchor text that describes what they link to. Using meaningful links is important to both search engine crawlers (SEO) and people with accessibility issues.
1. We use sentence case for titles.
## Internal Meetings
## Internal meetings
PostHog uses [Zoom](https://zoom.us/) for video communications. Zoom also has useful plugins for [Google Calendar](https://chrome.google.com/webstore/detail/zoom-scheduler/kgjfgplpablkjnlkjmjdecgdpfankdle?hl=en-US) and Slack which you may wish to use.
@@ -170,7 +171,7 @@ Use video calls if you find yourself going back and forth in an issue/via email
For external meetings, the above is also helpful. We also have separate guidance on [how to run a great demo](/handbook/growth/sales/demos).
### Indicating Availability
### Indicating availability
1. Put your planned away time including holidays, vacation, travel time, and other leave in your own calendar.
1. Set your working hours in your Google Calendar - you can do this under _Settings_ > _Working Hours_. This is helpful as we work across different timezones.

2
contents/handbook/company/diversity.md
View File

@@ -1,5 +1,5 @@
---
title: Diversity and Inclusion
title: Diversity and inclusion
sidebar: Handbook
showTitle: true
---

2
contents/handbook/company/management.md
View File

@@ -57,7 +57,7 @@ That's why it's important for managers to keep practising their craft.
Management tasks do come first, as giving context to your team tends to have a multiplying effect vs getting one more PR out. After that though, it's back to work.
## Anti silos
## Anti-silos
There are teams at PostHog that need to work across functions, so we have an anti-silo approach when it comes to the tasks that people work on.

8
contents/handbook/company/security.md
View File

@@ -6,16 +6,16 @@ showTitle: true
It is critical that everyone in the PostHog team follows these guidelines. We take people not following these rules very seriously - it can put the entire company and all of our users at risk if you do not.
## Password Managers
## Password managers
You **must** make use of a password manager; it simply isn't possible to use appropriate passwords securely without one.
PostHog uses [1password](https://1password.com/) for storing all passwords.
## Password Strength
## Password strength
Please use strong passwords for everything. Use the 1password password generator that comes with the app in all cases. Do not repeat passwords across different sites.
## Dual Factor Authentication
## Two-factor authentication
You should enable dual factor authentication for any account where the option is available, especially those which are core to your work.
You should enable two-factor authentication for any account where the option is available, especially those which are core to your work.

35
contents/handbook/company/standups.md
View File

@@ -1,35 +0,0 @@
---
title: Daily Standups
sidebar: Handbook
showTitle: true
---
While we default to [written and asynchronous communication](/handbook/company/communication), we find that having a few regular touch points for the whole team to come together on a call useful for sharing certain types of information, strengthening our culture and discussing more dynamic issues in real time.
We keep these minimal in terms of time expectation - no more than 2hrs total per week. They are usually scheduled around 8.30am PDT/4.30pm GMT to allow people across multiple timezones to attend more easily.
You should have been invited to our regular standups as part of your [onboarding](/handbook/people/onboarding).
## Daily Standup Schedule
- **Monday** - PostHog News. Members of the team share company-wide updates about things like recruitment, product metrics and commercial performance. The content of these meetings is always confidential. We then go around the team and each person summarises what they did last week and what they plan to do this week.
- **Tuesday** - No standup (we keep Tuesdays meeting-free).
- **Wednesday** - Anyone can propose to have a meeting about any topic. Stuck with a technical problem? Want to get feedback on something? Want to brainstorm? Schedule those meetings during this timeslot and advertise in Slack.
- **Thursday** - No standup (we keep Thursday meeting-free).
- **Friday** - These alternate between Sprint Planning and Life Stories.
### Sprint Planning
This is a longer 45min meeting every other Friday where we review the previous two week sprint and then outline what we want to achieve in the next 2 weeks. We split into Engineering and Not Engineering teams for this, but schedule the meetings sequentially so that anyone can sit in on both if they would like to.
You will be asked to add your comments to the relevant GitHub planning issue in advance of each meeting on Slack the day before.
### Life Stories
Alternating with Sprint Planning, Life Stories we hear from 1-2 members of the team who share a bit about themselves with us. No particular format - it's one of the few times a presentation makes sense! Each team member has up to 30min, inclusive of Q&A. These are a fun opportunity for us to get to know a bit about the people we work with, what cool things we didn't know about them, and whether or not they believe that pineapple belongs on pizza...
## Standup Bot
Outside of the above meeting schedule, we still write up our tasks in a standard format in Slack - you will be prompted by Standup Bot. You will be asked what you did since the last standup, what you plan to do before the next one, and any issues or blockers you might have.
This means that everyone still has visibility and context for what everyone else is working on, but delivered in a format that is quick to digest and easier to respond to. We don't do this on meeting-free Tuesdays and Thursday, to minimise interruptions.

10
contents/handbook/company/working-with-design.md
View File

@@ -6,7 +6,7 @@ showTitle: true
Design is currently a shared resource at PostHog. This explains what we do, our design process, and how we can assist across the PostHog team.
## Design's Role at PostHog
## Design's role at PostHog
1. Support Small Teams (and contributors) in building better versions of PostHog
1. Enable customers to build better products (using PostHog)
@@ -18,7 +18,7 @@ Design is currently a shared resource at PostHog. This explains what we do, our
1. Support Small Teams in completing their sprint tasks
1. Iterate based on feedback from customers
## Our Process
## Our process
Design tasks are managed with our [GitHub Org project](https://github.com/orgs/PostHog/projects/3), otherwise known as our Design Board. This aggregates design-related tasks from the main three repositories for the company:
@@ -26,7 +26,7 @@ Design tasks are managed with our [GitHub Org project](https://github.com/orgs/P
1. [posthog.com](https://github.com/PostHog/posthog.com) - website + docs
1. Internal - higher-level company strategy
### How Our Design Board Works
### How our Design Board works
Cards generally move from left to right.
@@ -36,7 +36,7 @@ Cards generally move from left to right.
1. **Awaiting implementation** - In development or in review
1. **Done** - Shipped! 🚀
## Design Request Process
## Design request process
Since design is currently a shared resource, the best way design requests can be handled is by creating an issue in the relevant repository, then adding to the _Design_ project.
@@ -51,7 +51,7 @@ The following details will help us triage incoming requests:
**Note:** We may defer some design requests if we're planning a larger overhaul in the near term. For example, if a request is to create an icon, we may suggest an alternate solution (like pulling an icon from The Noun Project) if we have a larger plan for revamping all icons in a section in the near future.
### When to Loop in Design
### When to loop in design
Because we hire self-starters, there is no expectation that every project should start by running through design _first_.

2
contents/handbook/engineering/bug-prioritization.md
View File

@@ -1,5 +1,5 @@
---
title: Bug Prioritization
title: Bug prioritization
sidebar: Handbook
showTitle: true
---

6
contents/handbook/engineering/common-issues.md
View File

@@ -1,13 +1,13 @@
---
title: Common Issues
title: Common issues
sidebar: Handbook
showTitle: true
---
A page to host big issues raised by users (rather than small bugs) that we have certain answers for.
### Shopify Event-Logging "Bug"
### Shopify event-logging "bug"
Admin users who have PostHog setup for Shopify may experience their events being logged for another user.
This is not an issue with PostHog. Rather, this is due to a feature Shopify offers where it stores all the session data and lets you browse your website as if you were your client with all their cookies and local/session storage.
This is not an issue with PostHog. Rather, this is due to a feature Shopify offers where it stores all the session data and lets you browse your website as if you were your client with all their cookies and local/session storage.

14
contents/handbook/engineering/development-process.md
View File

@@ -1,5 +1,5 @@
---
title: Development Process
title: Development process
sidebar: Handbook
showTitle: true
---
@@ -13,7 +13,7 @@ Any process is a balance between speed and control. If we have a long process th
However, if we have no checks in place, we will release quickly but everything will be broken.
## 1. How to Decide What to Build
## 1. How to decide what to build
There are 3 places that work comes from.
@@ -22,13 +22,13 @@ There are 3 places that work comes from.
- "This should be better"
## 2. Sizing a Task
## 2. Sizing a task
When picking up a task, it should be doable in a day, including code review and QA. If it's not, you need to break it down into smaller chunks until it is. Tasks of this size are easy to test, easy to deploy, less likely to cause merge conflicts, and should still deliver some kind of value.
Even if you're contributing, this is helpful as it means you'll be able to contribute to PostHog faster.
## 3. Writing Code
## 3. Writing code
We're big fans of Test Driven Development (TDD). We've tried to create test infrastructure that helps you rather than annoys you. If that isn't the case, please raise an issue! Keeping tests on point is a high priority to keep developer productivity high.
@@ -42,7 +42,7 @@ To make sure our issues are linked correctly to the PRs, you can tag the issue i
git commit -m "Closes #289 add posthog logo to website"
```
## 5. Code Review
## 5. Code review
When we review a PR, we'll look at the following things:
- Does the PR actually solve the issue?
@@ -62,11 +62,11 @@ Merge anytime. Friday afternoon? Merge.
Our testing, reviewing and building process should be good enough that we're comfortable merging any time.
## How to Test
## How to test
See: [How to test](/docs/contributing#testing).
## How we Review
## How we review
See: [How we review](/handbook/engineering/how-we-review).

4
contents/handbook/engineering/how-we-review.md
View File

@@ -1,5 +1,5 @@
---
title: How We Review PRs
title: How we review PRs
sidebar: Handbook
showTitle: true
---
@@ -34,7 +34,7 @@ Almost all PRs made to PostHog repositories will need a review from another engi
The emphasis should be on getting something out quickly. Endless review cycles sap energy and enthusiasm.
## Setting up Heroku Test Environment
## Setting up Heroku test environment
1. Go to the pull request you want to QA on.
2. Go to the Heroku test environment.

2
contents/handbook/engineering/mdx.mdx
View File

@@ -1,5 +1,5 @@
---
title: Website MDX Setup
title: Website MDX setup
sidebar: Handbook
showTitle: true
---

4
contents/handbook/engineering/onboarding-customer.md
View File

@@ -1,5 +1,5 @@
---
title: Onboarding Customers
title: Onboarding customers
sidebar: Handbook
showTitle: true
---
@@ -10,7 +10,7 @@ Our user notes are not shared publicly. [Read them here](https://docs.google.com
A standard structure you could maintain while doing that call is:
## 1. Introductions / Find Out About Their Business
## 1. Introductions - find out about them
1. Make sure you introduce yourself and check it's ok if you take notes.
1. Introduce PostHog: "We're open-source product analytics. Think Mixpanel or Amplitude, but with full control over your data and focused on engineers"

4
contents/handbook/engineering/release-new-version.md
View File

@@ -1,12 +1,12 @@
---
title: Releasing a New Version
title: Releasing a new version
sidebar: Handbook
showTitle: true
---
At the moment, we release a new version every two weeks ([unless it makes sense not to!](/blog/we-ship-whenever)). This might change in the future.
## Version Numbers
## Version numbers
Every week we up the 'minor' in `major.minor.patch`. At the moment, we're at version 1 for major. This will only change once we have released sufficient functionality under stage 2 of [our Roadmap](/handbook/strategy/roadmap/).

6
contents/handbook/engineering/releasing-python.md
View File

@@ -1,12 +1,12 @@
---
title: Releasing a New Version (Python Library)
title: Releasing a new version (Python library)
sidebar: Handbook
showTitle: true
---
## How to Release
## How to release
1. Increase `VERSION` in `posthog/version.py`
2. Update `CHANGELOG.md` with a short summary of the changes
3. run `make release` and `make release_analytics`
4. `git commit -am "Release X.Y.Z."` (where X.Y.Z is the new version)
5. `git tag -a X.Y.Z -m "Version X.Y.Z"` (where X.Y.Z is the new version).
5. `git tag -a X.Y.Z -m "Version X.Y.Z"` (where X.Y.Z is the new version).

6
contents/handbook/getting-started/meetings.md
View File

@@ -20,13 +20,13 @@ You should have been invited to any relevant meetings as part of your [onboardin
- **Thursday** - Meeting-free - no internal meetings allowed.
- **Friday** - These alternate between Sprint Planning and Life Stories.
### Sprint Planning
### Sprint planning
This is a longer 45min meeting every other Friday where we review the previous two week sprint and then outline what we want to achieve in the next 2 weeks. We split into [small teams](/handbook/people/team-structure/team-structure) for this. Not all small teams follow this exact schedule, but you'll find they usually do these types of meetings on a Friday.
This is a longer 45min meeting every other Friday where we review the previous two week sprint and then outline what we want to achieve in the next 2 weeks. We split into [Small Teams](/handbook/people/team-structure/team-structure) for this. Not all small teams follow this exact schedule, but you'll find they usually do these types of meetings on a Friday.
All sprint planning meetings are open to anyone to attend - if you are not a member of that small team, then we ask that you sit in as a non-speaking observer only.
### Life Stories
### Life stories
Alternating with Sprint Planning, Life Stories we hear from 1-2 members of the team who share a bit about themselves with us. No particular format - it's one of the few times a presentation makes sense! Each team member has up to 30min, inclusive of Q&A. These are a fun opportunity for us to get to know a bit about the people we work with, what cool things we didn't know about them, and whether or not they believe that pineapple belongs on pizza...

2
contents/handbook/growth/customer-support.md
View File

@@ -1,5 +1,5 @@
---
title: Customer Support
title: Customer support
sidebar: Handbook
showTitle: true
---

4
contents/handbook/growth/marketing/releasing-content.md
View File

@@ -1,5 +1,5 @@
---
title: Releasing Content
title: Releasing content
sidebar: Handbook
showTitle: true
---
@@ -10,7 +10,7 @@ We aim to regularly publish content in the form of videos and articles as part o
As a result, we have formulated a loose strategy for how to approach publishing the content produced once it is ready to be exposed to the world.
#### Suggested Workflow
#### Suggested workflow
1. If the content requires a visual element, create a [design request](https://posthog.com/handbook/company/working-with-design) (more than 24 hours in advance) to have a graphic produced. For example, if the content is a YouTube video, we'll make a thumbnail image. If it's a blog post, we'll create a post image that is featured at the top of the post.
1. Make sure the content is actually live: If it is an article, ensure that the changes are reflected on the website following the merge of the pull request, which might take 10 to 30 minutes.

4
contents/handbook/growth/sales/demos.md
View File

@@ -4,11 +4,11 @@ sidebar: Handbook
showTitle: true
---
## Giving Great Demos
## Giving great demos
Always focus on delivering what the customer needs. Sometimes that will mean sending them to a competitor or turning them down.
### Initial Call
### Initial call
The purpose of this call is to work out what the potential customer needs.

4
contents/handbook/growth/sales/sales-operations.md
View File

@@ -1,10 +1,10 @@
---
title: Sales Operations
title: Sales operations
sidebar: Handbook
showTitle: true
---
## The Basics
## Overview
We use [HubSpot](https://www.hubspot.com/) as our customer relationship management ('CRM') platform. If you need access, you can ask Charles or James H and they will send you an invite to create an account. 

14
contents/handbook/growth/sales/yc-onboarding.md
View File

@@ -1,14 +1,14 @@
---
title: YC Onboarding
title: YC onboarding
sidebar: Handbook
showTitle: true
---
As a YCombinator company ourselves, we want to be supportive of other YC companies that want to use PostHog. As such, our onboarding process for YC companies is different and more extensive than our general process.
## The YC Deal
## The YC deal
Our YC Deal provides the following:
Our YC deal provides the following:
One free year of PostHog Cloud with up to 10 million events per month *or* a one-year enterprise license if they want to self-host PostHog.
@@ -22,9 +22,9 @@ For YC W21 companies, we also offer:
> **Note:** Batch-specific deals will be updated here as new batches come along.
## Onboarding Call
## Onboarding call
### Inbound Request Sources
### Inbound request sources
YC companies can reach out to us in many ways. Ideally we will steer them towards the [dedicated YC Onboarding page](/yc-onboarding), but they may also reach out to us on _yc@posthog.com_ or _ycdeal@posthog.com_ (as well as individual emails and _hey@posthog.com_).
@@ -42,7 +42,7 @@ Before the call, we recommend you sign up to our Cloud version and try your hand
If users come to the call with a ready instance, we can focus more on their needs and setting up relevant views for them than a basic overview of the platform that they could have gotten without us.
### The Demo
### The demo
When doing a demo of PostHog, you should prioritize using the following environments:
@@ -96,6 +96,6 @@ This is where we buy from, in descending order of preference:
When ordering from Apple, put in your email address as the main one for the order, and then add the user's email address under 'Share delivery updates' so they can easily track their order. For Allbirds, you will need to put in your email address and then just forward the receipt to the user for them to track. You should not just put in their email address for the order, as you won't then get a copy of the receipt for expenses.
## Current Responsibilities
## Current responsibilities
Yakko currently handles YC onboarding calls while Charles processes merch requests. Paolo is the point of contact for billing issues.

14
contents/handbook/growth/strategy.md
View File

@@ -1,12 +1,12 @@
---
title: Growth Strategy
title: Growth strategy
sidebar: Handbook
showTitle: true
---
<br />
##Self-serve
## Self-serve
We believe this approach will lead to the best product for end users, which is how we'll build the best company.
@@ -31,7 +31,7 @@ This means the path to revenue starts with adoption of a Free version, then work
As an individual, it is useful for organizing your own API creation activity.
In team mode, it is a way for multiple teams to organize distributed development effort. If you're building across multiple teams with different services, how you coordinate these teams is a big, strategic business problem. By using the same tool with modifications, you can orchestrate this.
In team mode, it is a way for multiple teams to organize distributed development effort. If you're building across multiple teams with different services, how you coordinate these teams is a big, strategic problem. By using the same tool with modifications, you can orchestrate this.
#### LaunchDarkly
@@ -70,13 +70,13 @@ As we grow, it'll get important to work out which teams in PostHog own different
<td>Customer Solutions Architect</td>
</tr>
<tr>
<td>Business Ops</td>
<td colspan="3" style="text-align: center;">Business Ops</td>
<td>Sales Ops</td>
<td colspan="3" style="text-align: center;">Sales Ops</td>
</tr>
</table>
Following the 1-2-3 framework, we are currently focused on building our team in the first and second columns - _Free_ and _Team_ - and already have Developer Experience and Business Ops people in place. Only after we have brought in people to take care of Marketing/Developer Evangelism and Customer Success will we then look at recruiting people into the roles in the third column, _Enterprise_.
Following the 1-2-3 framework, we are currently focused on building our team in the first and second columns - _Free_ and _Team_ - and already have Developer Experience and Sales Ops people in place. Only after we have brought in people to take care of Marketing/Developer Evangelism and Customer Success will we then look at recruiting people into the roles in the third column, _Enterprise_.
### Structure FAQ
@@ -94,6 +94,6 @@ Developer-evangelism is more about adoption of the first users - creating conten
Customer Success is a more commercially-oriented function, focused on inbound sales.
#### What are business ops?
#### What are sales ops?
It'll be important we have good processes in place to grow usage from free to team and beyond. This means making sure we have a CRM set up, integrated with our product, etc.

12
contents/handbook/people/benefits.md
View File

@@ -18,7 +18,7 @@ In the UK, we use [Royal London](https://www.royallondon.com/) as our pension pr
[Deel](https://app.letsdeel.com/), our international payroll provider, is currently building a pension product for contractors as well, due for release in Q2 2021. We will aim to provide the same percentages as in the UK.
### Private Health Insurance
### Private health insurance
We currently provide private health insurance in the US and UK.
@@ -28,7 +28,7 @@ PostHog pays 75% of the premium of the platinum plan, and you pay the other 25%.
In the UK, we use [Bupa](https://www.bupa.co.uk/) for private healthcare (£100 excess per policy year) and [Medicash](https://www.medicash.org/) as our cash plan for dental and vision. Children are included for free. Both of these are taxable benefits which will affect your Personal Allowance each tax year, and you can opt out at any time with 1 month notice.
### Mental Health Support
### Mental health support
We know that the world can feel a bit heavy from time to time and we want to make sure everyone gets support, if they need it.
@@ -36,23 +36,23 @@ We launched [Spill](https://www.spill.chat/) in March 2021 to give everyone in t
Spill is 100% free and confidential - they do not share any personal information with PostHog about who is using the service etc. The _only_ exception is if they believe that there is a threat to a person's safety or the safety of others.
### Unlimited Time off
### Unlimited time off
Everyone in the team has [unlimited, permissionless time off](/handbook/people/time-off). This means you won't need to ask for permission before requesting time off - our people platform [CharlieHR](https://posthog.charliehr.com/) will autoapprove your request.
We also offer generous [parental leave](/handbook/people/time-off#parental-leave) for new parents.
### Learning and Development
### Learning and development
We currently offer a [Training budget](/handbook/people/training#training-budget) and [free books](/handbook/people/training#books) - you can find more on the relevant pages.
### Equipment and Co-working
### Equipment and co-working
As we are fully remote, we provide [all equipment](/handbook/people/spending-money#equipment) you need to have an ergonomic setup at home to be as productive as possible. We provide all team members with a company card for this purpose.
If you ever need change of scenery, we offer $200/month budget towards [coworking or café working](/handbook/people/spending-money#work-space).
### Off-sites and Team Socials
### Off-sites and team socials
Ideally, we would like to meet up in person at twice a year. The team was able to meet up in Italy in September 2020, but we haven't been able to travel since, so we are planning a virtual off-site in April 2021 instead (and hopefully a real one on Autumn 2021!).

16
contents/handbook/people/compensation.mdx
View File

@@ -4,7 +4,7 @@ sidebar: Handbook
showTitle: true
---
## How it Works
## How it works
As we are a small (but growing!) startup, we've kept compensation simple.
@@ -21,7 +21,7 @@ Important:
For hiring into executive roles, we usually use a separate database of compensation benchmarks rather than this calculator. The terms of access to this database means that we're unfortunately not able to share it publicly.
### San Francisco Benchmark
### Benchmark
​
Our benchmark for each role we are hiring for is based on the market rate in San Francisco. We use a number of difference sources to gather salary data, this includes [Payscale](https://www.payscale.com/), [salary.com](https://www.salary.com/), reported salary on Glassdoor and LinkedIn, and other available sources. We try to have a data set that is as big as possible to reduce the margin for error and add a 1.2x multiplier to the median salary.
@@ -46,7 +46,7 @@ We pay more experienced team members a greater amount since it is reasonable to
We believe at first increased skill comes from more time spent in the role. Over time, this judgement becomes more subjective and is instead based on the speed with which you can ship or help the team to ship, the quality of your prioritization and decision-making, as well as your technical approach.
### Steps
### Step
Within each level, we believe there's a place to have incremental steps to allow for more flexibility. We define these as follows:
@@ -92,12 +92,12 @@ If you are uncertain about where you're travelling to in advance, and you are tr
​
If this represents an increase in pay from however much you were _most recently_ paid, _we need to approve this change in advance_ - we cannot guarantee it is always possible, as our budgets may or may not allow it.
## Salary Adjustments, Raises, and Promotions
## Salary adjustments, raises, and promotions
​
We do not expect to do any salary raises, adjustments or promotions until July 2021, outside of role or location-based changes. After that, we will run a bi-annual review cycle to evaluate which Level and Step you are at.
We run a bi-annual [performance review cycle](/handbook/people/feedback#performance-reviews) to evaluate which Level and Step you are at.
## Exchange Rate
## Exchange rate
Unless there is a very good reason, you'll be paid in your local currency. This means that you know exactly how much you'll get every month. The rates are from [OpenRates](https://openrates.io/) and were taken on *1st January 2021*. Every year we'll update the rates on the 1st of January.
@@ -105,9 +105,9 @@ Unless there is a very good reason, you'll be paid in your local currency. This
We are fully committed to ensuring that you are set up for success, but also understand that it may take some time to determine whether or not there is a long term fit between you and PostHog.
During the first 3 months of your employment, you can choose to end your contract with 1 week's notice. If we chose to end your contract, PostHog will give you 4 weeks notice. In both scenarios, we expect you to handover your work to the team, but you won't have to work the rest of your notice period.
During the first 3 months of your employment, you can choose to end your contract with 1 week's notice. If we chose to end your contract, PostHog will give you 4 weeks' notice. In both scenarios, we expect you to hand over your work to the team, but you won't have to work the rest of your notice period.
Your manager is responsible for monitoring and specifically reviewing your performance throughout the probation period. If under-performance is a concern, or if there is any hesitation regarding the future at PostHog, this should be discussed immediately with you and your manager.
Your manager is responsible for monitoring and specifically reviewing your performance throughout this initial period. If under-performance is a concern, or if there is any hesitation regarding the future at PostHog, this should be discussed immediately with you and your manager.
## Severance

6
contents/handbook/people/hiring-process.md
View File

@@ -1,12 +1,12 @@
---
title: Hiring Process
title: Hiring process
sidebar: Handbook
showTitle: true
---
This page will walk you through how we hire at PostHog. The goal is to have a lightweight process that optimizes for speed for the candidate, but above all for quality of the hire.
## Deciding to Hire
## Deciding to hire
Every hire introduces complexity to the organisation and increases our burn rate. As a result, we think very carefully about each new role, and we set an extremely high bar for the people that we do hire.
@@ -46,7 +46,7 @@ When you book, you have the option of selecting a Google Meet or Zoom call. You
Make sure you have set an agenda for the meeting in order to be welcoming to the candidate and to let the internal PostHog team member know what they need to cover in the meeting. The person who _books_ the meeting is responsible for setting the agenda.
## Our Hiring Process
## Our hiring process
The stages of our hiring process are:

20
contents/handbook/people/offboarding.md
View File

@@ -4,11 +4,11 @@ sidebar: Handbook
showTitle: true
---
Offboarding team members can be a sensitive time. The aim of this policy is to create transparency around how this process works.
Offboarding team members is a sensitive time. The aim of this policy is to create transparency around how this process works.
Very infrequently, we may have long term contractors working for PostHog, acting essentially like a permanent employee. In this case, the process below is exactly the same. This offboarding policy *does not* apply to regular contractors who are doing short term work for us.
## Voluntary Departure
## Voluntary departure
In this case, the team member chooses to leave PostHog.
@@ -19,7 +19,7 @@ If you are a current team member and you are thinking about resigning from PostH
If resignation is the only solution after you have discussed your concerns, please communicate your intention to resign to your manager or the people team. We will then start a discussion around what is needed for the handover.
## Involuntary Departure
## Involuntary departure
In this case, we require the team member to leave.
@@ -27,7 +27,7 @@ This is generally for performance reasons or because the company's needs have ch
Once the team member has been with us for 3 months, we will provide a 4-month [notice](https://posthog.com/handbook/people/compensation#severance) (otherwise, it will be a month). We will usually ask the team member to stop working immediately, but still pay them a 4-month severance).
## Communicating Departures
## Communicating departures
PostHog cannot always provide context around why people are leaving when they do.
@@ -35,7 +35,7 @@ In the case of voluntary departure, we will ask the team member if they wish to
In the case of involuntary departure, we will aim to be as transparent as possible about the reasons behind the departure, while respecting the individual's privacy.
## The Process for Offboarding
## The offboarding process
For involuntary leavers, we will schedule a call, covering the following points with the team member:
@@ -53,7 +53,7 @@ During the call, we will also cover above questions and answer any open question
If the team members works their notice period, we will start an offboarding issue and document the progress and handover in there.
### Final Pay
### Final pay
Final pay will be determined based on length of service and the reasons for leaving.
@@ -66,19 +66,19 @@ We are likely to ask departing team members to sign a release of claims in order
Please note that if there are local laws which are applicable, we will pay the greater of the above or the legally required minimum.
### Share Options Vested
### Share options vested
If you have been allocated share options, we will confirm how many have vested and the process by which you may wish to exercise them. We have a team-friendly post-departure exercise window of 10 years, and most team members who leave will be deemed a 'good leaver' unless you have been terminated due to misconduct or negligence.
### Company Property
### Company property
You will be required to return any company property to us. PostHog will cover the cost of shipping this.
### Business Expenses
### Business expenses
We will pay any expenses in line with our policy that are still unpaid.
### Personal Email to the Company
### Personal email to the company
In the case of voluntary offboarding, you will be offered the chance to send a goodbye email to the company, with relevant contact information as you move on.

15
contents/handbook/people/onboarding.md
View File

@@ -12,21 +12,21 @@ If you have any questions on any of this stuff, ask Charles, James or Tim.
The best way to run through this checklist is to copy the relevant sections below into an onboarding issue on the [Ops Roadmap](https://github.com/orgs/PostHog/projects/2) in GitHub.
## Upon Offer Acceptance
## Upon offer acceptance
Eltje or Charles will create the contract needed, depending on who is joining. Only James and Tim are allowed to sign on behalf of the company.
### US Team Member Checklist
### US team member checklist
<input type="checkbox"/> Create a contract using the [Google Docs template](https://docs.google.com/document/d/15cdfWfGj5OWBpVST6VcMwb5TP5qLVPQd9SGWKSnB9bc/edit?usp=sharing) in the Legal Docs shared drive <br />
<input type="checkbox"/> If we are employing someone in a new state for the first time, check the tax filing requirements on Gusto as soon as possible, as there can be a long lead time <br />
### UK Team Member Checklist
### UK team member checklist
<input type="checkbox"/> Create a contract using the Google Docs templates for [CIIA](https://docs.google.com/document/d/1r7Xc1ALf-JKUrL3g_oyzaQ8H3SOuVchBpJrGp7TINdc/edit?usp=sharing) and [Offer Letter](https://docs.google.com/document/d/1ZzF5hbVmTmKIYKxW7JkXzrBFFNrztkcNvcdO643r6sY/edit?usp=sharing) in the Legal Docs shared drive <br />
<input type="checkbox"/> Email Parallel to add them to our pension scheme <br />
### Non-US nor UK Team Member Checklist
### Non-US nor UK team member checklist
<input type="checkbox"/> Use [Deel](https://letsdeel.com) to set up as a contractor. Choose 'Create a contract' and select fixed. Follow the instructions. This contract will cover pay, notice period, confidentiality and IP assignment. <br />
<input type="checkbox"/> Choose the last day of the month to make payments for ongoing work, else choose something appropriate for a short term contract <br />
@@ -35,7 +35,7 @@ Eltje or Charles will create the contract needed, depending on who is joining. O
<input type="checkbox"/> Select for the contractor to be potentially allocated equity in the future (if this has been agreed) <br />
<input type="checkbox"/> Under 'Other Specifics' add the following as a special clause: _Contractor agrees to comply with any rules, policies and procedures set out in the Company Handbook, a copy of which is available on the Client's website. To the extent that there is any conflict between the terms of this Agreement and the Company Handbook, the terms which are more favorable to the Contractor shall prevail._ <br />
## The Week Before They Join
## The week before they join
<table>
<tr>
@@ -397,7 +397,7 @@ Eltje or Charles will create the contract needed, depending on who is joining. O
## On Their First Day
## On their first day
<table>
<tr>
@@ -535,8 +535,7 @@ Eltje or Charles will create the contract needed, depending on who is joining. O
> Not a hard requirement by any means, but we highly recommended that you join a feedback call and/or product demo in your first weeks. It provides great context on our users.
### Additional Access
### Additional access
Add these if appropriate for the role:

2
contents/handbook/people/side-gigs.md
View File

@@ -10,7 +10,7 @@ These side gigs may sometimes earn you money. Sometimes, you may one day want yo
We have deliberately called them "side gigs", as we are ok with you earning money on the side. We are not ok with this being your main focus and PostHog being just a paycheck. Quite simply, we are too small for PostHog not to be your main motivation.
## Managing Time
## Managing time
The key distinction to something being a side gig, and thus it being appropriate, is its impact on your work and the amount of time involved.

14
contents/handbook/people/spending-money.md
View File

@@ -16,13 +16,13 @@ If you live in the UK, you should use your Revolut card for UK-specific spending
For larger expenses which don't fit into the items here, please **raise a policy suggestion for it as a pull request** in this doc, so we can document our decision making into our policy rather than making everything case by case.
## Trivial Expenses
## Trivial expenses
Just do it.
This means expenses that are under \$75 one off or under \$20/month recurring that we can cancel easily.
## Saving Receipts
## Saving receipts
Make sure you *keep copies for all receipts*. If you expense something on a company card and cannot provide a receipt, this may be deducted from your pay.
@@ -47,7 +47,7 @@ Make sure you forward digital invoices to Brex from your PostHog email address -
Accidentally bought something on the company card when it was a personal expense? Don't worry! Again, just let Charles know _as soon as you become aware_ and he will provide you with the relevant bank details for you to repay the company.
## Making Larger Purchases
## Making larger purchases
If your purchase fits within the policy below, there is no need to ask. We **cannot** pay you back for anything without a receipt if you use your personal card.
@@ -83,7 +83,7 @@ For monitors, we suggest you pick one that supports 4K. This means you'll get a
We would expect to spend \$250 to \$350 on a monitor. Philips have a [great value model](https://www.amazon.com/Philips-276E8VJSB-3840x2160-UltraNarrow-DispalyPort/dp/B07JXCR263). It comes with an HDMI cable, but you'll need an adaptor to USB-C with most Apple laptops.
### Keyboard, Mouse, and Laptop Stand
### Keyboard, mouse, and laptop stand
We'd encourage you to buy a keyboard, mouse and laptop stand.
@@ -91,7 +91,7 @@ Again, Apple items for keyboards and mice should be what you default to - refurb
[Nextstand](https://www.amazon.co.uk/NEXSTAND-K2-Adjustable-Foldable-Portable/dp/B01HHYQBB8) make great value laptop stands that are portable.
### Chairs and Desks
### Chairs and desks
We find that most people already have a desk and chair that are comfortable.
@@ -130,7 +130,7 @@ Individual software is down to your personal preference, and we encourage you to
* IDEs range widely in cost. Best in class IDE suites can cost up to \$700, which is a bad value proposition for most engineers. However, we are happy to revisit this policy if you have very specific needs.
* Before then, if you wish to spend up to \$200 on an IDE, that is fine. Visual Studio, VIM and PyCharm are the most popular within our team.
## Work Space
## Work space
We care about you being healthy, happy and productive.
@@ -156,7 +156,7 @@ For every PostHog anniversary, we will donate $50 to a charity of your choice. A
For events like childbirth, weddings, return to work after extended sick leave or the loss of a loved one, Eltje will send flowers and a gift, the budget is $100. We will also send a virtual card.
## Client Meetings
## Client meetings
If you are meeting a user for an interview or a potential customer, we would encourage you to pick up the bill.

2
contents/handbook/people/team-structure/core-experience.md
View File

@@ -10,7 +10,7 @@ hideAnchor: true
- [Eric Duong (Team Lead, Full Stack Engineer)](/handbook/people/team/#eric-duong-software-engineer)
- [Paolo D'Amico (Product Manager)](/handbook/people/team#paolo-damico-product-team)
- [Buddy Williams, Full Stack Engineer](/handbook/people/team/#buddy-williams-software-engineer)
- Sam Winslow, Full Stack Engineer
- [Sam Winslow, Full Stack Engineer](/handbook/people/team#sam-winslow-full-stack-engineer)
- [Li Yi Yu, Full Stack Engineer]((/handbook/people/team/#li-yi-yu-software-engineer))
## Mission

2
contents/handbook/people/team-structure/design.md
View File

@@ -28,7 +28,7 @@ Tangibly, we:
## Customer
- The other small teams – [here is a guide on how to best work with the Design team](/handbook/company/working-with-design).
- The other small Teams – [here is a guide on how to best work with the Design team](/handbook/company/working-with-design).
## Output metrics

4
contents/handbook/people/team-structure/infrastructure.md
View File

@@ -64,8 +64,8 @@ Concrete things we take responsibility over:
##### Cost
- Metric: Infra Costs
- Objective: Our costs should grow at a rate that is sublinear relative to scale
### Dev Experience
##### Dev Experience NPS (Infra)
### Dev experience
##### Dev experience NPS (Infra)
- Metric: Developer experience (relating to infra) (maybe NPS?)
- Objective: TBD (maybe NPS?)

2
contents/handbook/people/team-structure/people.md
View File

@@ -5,7 +5,7 @@ showTitle: true
hideAnchor: true
---
## People & Culture
## People & culture
- [Eltje Lange](/handbook/company/team#eltje-lange-people-and-talent)
- [Recruitment and Operations Coordinator](https://apply.workable.com/posthog/j/554EC800BE/) (currently hiring!)

2
contents/handbook/people/team-structure/team-structure.md
View File

@@ -45,6 +45,6 @@ We've organised the team into small teams that are multi-disciplinary. [You can
- Mo Shehu (Content Marketer)
## [People & Culture](people)
## [People & culture](people)
- [Eltje Lange](/handbook/people/team#eltje-lange-people-and-talent) (People and Talent)

2
contents/handbook/people/team.md
View File

@@ -38,7 +38,7 @@ That's why we have people in Belgium, the East and West coast of the US, England
<div class="team-title" markdown="1">
## Core Team
## Core team
</div>

8
contents/handbook/people/time-off.md
View File

@@ -16,7 +16,7 @@ This is to make sure that people can take time off flexibly, whilst not feeling
The reason for this policy is that it's critical for PostHog that we hire people we can trust to be responsible with their time off - enough that they can recharge, but not so much that it means we don't get any work done.
## Permissionless Time Off
## Permissionless time off
You do not need to "clear" time off with your manager.
@@ -28,7 +28,7 @@ The same rules as above apply regardless of the vacation length.
You can add the team time off calendar to Google Calendar by following [these instructions](https://intercom.help/charliehr/en/articles/839648-importing-your-time-off-calendar-to-google-calendar) on CharlieHR as well. CharlieHR only refreshes the calendar twice a day, so any changes you make won't be reflected immediately.
## When You Should Have Time Off
## When you should have time off
### You are sick
@@ -38,11 +38,11 @@ Please let your manager know if you need to take off due to illness as soon as y
For extended periods of illness, please speak to us so we can work out a plan. In some countries, we may be required to request a doctor's note from you.
### Jury Duty / Bereavements / Voting / Child Admin Disasters
### Jury duty / bereavements / voting / childcare disasters
There are lots of situations where life needs to come first. Please let it - just be communicative with us and fit your work around it as you need.
## Parental Leave
## Parental leave
Parental leave is exceptional as it needs to be significantly longer than a typical vacation. Anyone at PostHog, regardless of gender, is able to take parental leave, and regardless of the way you've become a parent - childbirth, adoption or foster care.

4
contents/handbook/strategy/business-model.md
View File

@@ -1,5 +1,5 @@
---
title: Business Model
title: Business model
sidebar: Handbook
showTitle: true
---
@@ -16,7 +16,7 @@ The reality is that paid features can increase our revenue, thus our ability to
At the moment, 100% of our focus is on the Community Edition of the software.
## Promises
## Promises
1. We won't introduce features into the open source codebase with a delay.
1. We will always release and open source all tests we have for an open source feature.

59
contents/handbook/strategy/investor-updates.md
View File

@@ -1,59 +0,0 @@
---
title: Working with Investors
sidebar: Handbook
showTitle: true
---
<br />
PostHog brings investors on as partners.
There is a lot of value added from investors:
* Financing so we can build a better and more ambitious product, hence growing faster
* Strategic or tactical advice
* Connections to valuable finance partners
* Connections to valuable potential customers
* Help with hiring a world-class team
# Investor Updates
Investor updates are sent on a monthly basis. This keeps news small and actionable, creates discipline, yet isn't so frequent that much time is spent on reporting.
The format is as follows:
```
------------------------------------------------
Thanks
This is to encourage people to be helpful, which is in everyone's interest, and is part of being nice to work with!
------------------------------------------------
Asks
We may need help with connections to people or organizations, with hiring, or troubleshooting / rubber-ducking.
------------------------------------------------
Key metrics
Investors have a right to know how we're doing. Putting up regular numbers keeps our team focused, and makes many problems more obvious so we can tackle them.
------------------------------------------------
Lowlights
We don't want to surprise people, and by raising issues we may have others help us. We will commit to 3 lowlights every month so we have to include something here.
------------------------------------------------
Highlights
We should surface key opportunities or exciting moments so we can aim to grow fast and to keep people excited.
------------------------------------------------
Expectations
What we're planning for the next month. This context increases our chances of getting help from investors.
------------------------------------------------
```
We do not share investor updates publicly. This is because we often need to mention specific clients, legal and finance issues, all of which are in the rare category of being potentially harmful to discuss.

2
contents/handbook/strategy/prioritization.md
View File

@@ -13,7 +13,7 @@ Our mission is to increase the number of successful products in the world.
To achieve this, we will need revenue to be able to re-invest into making a better product.
## How is our Product-Market Fit?
## How is our product/market fit?
Below is a table of how we see our product-market fit for various sizes of companies and various job roles.

4
contents/handbook/strategy/strategy.md
View File

@@ -14,7 +14,7 @@ Our best users look a little like this:
* They may work in a startup, scaleup or enterprise
* Their company builds software, at least in some capacity, and cares about the end users of their software
## How we'll meet their needs
## How we'll meet their needs
We're consolidating a fragmented set of tools in the market that help software teams understand and act on user behavior. Companies already know why product analytics matter.
@@ -30,7 +30,7 @@ We've had ~3,000 deployments since we started.
PostHog helps power products as diverse as those in airlines and banks, to indie gamers making it more fun to protect earth from aliens to underwear startups working on their retention. Across all devices.
## The future
## The future
Software is a good chunk through eating the World.

2
src/components/CompensationCalculator/compensation_data/location_factor.ts
View File

@@ -1715,7 +1715,7 @@ export const locationFactor: CompensationCalculatorLocation[] = [
{
country: 'France',
area: 'Everywhere else',
locationFactor: 0.50,
locationFactor: 0.5,
currency: 'EUR',
},
{

2
src/components/Footer/DocsFooter.tsx
View File

@@ -10,7 +10,7 @@ export function DocsFooter({ filename, title }: DocsFooterProps) {
return (
<div className="docs-footer">
<Row>
<h3>Reach Out</h3>
<h3>Reach out</h3>
If you need help on any of the above, feel free to create an issue on{' '}
<a href="https://github.com/PostHog/posthog">our repo</a>, or <a href="/slack">join our Slack</a> where
a member of our team can assist you! Chances are that if you have a problem or question, someone else

132
src/mdxGlobalComponents.js
View File

@@ -1,4 +1,4 @@
// AUTO GENERATED FILE
// AUTO GENERATED FILE
import { Endpoint } from './components/APIDocs/Endpoint'
import { MethodTags } from './components/APIDocs/MethodTags'
@@ -66,68 +66,68 @@ import { Structure } from './components/Structure'
import { TableOfContents } from './components/TableOfContents'
export const shortcodes = {
Endpoint,
MethodTags,
AnchorScrollNavbar,
ArrayCTA,
BasicHedgehogImage,
BlogPostLayout,
BlogPosts,
BlogShareButtons,
BlogSidebar,
BlogFooter,
CallToAction,
Benefits,
CareersHero,
Culture,
InterviewProcess,
OpenRoles,
WhyWereHere,
WorkingAtPostHog,
CodeBlock,
CompensationCalculator,
Container,
ContributorAvatars,
ContributorCard,
ContributorSearch,
ContributorsChart,
DarkModeToggle,
DemoScheduler,
DocsPageSurvey,
DocsSearch,
FeaturesComparisonTable,
FeaturesNav,
Footer,
GetStartedModal,
HiddenSection,
Blockquote,
Features,
Hero,
LandingPageCallToAction,
PrivateCloud,
ProductFeatureIcons,
RecentBlogPosts,
Roadmap,
SocialProof,
Tutorials,
LibraryStats,
MdxAnchorHeaders,
NewsletterForm,
OtherFeaturesBlock,
PageHeader,
PostCard,
PricingComparisonTable,
PricingSlider,
ResponsiveAnchor,
ResponsiveSidebar,
ResponsiveTopBar,
DesignedForYourStackBlock,
FeaturedSectionTextLeft,
FeaturedSectionTextRight,
FeaturedSectionTripleImage,
Spacer,
StarRepoButton,
StartNowButton,
Structure,
TableOfContents
}
Endpoint,
MethodTags,
AnchorScrollNavbar,
ArrayCTA,
BasicHedgehogImage,
BlogPostLayout,
BlogPosts,
BlogShareButtons,
BlogSidebar,
BlogFooter,
CallToAction,
Benefits,
CareersHero,
Culture,
InterviewProcess,
OpenRoles,
WhyWereHere,
WorkingAtPostHog,
CodeBlock,
CompensationCalculator,
Container,
ContributorAvatars,
ContributorCard,
ContributorSearch,
ContributorsChart,
DarkModeToggle,
DemoScheduler,
DocsPageSurvey,
DocsSearch,
FeaturesComparisonTable,
FeaturesNav,
Footer,
GetStartedModal,
HiddenSection,
Blockquote,
Features,
Hero,
LandingPageCallToAction,
PrivateCloud,
ProductFeatureIcons,
RecentBlogPosts,
Roadmap,
SocialProof,
Tutorials,
LibraryStats,
MdxAnchorHeaders,
NewsletterForm,
OtherFeaturesBlock,
PageHeader,
PostCard,
PricingComparisonTable,
PricingSlider,
ResponsiveAnchor,
ResponsiveSidebar,
ResponsiveTopBar,
DesignedForYourStackBlock,
FeaturedSectionTextLeft,
FeaturedSectionTextRight,
FeaturedSectionTripleImage,
Spacer,
StarRepoButton,
StartNowButton,
Structure,
TableOfContents,
}

15
src/sidebars/sidebars.json
View File

@@ -271,8 +271,7 @@
"handbook/strategy/strategy",
"handbook/strategy/business-model",
"handbook/strategy/roadmap",
"handbook/strategy/prioritization",
"handbook/strategy/investor-updates"
"handbook/strategy/prioritization"
]
},
{
@@ -398,17 +397,5 @@
"handbook/engineering/beginners-guide/developer-workflow",
"handbook/engineering/beginners-guide/technologies-to-learn"
]
},
{
"entry": "Strategy",
"name": "Strategy",
"items": [
"handbook/strategy/strategy",
"handbook/strategy/business-model",
"handbook/strategy/roadmap",
"handbook/strategy/prioritization",
"handbook/strategy/investors",
"handbook/strategy/investor-updates"
]
}
]