Skip to content

Commit

Permalink
Content-updates
Browse files Browse the repository at this point in the history
  • Loading branch information
@aagonzales
aagonzales committed Oct 22, 2024
1 parent 90a5dcd commit 238c1f6
Show file tree
Hide file tree
Showing 3 changed files with 56 additions and 54 deletions.
2 changes: 1 addition & 1 deletion src/data/nav-items.yaml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -43,7 +43,7 @@
pages:
- title: Get started
path: /contributing/get-started/overview/
- title: Product development lifecycle
- title: Product Development Lifecycle
path: /contributing/product-development-lifecycle/
- title: Component checklist
path: /contributing/component-checklist/
Expand Down
2 changes: 1 addition & 1 deletion src/pages/contributing/component-checklist/index.mdx
View file
Original file line number Diff line number Diff line change
Expand Up @@ -33,7 +33,7 @@ a backlog of work, share the status of assets with contributors and better
differentiate when an asset is a component versus a pattern. We can also work
backward from this strict list of requirements to inform where a component
currently is in the
[Product Development Lifecycle](https://w3.ibm.com/w3publisher/winning-products/how-we-work/product-development-lifecycle)
[Product Development Lifecycle](/contributing/product-development-lifecycle/)
(PDLC). With each phase, the component should progress in its completeness. Once
it has reached stable and all items in the following checklists have been
completed, then the component will be considered done.
Expand Down
106 changes: 54 additions & 52 deletions ...uting/product-development-lifecycle/index → ...g/product-development-lifecycle/index.mdx
View file
Original file line number Diff line number Diff line change
@@ -1,21 +1,21 @@
---
title: Product development lifecycle
title: Product Development Lifecycle
description:
In order to contribute to the Carbon ecosystem, it’s essential that we explain Carbon’s process, clearly define milestones in each phase of contribution, and offer a clear “definition of done” for our contributors.
In order to contribute to the Carbon ecosystem, it’s essential that we explain Carbon’s process, define milestones in each phase of contribution, and offer a clear “definition of done” for our contributors.
---

<PageDescription>

In order to contribute to the Carbon ecosystem, it’s essential that we explain Carbon’s process, clearly define milestones in each phase of contribution, and offer a clear “definition of done” for our contributors.
In order to contribute to the Carbon ecosystem, it’s essential that we explain Carbon’s process, define milestones in each phase of contribution, and offer a clear “definition of done” for our contributors.

</PageDescription>

<AnchorLinks>
<AnchorLink>Overview</AnchorLink>
<AnchorLink>Definition of done</AnchorLink>
<AnchorLink>Discovery</AnchorLink>
<AnchorLink>Delivery</AnchorLink>
<AnchorLink>Launch and scale</AnchorLink>
<AnchorLink>Definition of done</AnchorLink>

</AnchorLinks>

Expand All @@ -25,56 +25,22 @@ IBM teams follow a process framework called the Product Development Lifecycle (P
The PDLC is organized into three phases: discovery, delivery, and launch & scale. Once a product is in market, agile product teams do all these types of work concurrently, in parallel work streams, with feedback from in-market learnings shaping the priorities of both discovery and delivery.

#### PDLC applied to contribution
Carbon has applied PDLC framework to how we expect new assets like components, features, and patterns to be contributed to Carbon. We have broken the contribution process up into the same three phases, each having their own set of success criteria.
Carbon has applied the PDLC framework to how we expect new assets like components, features, and patterns to be contributed to Carbon. We have broken the contribution process up into the same three phases, each having their own set of success criteria.

- **Discovery phase**: The purpose of the discovery phase is to address any major value, usability, feasibility and viability risks ahead of delivering product-quality code, in order to arrive at a successful product faster and at a lower cost.
- **Delivery phase**: The delivery phase emphasizes the disciplined execution of determining how we will realize user value and maximizing the efficiency of building it. This includes the functional and non-functional requirements, and the user experience required for customers to adopt product features within a production setting.
- **Launch and scale**: Launch and scale of course, involves having clearly defined success criteria or learning objectives that are monitored after launch. In this phase an asset will become stable and achieve Carbon’s “definition of done.”
- **Launch and scale phase**: Launch and scale of course, involves having clearly defined success criteria or learning objectives that are monitored after launch. In this phase an asset will become stable and achieve Carbon’s “definition of done.”

_For IBMers only_: You can read more about the PDLC on the [IBM Winning Products](https://w3.ibm.com/w3publisher/winning-products/how-we-work/product-development-lifecycle) website.

<Row>
<Column colLg={12}>

![PDLC diagram](images/PDLC-01.png.png)
![PDLC diagram](images/PDLC-01.png)

</Column>
</Row>

### Definition of done

By aligning on the requirements for what it means for an asset to be done, we can create a backlog of work to be prioritized, better differentiate when an asset is a component versus a pattern, share expectations with contributors, and display the status of assets to users. With each phase, the component should progress in its completeness. Once it has reached stable, then the asset will be considered done.

| Status | PDLC Phase | Description |
| ------------------- | ---------------- | ------------------------------------------------------------------------------------ |
| `Draft` | [Discovery]() | Partially complete, ready for validation. |
| `Preview candidate` | [Discovery]() | Partially complete, with measurable results, stakeholders, and clear business value. |
| `Preview` | [Delivery]() | Mostly complete, changes possible based on feedback, available to use in production. |
| `Stable` | [Launch and scale]() | Complete across code, kit, docs, design, and ready for production use. |

### Asset types

Defining and standardizing our terms across the ecosystem is crucial as we align against the PDLC. In the past, teams operated under very different assumptions about what a “pattern” versus “component” is. It has been difficult to move towards stability without everyone being on the same page in this respect.

Eventually, all Carbon and Carbon for IBM Products resources (e.g. libraries, assets, design kits) will follow a schema to standardize definitions and documentation. However, for now, we’re just going to focus on defining the two most important assets in our ecosystem. Each asset type has its own definition of done that must be completed before an asset can be considered done.

| Asset type | Description |
| ---------- | ----------- |
| Component | An asset that has been designed and coded, that can be imported into a UI. See the [component checklist](m/contributing/component-checklist/) for the definition of done. |
| Pattern | Patterns are something that can be accomplished in multiple ways utilizing a combination of component(s) with additional design considerations. Because of the many ways patterns can be implemented, it is not possible to provide code for every scenario, but some patterns do have example code. |

## Review channels

Before an asset can move to the next phase it needs to be reviewed to ensure all requirements and criteria are being met. Below are the best ways to get a review from core Carbon maintainers. In order to not overwhelm these review channels the community first needs to show significant interest in the discovery asset. The community is the first approval gateway before the Carbon teams engages with it.

| Review channel | Description |
| ---------- | ----------- |
| GitHub issue | Open a [feature request or enhancement](https://github.com/carbon-design-system/carbon/issues/new?template=FEATURE_REQUEST_OR_ENHANCEMENT.yaml) issue in the Carbon GitHub outlining the gap that needs to be resolved. The issue should include all supporting materials and evidence you have gathered in the discovery phase. This can include competitive research, potential solutions, or prototypes.|
| GitHub pull request | Open a pull request in the appropriate Carbon [GitHub repo](https://github.com/carbon-design-system) for a final review of your completed contribution. If you are seeking feedback on a proof-of-concept then open a draft pull request instead. |
| DSAG playback | _For IBMers only_: Present your findings at a Design System Adoption Guild (DSAG) meeting. [Enroll](https://ec.yourlearning.ibm.com/w3/meeting/10453549) in the event and sign up for a time slot when you are ready.|
| Carbon office hours | _For IBMers only_: Carbon offers both a development and design specific sessions. [Enroll](https://ec.yourlearning.ibm.com/w3/series/10289694?layout=grid) in the event and sign up for a time slot when you are ready. |


## Discovery

The discovery phase is where research, exploration, and validation happen. This is when innovations to the system are proposed and reviewed.
Expand All @@ -85,11 +51,11 @@ For an enhancement or net new asset to warrant resourcing a discovery phase, we

#### Key considerations:

– Does it replicate anything in the system already, or is there truly a gap?
– If the proposal does replicate an existing asset, is there evidence to show that the proposed solution is better?
– Is there already an existing issue or proposal in [Github](https://github.com/carbon-design-system/carbon/issues) to address the gap?
– Is there evidence that the new asset or enhancement would be useful for many teams or services?
– What is the ratio of feasibility to impact to help prioritize (consult developers and accessibility SMEs)?
- Does it replicate anything in the system already, or is there truly a gap?
- If the proposal does replicate an existing asset, is there evidence to show that the proposed solution is better?
- Is there already an existing issue or proposal in [GitHub](https://github.com/carbon-design-system/carbon/issues) to address the gap?
- Is there evidence that the new asset or enhancement would be useful for many teams or services?
- What is the ratio of feasibility to impact to help prioritize (consult developers and accessibility SMEs)?

#### Discovery status

Expand All @@ -109,13 +75,15 @@ In the delivery phase, the Carbon team usually collaborates with a workgroup or

### Delivery criteria

As a component or pattern enters the delivery phase, we begin to complete the requirements for an asset to reach "stable.” By aligning across the Carbon ecosystem on our requirements for stability—or a definition of done— we not only share our expectations with contributors, but we can more easily create a backlog of work to prioritize, and more clearly display the status of assets to users.
As a component or pattern enters the delivery phase, we begin to complete the requirements for an asset to reach "stable.” By aligning across the Carbon ecosystem on our requirements for stability—or a [definition of done](/contributing/product-development-lifecycle/#definition-of-done)—we not only share our expectations with contributors, but we can more easily create a backlog of work to prioritize, and more clearly display the status of assets to users.

#### Milestones:

– Carbon team will collaborate with the subject matter experts and establish a feasible quarterly roadmap (3-in-a-box perspective)– A strong source of truth has been established in Figma, including robust design specs and initial usage docs– Identify 5–8 stakeholder teams for early usage and feedback
– Backlog work begins on kit, docs, code triumvirate per definition of done
– Any breaking changes are integrated into the Carbon library behind a [feature flag](/components/overview/feature-flags/)
- Carbon team will collaborate with the subject matter experts and establish a feasible quarterly roadmap (3-in-a-box perspective)
- A strong source of truth has been established in Figma, including robust design specs and initial usage docs
- Identify 5–8 stakeholder teams for early usage and feedback
- Backlog work begins on kit, docs, code triumvirate per definition of done
- Any breaking changes are integrated into the Carbon library behind a [feature flag](/components/overview/feature-flags/)

#### Prioritization

Expand All @@ -137,7 +105,41 @@ In the delivery phase, the workgroups should begin to think about the requiremen
Along the way you should be requesting peer on the various deliverables. It is crucial to get reviews early and often to make sure all requirements are accounted for. Reach out to the Carbon team if you are unsure who should review your work.

#### Launch and scale status
All components in the in launch and scale phase are `stable`. This means all requirements in the assets [definition of done]() are complete and the asset is ready to use in production.
All components in the in launch and scale phase are `stable`. This means all requirements in the assets [definition of done](/contributing/product-development-lifecycle/#definition-of-done) are complete and the asset is ready to use in production.

#### Final steps
— Once an asset is complete there should be a communication plan in place to raise awareness of the new work across multiple channels. — PMs should also begin to track the usage (product insertions) of the new asset via Figma’s API and the IBM Telemetry service.
- Once an asset is complete there should be a communication plan in place to raise awareness of the new work across multiple channels.
- PMs should also begin to track the usage (product insertions) of the new asset via Figma’s API and the IBM Telemetry service.

## Definition of done

By aligning on the requirements for what it means for an asset to be done, we can create a backlog of work to be prioritized, better differentiate when an asset is a component versus a pattern, share expectations with contributors, and display the status of assets to users. With each phase, the component should progress in its completeness. Once it has reached stable, then the asset will be considered done.

| Status | PDLC Phase | Description |
| ------------------- | ---------------- | ------------------------------------------------------------------------------------ |
| `Draft` | [Discovery](/contributing/product-development-lifecycle/#discovery) | Partially complete, ready for validation. |
| `Preview candidate` | [Discovery](/contributing/product-development-lifecycle/#discovery) | Partially complete, with measurable results, stakeholders, and clear business value. |
| `Preview` | [Delivery](/contributing/product-development-lifecycle/#delivery) | Mostly complete, changes possible based on feedback, available to use in production. |
| `Stable` | [Launch and scale](/contributing/product-development-lifecycle/#launch-and-scale) | Complete across code, kit, docs, design, and ready for production use. |

### Asset types

Defining and standardizing our terms across the ecosystem is crucial as we align against the PDLC. In the past, teams operated under very different assumptions about what is a “pattern” versus “component”. It has been difficult to move towards stability without everyone being on the same page in this respect.

Eventually, all Carbon and Carbon for IBM Products resources (e.g. libraries, assets, design kits) will follow a schema to standardize definitions and documentation. However, for now, we’re just going to focus on defining the two most important assets in our ecosystem. Each asset type has its own definition of done that must be completed before an asset can be considered done.

| Asset type | Description |
| ---------- | ----------- |
| Component | An asset that has been designed and coded, that can be imported into a UI. See the [component checklist](/contributing/component-checklist/) for the definition of done. |
| Pattern | Patterns are something that can be accomplished in multiple ways utilizing a combination of component(s) with additional design considerations. Because of the many ways patterns can be implemented, it is not possible to provide code for every scenario, but some patterns do have example code. |

### Review channels

As an asset moves through the phases it needs to be reviewed to ensure all requirements and criteria are being met. Below are the best ways to get a review from the Carbon team. In order to not overwhelm these review channels the community first needs to show significant interest in the discovery phase. The community is the first approval gateway before the Carbon teams engages with the work.

| Review channel | Description |
| ---------- | ----------- |
| [GitHub issue](https://github.com/carbon-design-system/carbon/issues/new?template=FEATURE_REQUEST_OR_ENHANCEMENT.yaml) | Open a feature request or enhancement issue in the Carbon GitHub outlining the gap that needs to be resolved. The issue should include all supporting materials and evidence you have gathered in the discovery phase. This can include competitive research, potential solutions, or prototypes.|
| [GitHub pull request](https://github.com/carbon-design-system) | Open a pull request in the appropriate Carbon GitHub repo for a final review of your completed contribution. If you are seeking feedback on a proof-of-concept then open a draft pull request instead. |
| [DSAG playback](https://ec.yourlearning.ibm.com/w3/meeting/10453549) | _For IBMers only_: Present your findings at a Design System Adoption Guild (DSAG) meeting. Sign up for a time slot when you are ready.|
| [Carbon office hours](https://ec.yourlearning.ibm.com/w3/series/10289694?layout=grid) | _For IBMers only_: Carbon offers both a development and design specific sessions. Sign up for a time slot when you are ready. |

0 comments on commit 238c1f6

Please sign in to comment.