Skip to content

doc/developer: minor patches to project lifecycle #24997

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Feb 6, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 9 additions & 8 deletions doc/developer/project-lifecycle.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,8 @@ The DRI is responsible for communicating progress through these
lifecycle phases by:

- Updating the "Lifecycle" tag on the associated GitHub Epic.
- Optionally, announcing the update in #epd-announce and #ohship.
- Optionally, announcing the update in `#epd-announce` and
`#shipped-it`.

## Internal Development

Expand Down Expand Up @@ -41,16 +42,16 @@ Before a project can move to Private Preview, it must:
- Cause stability issues for other parts of the system.
- Live behind a gated feature flag (disabled by default).
- Have basic tests live and running.
- Have basic reference documentation live behind a {{< private-preview >}} flag.
- Have basic reference documentation live behind a `{{< private-preview >}}` flag.
- Have its GitHub epic status set to "Private Preview".

## Private Preview

The goal of Private Preview is to identify and address all of
the reasons why the solution might not work. To do this, the
DRI is responsible for getting the solution in front of relevant
internal (e.g. DevEx) and external (e.g. customers) testers.
It is recommended to kick this off by posting to #epd-announce
internal (e.g. testing team, analytics team) and external (e.g. customers) testers.
It is recommended to kick this off by posting to `#epd-announce`
and asking for support on identifying testers. Customer-facing
teams such as field engineering are well-positioned to provide
guidance on external testers. If you're unsure how to proceed,
Expand Down Expand Up @@ -83,12 +84,12 @@ Before a project can move to Public Preview, it must:
- Have addressed all known stability issues.
- Have addressed all known limitations, except those that are explicitly out of scope.
- Support all known customer configurations, except those that are explicitly out of scope.
- Have polished reference documentation published with a {{< private-preview >}} notice.
- Have polished reference documentation published with a `{{< private-preview >}}` notice.

To move a feature to Public Preview:

- Update any documentation about the feature to use the {{< public-preview >}} notice.
- Add a release note with a {{< public-preview >}} flag.
- Update any documentation about the feature to use the `{{< public-preview >}}` notice.
- Add a release note with a `{{< public-preview >}}` flag.
- Update the GitHub epic status to "Public Preview".
- Enable the feature flag in all environments.

Expand All @@ -113,7 +114,7 @@ Before a project can move to General Availability, it must:

To move a project to General Availability:

- Remove the {{< public-preview >}} notice from the documentation.
- Remove the `{{< public-preview >}}` notice from the documentation.
- Write a blog post describing the project, or explicitly
justify why a blog post is not required.
- Write a release note announcing that the project is in General Availability.
Expand Down