Skip to content

Commit

Permalink
lang tweaks
Browse files Browse the repository at this point in the history
  • Loading branch information
rajsite committed Mar 28, 2024
1 parent 727af24 commit 6bc0778
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion docs/nimble-spright-requirements-adr.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down

0 comments on commit 6bc0778

Please sign in to comment.