Versions Compared

Old Version 5

changes.mady.by.user Jenna Makowski

Saved on

compared with

New Version 6

changes.mady.by.user Jenna Makowski

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

Attendees:

Xavier Antoviaque

Ryan O'Connell

Spencer Tiberi

Ali Hugo

Faqir Bilal

Santiago Suarez

Maria Fernanda Magallanes Z

Shelly Upton

Jenna Makowski

Agenda Items for 10-25:

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. Product working group Charter

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. https://openedx.atlassian.net/wiki/spaces/COMM/pages/3540713547/Open+edX+Proposal+57+Product+Offering?src=mail&src.mail.action=view&src.mail.notification=com.atlassian.confluence.plugins.confluence-notifications-batch-plugin%3Abatching-notification&src.mail.recipient=8a7f808a7e00012e017e0289182301dd&src.mail.timestamp=1664995272833

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 https://github.com/openedx/platform-roadmap/issues/182

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:

  1. 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

  2. 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

  3. 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

  4. 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?