Sprint 1.38.0 1/2 - June 27 to July 8

[marcushyett-ph]

Global Sprint Planning

Retro: Status of Outcomes from Previous Sprint

1. Nail Exports - why? a lot of customer demand for various types of exports (better CSV), subscriptions and image exports @mariusandra (90%)
2. Nail FOSS - why? because we're open source (incuding some kind of celebration 🎉) @EDsCODE (Deployable end of sprint 🤞)
3. Simplifying events + actions @alexkim205 — Why? Customers struggle to differentiate or group similar events, causing inconsistency in reporting and inaccurate analyses (Final PR out)
4. Nail Session Analysis - why? Bring back session analysis, a ton of customer demand for using recordings and understand how time is spent @rcmarron (Status: made progress on unique session + session duration property. Breakdowns/property math operations/funnels still need to be done. Will continue into next sprint.)
5. Gitlab installation (setup snowplow ingestion plugin and hand holding) @fuziontech - Why: Support a valuable customer and collect feedback (Blocked on their Data Engineer investigating schema they want to implement, instance up and mapping ready)
6. Blob storage for session recording setup for a team on cloud @hazzadous - Why: Reclaim storage on ClickHouse and reduce load on ClickHouse. Reduce costs (More complecated than when we started the sprint, @rcmarron and @pauldambra to dedicate next-next sprint to nailing this collaboratively)
7. Specifically production traffic will be consumed by new infrastructure in parallel (incuding some kind of celebration 🎉) @hazzadous @guidoiaquinti - Why: Move towards a more repeatable infrastructure defined in code. 6 month goal (We went to 5%, postgres maintenance first)
8. Ensure persons drift between Postgres and ClickHouse is less than 1% @tiina303 - Why: To make the plugin server more reliable and prevent churn from data integrity issues (at 2.8%, we have landed several fixes, this should get us below 1%)
9. Complete the final ingestion-related tasks for persons/groups on events to get ready for async migration @Twixes - Why: To unlock high scale querying (progressed in this department, async migration planned for next sprint)

Support hero this sprint

Week 1: @tiina303 Week 2: @mariusandra

Plan: Proposed Goals for Next Sprint

Each goal should have a single owner. Owner can only be an engineer.

1. Top priority is to methodically and stepwise ship to 100% on EKS infrastructure @hazzadous @fuziontech
   • why? Six month plan, convert our infra
2. Audit and improve Postgres monitoring and alerting @guidoiaquinti + someone TBD
   • why? A lot of pain recently (i.e. tablecache issues), get ahead of some categstorphic fires, find out what might haunt us in the next few months
3. Write the async migration to backfill persons on events (and potentially JSON object data type) @macobo
   • why? Unlock high scale query, last infra bit we need to work on
4. https://github.com/PostHog/posthog/issues/10421 @yakkomajuri
   • why? data integrity is critical for our customers to be successful
5. Nail Exports - Episode 2 - Attack of the Exports - Subscriptions - Slack (finishing) @benjackwhite, CSV - standardise export method and make as many things exportable as possible @pauldambra, Embeds / Sharing @mariusandra
   • why? exports is bread and butter missing functionality, and will drive discovery of posthog and useage from exsisting customers
6. Nail session analysis (Breakdowns/property math operations/funnels) @rcmarron
   • why? because our customers really want to understand the duration of sessions for customer engagemnt and we've had a lot of feedback since we removed sessions insight
7. Server side library support for mult-variate feature flags and groups (stretch mobile SDKs) @liyiy
   • why? A lot of customers can't use features like experiments or groups because they libraries they use don't support it

Team sprint planning

For your team sprint planning copy this template into a comment below for each team.

Team ___

## Retro

<!-- Talk about what went well, what didn't go well and any actions to improve next time -->

- 

## Hang over items from previous sprint

<!-- For each item, decide to re-prioritise (and add below) or deprioritise -->

- Item 1. prioritised/deprioritise

## Planning

<!-- Each item should have a single owner. Owner can only be an engineer. -->

### High priority

-

### Bugs

-

### Low priority / side quests

-

[benjackwhite]

Team East

Retro

• @mariusandra - good to be off 3 days, floating ui took way too much time, happy it's done
• @kappa90 - brown bag moment. Thought I'm done with the datepicker, then had to re-refactor to make it into an experiment... and got the flu. Learning pains :)
• @pauldambra - learned a lot about Kafka & CH, appreciate how much I don't know. Too slow to roll my chair to a colleague remotely.
• @benjackwhite - quite a lonely sprint with a lot of work on subscriptions - also enjoyable. Got a long session with Paul and was good to have back-n-forth. Scheduled a regular chat between us. Suggestion we all do this.

Hang over items from previous sprint

🤔 - Email Subs (Insights + Dashboards), Slack Subs 90%, Optimising the image exporter

• Item 1. Slack Subscriptions (90%)
• Item 2. S3 Session Recordings - still a way to go...

Planning

High priority

Nail Exports - Episode 2 - Attack of the Exports - Subscriptions - Slack (finishing) @benjackwhite, CSV - standardise export method and make as many things exportable as possible @pauldambra, Embeds / Sharing @mariusandra

Bugs

-

Low priority / side quests

ON HOLD - till next sprint - (@pauldambra & @rcmarron) Reading from S3 for Session Recordings (for PostHog team)

• Start looking into Mobile SDK improvements (will likely be the following Sprint Goal

[EDsCODE]

Team WEST

Retro

• A lot of stuff getting done and bugs squashed but tons of separate PRs and people on different work @EDsCODE

Hang over items from previous sprint

• Session Analysis - Prioritize

Planning

• Session Analysis @rcmarron
• Server/client libraries @liyiy
• Keep tabs on person-on-events integraiton @EDsCODE

[fuziontech]

Team Infrastructure

Retro

• @guidoiaquinti - Low energy. Mix of things. Deferred to ingestion team which was good, but the tendency is for us to wait until things go full on fire before actually acting on it. Maybe we can do a bit better job getting attention to a potential issue.
• @hazzadous - Feel pretty drained. "oh my gaawwwd" Ignoring most of the other stuff that goes on. The little battles.
• @fuziontech - We have some really great candidates in the pipeline. I'm really really excited for the new infrastructure. We have that partially shipped.

Hang over items from previous sprint

• We've migrated 5%, we still have 95% to go. Nothing blocking so far. Just being cautious.

Planning

High priority

• Top priority is to methodically and stepwise ship to 100% on EKS infrastructure @hazzadous @fuziontech
• Audit and improve Postgres monitoring and alerting @guidoiaquinti + someone TBD

Bugs

• Postgres cleanups and low hanging fruit @guidoiaquinti + someone TBD

[yakkomajuri]

1. Write the async migration to backfill persons on events (and potentially object storage)
   • Why: To unlock high scale querying
2. https://github.com/PostHog/posthog/issues/10421