2022-10-25 - Product Working Group Meeting Notes and Agenda

Recording Link: https://drive.google.com/drive/folders/1a9_EokEh96VgLTtRoxT9Xfo9z1xsMkcQ

Attendees:

@Xavier Antoviaque

@Ryan O'Connell

@Spencer Tiberi

@Ali Hugo

@Faqir Bilal

@Santiago Suarez

@Shelly Upton

@Jenna Makowski

Agenda Items for 10-25:

Agenda Item	Presenter	Description	Notes/Next steps

Agenda Item	Presenter	Description	Notes/Next steps
Update: Project Status Updates: Governance Charter	@Jenna Makowski @Xavier Antoviaque	Review of final edits and comments and finalize. Set plan to review on a regular cadence. https://openedx.atlassian.net/wiki/spaces/COMM/pages/3487301637	Notes from 10/25: Project closed and completed Notes from 10/11: @Xavier Antoviaque to review remaining comments and new edits, and close comments if resolved. Once comments are closed, @Jenna Makowski to post final version in original discourse thread. Ticket created to do a retro in 6mos.
Update: Project Status Updates: Product Narrative [prod-nar]	@Faqir Bilal @Santiago Suarez @Jenna Makowski	https://github.com/orgs/openedx/projects/26/views/1?filterQuery=prod-nar	Next steps - value props survey
Update: OEP-57	@Ali Hugo	Summary idea behind OEP-57: we wish to define what a Product Narrative, a Core Product Offering, and an Extended Product Offering are, and detail the process by which we will get there.	Any updates on reviews, comments, feedback?
PR step of OSPR process	@Xavier Antoviaque @Ryan O'Connell @Sarina Canelake @Jenna Makowski	Clarify where in the current OSPR process the specific product review step falls Clarify how it is currently tracked Decide who should be involved in product triage and when. Let's define the criteria for when a PR needs product review, who it should go to, and where Prod WG can step into that process in a meaningful way. See	See next steps and ticket links below
Release Notes Blog Invitation	@Ryan O'Connell	Invitation to publish release notes to the Open edX Product Management Confluence Blog

PR process - Immense opportunity to redefine how this works

Next steps:

Pain point: Product context gets separated from the PR by the time the PR is submitted. There should be an earlier “product check” process.
1. Solution: Leverage the Roadmap. Need a step to create a Roadmap ticket for the project at the same time the PR is submitted. Create better/more streamlined issue templates for the Roadmap and document this step in PR process to submit tickets (OEP?)
  1. @Jenna Makowski will work with @Sarina Canelake on this
Pain point: No guidelines for when PRs should go to product review and when.
1. Solution: Open edX Product to write and own this guideline.
  1. @Ryan O'Connell and @Jenna Makowski to collaborate on v1
Pain point: The review process historically has taken too long, with PRs sitting for months or more.
1. Solution: PMs need better notification systems. Explore integrating GH and Jira
2. Solution: Explore shifting the review workload to future Core Contributor Product Managers and leveraging WG meetings to review
Pain point: No framework for assessing submissions
1. If Solution B above moves forward, the WG must create a framework for assessing based on the evolving Core Product work

Notes on the conversation:

Current workflow
-engineering teams are taking PRs are making decisions about whether or not to engage with PMs, most PRs don’t make it to PMs

Pains
-no centralized process or gates
-pop up surprises for PMs in boards at sprint review times

Pro of current workflows
-where teams are active, the process can move quickly, esp for non-user facing PRs

Need - identify a rubric for EMs to decide when a PR goes to product

Does this change UI or user behavior, reporting, data structure?
-or if an EM is unsure

Bake into the PR workflow - product documentation should be baked into the process by design
-adding docs to a PR vs pre-check processes
^the goal of the roadmap is to capture those pre-check steps of new features, enhancements
-Can we start with the roadmap? Create a roadmap ticket at the same time as a PR?
-use roadmap template but modify template depending on types of features - major features, major arch changes, smaller bug fixes, etc (link to PRs)

Then:

More pain points:
How do we find the right person?
Different teams on different timelines

Possible solutions:

-clear expectations of timelines - ie a high-level review within 2 weeks of submission, or a second option to escalate to the PWG to undertake the review
-recognize it will be difficult, sometimes not possible, to enforce an sla
-possibility to shift some of the review responsibilities to core contributor PM role, and leverage the PWG time to aid in reviews, unblock
-need framework to conduct the high level review, quick checklist to review submissions

Secondary problem - GH vs jira
-better notifications from GH? slack integrations?