You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Check out the [contribution example](#contribution-example) for a formatted example, and explore [breaking change formatting](#breaking-changes) for consideration during Calcite's breaking change releases.
@@ -240,7 +240,7 @@ Contributions must adhere to **one** of the following types:
240
240
241
241
### Scope of change
242
242
243
-
*Optional*. Most contributions will include a scope, such as a component, multiple components, test(s), or utilities. For example:
243
+
_Optional_. Most contributions will include a scope, such as a component, multiple components, test(s), or utilities. For example:
244
244
245
245
-`text-area`
246
246
-`dropdown, dropdown-group, dropdown-item`
@@ -328,6 +328,12 @@ By default, the PR body will be used for the commit message when squash merging,
328
328
329
329
### Visual snapshots
330
330
331
-
If the PR includes visual changes, once you are ready to run Chromatic to create visual snapshots, add the `pr ready for visual snapshots` label to the PR. Removing and re-adding the label is required to re-run snapshots, e.g. when pushing additional updates.
331
+
If the PR's linked issue contains the `visual changes` label **or** the PR contains [visual changes](#visual-changes), once you are ready to run Chromatic to create visual snapshots, add the `pr ready for visual snapshots` label to the PR. Removing and re-adding the label is required to re-run snapshots, e.g. when pushing additional updates.
332
332
333
333
If visual snapshots are not necessary for the PR (e.g. changes to doc, ci, storybook, etc.), you can add the `skip visual snapshots` label instead. The `skip visual snapshots` label can also be used to prevent re-running Chromatic after pushing minor cleanup changes before merging.
334
+
335
+
#### Visual changes
336
+
337
+
Visual changes include issues and/or PR's that introduce a visual alteration that is not backwards compatible. If the change could prevent a visual test from passing, the change should be considered a visual change. Visual changes should be coordinated with designers and have consistency across the design system in mind.
338
+
339
+
Visual changes can be a standalone change, or be introduced with breaking changes. For instance, [Split button consistent divider across appearances](https://github.com/Esri/calcite-design-system/issues/8142) and [List scales, padding, spacing, and font sizes](https://github.com/Esri/calcite-design-system/issues/7100).
0 commit comments