From 6bc0778e04aee112c7d1a07c876ae6648adcace3 Mon Sep 17 00:00:00 2001 From: rajsite Date: Thu, 28 Mar 2024 17:55:53 -0500 Subject: [PATCH] lang tweaks --- docs/nimble-spright-requirements-adr.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/nimble-spright-requirements-adr.md b/docs/nimble-spright-requirements-adr.md index 144598c9f2..550696a626 100644 --- a/docs/nimble-spright-requirements-adr.md +++ b/docs/nimble-spright-requirements-adr.md @@ -39,7 +39,7 @@ While Nimble contributors may opt to create their component as ["incubating"](ht - The Nimble and Spright packages will be part of the same build, use the same infrastructure, and share the same dependency version management. Spright packages will depend on the Nimble packages. - Code in Spright packages will be co-owned and reviewed by the Design System team and the contributing team. - The goal of spright contributions is to be technically rigorous. To follow modern HTML, CSS, and TypeScript coding styles and follow Nimble's Contributing guidelines, CSS Best Practices, naming conventions, token usage, etc. - - Nimble developers remain as co-owners to enforce technical quality of implementation. Long-term components live in the Nimble monorepo and have to be patched to follow common patterns, updated with dependencies, supported on test infrastructure, and continually released. This is only mantainable when all code meets the same technical implementation bar. + - Nimble developers remain as co-owners to enforce technical quality of implementation. All the spright components live in the Nimble monorepo and have to be patched to follow common patterns, updated with dependencies, supported on test infrastructure, and continually released. This is only mantainable when all code in the monorepo meets the same technical implementation bar. - Nimble developers can (and will) give consulting on feature selection (api design for properties / attributes / methods / events, level of accessibility support for aria / keyboard / mouse, interaction design, visual design), while ultimately deferring to the spright contributor for feature selection of what to implement. - Components that _could/should_ go in Nimble may still opt to go in Spright if the contributing team needs to defer or omit certain work (like creating a full accessibility/interaction plan) to meet a deadline.