Define and implement pd-flow change process

From Slack thread: https://gitlab.slack.com/archives/C019KM43H4K/p1601311886017900

  • We need a changelog
  • We need to define when release notes are required (big enough changes) and where they live
  • We need to have a clear list of who it gets socialized to cross-functionally

Current Plan (prior to the change process being identified in this issue)

Currently, as part of an "interim change process" Farnoosh is going to share latest MRs merge to Draft page as FYI in Slack product channel and read-only section of PM weekly.

Moving Forward

Changelog

In order to make it simple for those who are consuming the changes, we need to be able to provide a change log to the greater GitLab team.

This could be accomplished via a diff of the existing version and the draft version. To accompany this, it would make sense to define all issues / epics that relate as part of a milestone. These milestones already exist in the product and would allow us to easily find issues through built-in filtering

Release Notes

Ideally, release notes would be succinct and easy to digest. They would highlight the key takeaways from what was done during the previous working group milestone. For example, for this first iteration we could mention that:

The current product development flow was updated to an outcomes and activities model, which addresses the problem of the previous version being too ambiguous.

We could also link to epics / issues for this to allow those who desire to dig in deeper.

Cross functional socialization

We would like to provide a clear way to distribute the changes and updates to the broader GitLab community in an asynchronous way to ease confusion. We could provide the release notes with links to the change log and the relevant milestone. We could also record overview videos.

For groups where synchronous communication may be warranted (as determined by group level leadership) we encourage those leaders to add it to their agendas for their teams to digest asynchronously (product team weekly call for example).

We will also hold AMA sessions (preferably two during opposite time zones to be as inclusive as possible) where questions can be asked.

Edited by Farnoosh Seifoddini