chore: sync content to repo (#10348)

Co-authored-by: nilbuild <4921183+nilbuild@users.noreply.github.com>
2026-09-24 15:00:31 +08:00 · 2026-09-17 10:12:21 +02:00
parent 4dc005c914
commit 1ba884560e
39 changed files with 36 additions and 49 deletions
@@ -1,3 +1,3 @@
 # Accessibility Testing
- 
+
 Accessibility testing checks that components meet standards like WCAG, covering things like sufficient color contrast, proper keyboard navigation, and correct screen reader labeling. It combines automated tools, like axe or Lighthouse, with manual testing using assistive technology to catch issues automated tools miss. Testing accessibility at the component level ensures every product built from the design system inherits accessible behavior by default.
@@ -7,6 +7,4 @@ Visit the following resources to learn more:
 - [@article@Introduction to Web Accessibility](https://www.w3.org/WAI/fundamentals/accessibility-intro/)
 - [@article@What is Accessibility? by Mozilla](https://developer.mozilla.org/en-US/docs/Learn/Accessibility/What_is_accessibility)
 - [@article@Accessibility Principles](https://www.w3.org/WAI/fundamentals/accessibility-principles/)
- [@article@WebAIMs Website (Web Accessibility In Mind)](https://webaim.org/)
- [@article@WAVE Web Accessibility Evaluation Tool](https://wave.webaim.org/)
- [@feed@Explore top posts about Accessibility](https://app.daily.dev/tags/accessibility?ref=roadmapsh)
+- [@article@WebAIMs Website (Web Accessibility In Mind)](https://webaim.org/)
@@ -1,3 +1,3 @@
 # Code Style
- 
+
 Code style refers to the formatting and structural conventions followed when writing a design system's component code, such as naming conventions, file structure, and formatting rules enforced by tools like ESLint or Prettier. Consistent code style makes the codebase easier to read and maintain as multiple contributors add or update components. It's usually enforced automatically through linting tools rather than left to manual review.
@@ -1,3 +1,3 @@
 # Commit Guidelines
- 
+
 Commit guidelines define a consistent format for writing commit messages when contributing code to a design system, such as the Conventional Commits format that prefixes messages with types like "feat" or "fix." Consistent commit messages make it easier to generate changelogs automatically and to understand a project's history at a glance. They're often enforced through automated checks that reject commits not following the required format.
@@ -1,3 +1,3 @@
 # Communication Channel
- 
+
 A communication channel is the primary medium a design system team uses for day-to-day questions and announcements, such as a dedicated Slack channel or Microsoft Teams space. It gives consuming teams a fast way to ask questions or report issues without going through formal ticketing for every small query. Having a clearly designated channel prevents design system discussions from getting scattered across multiple informal threads.
@@ -1,3 +1,3 @@
 # Community Meetings
- 
+
 Community meetings are regularly scheduled sessions where design system maintainers and the teams that consume the system come together to discuss updates, gather feedback, and address concerns. They give consuming teams a direct channel to raise issues or request new components rather than relying solely on written tickets. These meetings also help build a sense of shared ownership over the design system across the organization.
@@ -1,3 +1,3 @@
 # Component Catalog
- 
+
 A component catalog is a searchable, browsable reference of every component in a design system's code library, usually generated automatically from the component code itself. Tools like Storybook are commonly used to build a catalog that shows each component's variants, props, and usage examples in an interactive interface. It gives developers a live reference to check component behavior without reading the underlying source code.
@@ -1,3 +1,3 @@
 # Contribution Guidelines
- 
+
 Contribution guidelines document the process for proposing, reviewing, and approving changes to a design system, whether on the design side or the development side. They typically cover how to submit a new component, who reviews proposed changes, and what criteria a contribution needs to meet before acceptance. Clear contribution guidelines make it possible for people outside the core design system team to safely add or update components.
@@ -7,6 +7,4 @@ Visit the following resources to learn more:
 - [@opensource@Collection of Open Source Design Systems](https://github.com/alexpate/awesome-design-systems)
 - [@article@Material Design (Google)](https://material.io/)
 - [@article@Carbon Design System (IBM)](https://carbondesignsystem.com/)
- [@article@Atlassian Design System](https://atlassian.design/)
- [@article@Polaris Design System (Shopify)](https://polaris.shopify.com/)
- [@article@Gov.uk Design System](https://design-system.service.gov.uk/)
+- [@article@Atlassian Design System](https://atlassian.design/)
@@ -4,6 +4,5 @@ A component library is just a collection of visuals i.e. colours, button styling

 Visit the following resources to learn more:

- [@article@A Design System: So Much More Than A Component Library](https://www.architech.ca/a-design-system-so-much-more-than-a-component-library)
 - [@article@Design System vs UI Component Library vs Brand Style Guide](https://prototype.net/blog/design-system-component-library-style-guide)
 - [@article@Design Systems vs Pattern Libraries vs Style Guides vs Component Libraries](https://www.uxpin.com/studio/blog/design-systems-vs-pattern-libraries-vs-style-guides-whats-difference/)
@@ -1,3 +1,3 @@
 # FAQs
- 
+
 FAQs are a curated list of frequently asked questions and their answers, covering the most common issues or points of confusion that consuming teams run into when using the design system. Maintaining an FAQ reduces repetitive support requests by pointing people to existing answers before they need to ask directly. It's usually kept alongside the main documentation and updated as new common questions emerge.
@@ -1,3 +1,3 @@
 # Input Checkbox
- 
+
 An input checkbox component lets users select one or more options from a set of choices, toggling between a checked and unchecked state. It usually supports an indeterminate state as well, used when a checkbox represents a partially selected group of sub-options. Checkboxes are built with clear focus and disabled states to remain accessible via keyboard navigation.
@@ -1,3 +1,3 @@
 # Input Radio
- 
+
 An input radio component lets users select exactly one option from a group of mutually exclusive choices. Radio buttons in a group share a common name so that selecting one automatically deselects the others. They are used instead of a dropdown when all options should be visible at once for easier comparison.
@@ -1,3 +1,3 @@
 # Input Switch
- 
+
 An input switch, also called a toggle, lets users turn a single setting on or off, typically represented as a sliding control rather than a checkbox. It's commonly used for binary settings, like enabling notifications, where the on and off states have a clear, immediate effect. Switches usually include a visual and sometimes textual indicator of the current state.
@@ -1,3 +1,3 @@
 # List
- 
+
 A list component displays a vertical sequence of items, each following the same layout, such as a list of contacts or notifications. It often supports variants like showing an icon, avatar, or action button alongside each item's text. Lists are commonly built to handle large datasets efficiently through virtualization when the number of items is high.
@@ -1,3 +1,3 @@
 # Loading Indicator
- 
+
 A loading indicator communicates to the user that content is being fetched or processed, typically shown as a spinner, progress bar, or skeleton screen. It prevents the interface from appearing frozen or broken during delays caused by network requests or heavy computation. Design systems usually offer a few variants, such as a small inline spinner and a full-page loading state.
@@ -1,3 +1,3 @@
 # Logging
- 
+
 Logging, in the context of a design system, means recording events and errors that occur when components are used in production, such as a component failing to render or receiving invalid props. Reviewing these logs helps the design system team catch bugs that only surface in real-world usage across different consuming products. It complements testing done before release by revealing issues that appear once components run at scale.
@@ -7,5 +7,4 @@ Visit the following resources to learn more:
 - [@article@Design Systems: Step-by-Step Guide to Creating Your Own](https://www.uxpin.com/create-design-system-guide/)
 - [@article@Does My Organization Need a Design System?](https://www.method.com/insights/does-my-organization-need-a-design-system/)
 - [@video@Introducing Design Systems Into Chaos - Diana Mounter, GitHub](https://www.youtube.com/watch?v=FZSi1bK-BRM)
- [@video@Design Systems, when and how much?](https://www.youtube.com/watch?v=Hx02SaL_IH0)
- [@video@Create a Design System with Figma - Full Course](https://www.youtube.com/watch?v=RYDiDpW2VkM)
+- [@video@Design Systems, when and how much?](https://www.youtube.com/watch?v=Hx02SaL_IH0)
@@ -1,3 +1,3 @@
 # Milestones
- 
+
 Milestones are specific checkpoints within a design system's roadmap that mark the completion of a significant piece of work, such as shipping a new component library version or completing an accessibility audit. They break a larger roadmap into measurable stages, making it easier to track progress over time. Milestones are often tied to specific dates or releases to create accountability.
@@ -1,3 +1,3 @@
 # Modal
- 
+
 A modal component displays content in a layer above the main page, requiring user interaction before returning to the underlying content, commonly used for confirmations or focused tasks. It typically includes a backdrop that dims the rest of the page and traps keyboard focus within the modal while it's open. Modals need careful accessibility handling to ensure focus returns to the triggering element once closed.
@@ -1,3 +1,3 @@
 # Open Hours
- 
+
 Open hours are scheduled time blocks during which the design system team is available for live questions, pairing sessions, or troubleshooting help from consuming teams. They give teams a predictable way to get direct support without waiting for a response in a ticket or chat channel. Open hours work especially well for onboarding teams that are new to using the design system.
@@ -4,5 +4,4 @@ Pilots are one of the best ways to put your design system through its paces, esp

 Visit the following resources to learn more:

- [@official@Design Systems: Pilots & Scorecards](https://danmall.com/posts/design-systems-pilots-scorecards/)
 - [@article@How to run a design system pilot](https://university.obvious.in/product-design/design-system/how-to-run-a-design-system-pilot)
@@ -1,3 +1,3 @@
 # Plugins
- 
+
 Plugins are add-on tools that extend a design editor's functionality, such as automating token synchronization, checking accessibility contrast, or generating code snippets from design components. They reduce manual work by connecting the design tool directly to other parts of the design system workflow, like a token repository or a documentation site. Teams often build custom plugins tailored to their specific design system setup.
@@ -1,3 +1,3 @@
 # PR Templates
- 
+
 A PR template is a predefined structure that appears when someone opens a pull request, prompting contributors to fill in information like a description of the change, screenshots, and a checklist of required steps. It ensures every contribution includes the context a reviewer needs, rather than relying on contributors to remember what to include. Design systems use PR templates to keep the review process consistent as the number of contributors grows.
@@ -1,3 +1,3 @@
 # Release Strategy
- 
+
 A release strategy defines how and how often new versions of a design system get published, including whether releases happen on a fixed schedule or whenever changes are ready. It also covers how breaking changes get communicated and how long older versions remain supported. A clear release strategy helps consuming teams plan when to upgrade without being caught off guard by unexpected changes.
@@ -1,3 +1,3 @@
 # Roadmap
- 
+
 A roadmap, in project management terms, is a high-level plan that outlines what a design system team intends to build or improve over a given period, such as new components or major token changes. It helps set expectations with consuming teams about what's coming and in what order. Roadmaps are typically reviewed and adjusted regularly as priorities shift based on feedback and adoption needs.
@@ -1,3 +1,3 @@
 # Semantic Versioning
- 
+
 Semantic versioning is a version numbering convention, formatted as major.minor.patch, used to communicate the type of change made in each release of a design system's code. A major version bump signals a breaking change, a minor version adds new functionality without breaking existing usage, and a patch fixes bugs. Following this convention lets teams consuming the design system understand the risk of upgrading to a new version at a glance.
@@ -1,3 +1,3 @@
 # Service and Health Metrics
- 
+
 Service and health metrics track the overall reliability and performance of a design system as a product in its own right, such as build times, uptime of documentation or component hosting, and how quickly reported bugs get resolved. These metrics give the team an objective view of how well the design system is being maintained, beyond just component-level usage. They're often reported to stakeholders as evidence of the system's ongoing value.
@@ -1,3 +1,3 @@
 # Tabs
- 
+
 A tabs component lets users switch between different views or sections of content within the same page area, without navigating to a new page. Each tab typically shows a label and, when selected, displays its associated content while hiding the others. Tabs need keyboard support so users can navigate between them using arrow keys.
@@ -1,3 +1,3 @@
 # Ticketing
- 
+
 Ticketing refers to the system used to track individual tasks, bugs, and feature requests related to a design system, typically using tools like Jira or Linear. Each ticket captures a specific piece of work, such as adding a new component variant or fixing an accessibility issue, along with its status and assignee. A well-maintained ticketing system gives the team and stakeholders visibility into what's currently being worked on.
@@ -1,3 +1,3 @@
 # Toast
- 
+
 A toast component displays a brief, temporary message that appears and disappears automatically, typically used for confirmations like "Changes saved" or lightweight error notices. Unlike a banner, a toast floats above the page content and doesn't require the user to dismiss it manually. Toasts are commonly positioned in a corner of the screen and stack when multiple messages appear at once.
@@ -1,3 +1,3 @@
 # Tooling Analytics
- 
+
 Tooling analytics measure how the design system's own supporting tools get used, such as how often a Figma plugin runs, how frequently the documentation site is visited, or how often the component catalog is searched. This data helps the team understand which tools deliver value and which ones go unused. It informs decisions about where to invest further tooling effort.
@@ -1,3 +1,3 @@
 # Tooltip
- 
+
 A tooltip component displays a small piece of contextual information when a user hovers over or focuses on an element, typically used to explain an icon-only button or provide extra detail. It appears near the triggering element and disappears once the user moves away or shifts focus elsewhere. Tooltips need to be accessible via keyboard focus, not just mouse hover, to work for all users.
@@ -4,5 +4,4 @@ As it relates to a design system, a UI Kit is a representation of coded componen

 Visit the following resources to learn more:

- [@article@Design System vs UI Kit](https://uigstudio.com/insights/design-system-vs-ui-kit)
 - [@article@Your sketch library is not a design system](http://bradfrost.com/blog/post/your-sketch-library-is-not-a-design-system/)
@@ -1,3 +1,3 @@
 # Unit Testing
- 
+
 Unit testing means writing automated tests that verify individual components behave correctly in isolation, such as checking that a button calls its click handler or that a checkbox toggles its state correctly. These tests catch regressions early when a component's code changes, before the change reaches production. Design systems rely heavily on unit tests since a bug in a shared component can affect every product that uses it.
@@ -5,7 +5,5 @@ Logo usage guidance provides rules for proper implementation to maintain brand c
 Visit the following resources to learn more:

 - [@article@Logo Usage Best Practices](https://99designs.com/blog/tips/logo-usage-guidelines/)
- [@article@Brand Guidelines Development](https://designsystem.digital.gov/design-tokens/logo/)
 - [@article@Trademark and Logo Legal Guidelines](https://www.uspto.gov/trademarks-getting-started/trademark-basics)
- [@article@Brand Identity Protection](https://www.brandfolder.com/blog/brand-guidelines)
- [@feed@Explore top posts about Brand Management](https://app.daily.dev/tags/branding?ref=roadmapsh)
+- [@article@Brand Identity Protection](https://www.brandfolder.com/blog/brand-guidelines)
@@ -1,3 +1,3 @@
 # Version Control
- 
+
 Version control, in the context of design tooling, means tracking changes to design files over time, similar to how developers track code changes, so past states can be reviewed or restored. Some design editors have built-in version history, while others rely on external plugins or file naming conventions to track changes. This becomes especially important as multiple designers contribute to the same design system files.
@@ -6,6 +6,4 @@ Visit the following resources to learn more:

 - [@article@Creating Brand Vision](https://www.interaction-design.org/literature/article/branding-in-ux)
 - [@article@Vision-Driven Design Systems](https://bradfrost.com/blog/post/the-design-system-ecosystem/)
- [@article@Brand Strategy for Design](https://alistapart.com/article/creating-a-brand-identity/)
- [@article@Purpose-Driven Design](https://designsystem.digital.gov/design-tokens/brand/)
- [@feed@Explore top posts about Brand Strategy](https://app.daily.dev/tags/branding?ref=roadmapsh)
+- [@article@Brand Strategy for Design](https://alistapart.com/article/creating-a-brand-identity/)
@@ -5,5 +5,4 @@ Atomic design (by Brad Frost) is a mental model to help you think of user interf
 Visit the following resources to learn more:

 - [@article@Atomic Design Principles & Methodology 101](https://xd.adobe.com/ideas/process/ui-design/atomic-design-principles-methodology-101/)
- [@article@Atomic Design Methodology](https://atomicdesign.bradfrost.com/chapter-2/)
- [@article@Atomic Design and UI Components: Theory to Practice](https://blog.bitsrc.io/atomic-design-and-ui-components-theory-to-practice-f200db337c24)
+- [@article@Atomic Design Methodology](https://atomicdesign.bradfrost.com/chapter-2/)