Skip to content

Latest commit

 

History

History
61 lines (40 loc) · 2.83 KB

0000-template.md

File metadata and controls

61 lines (40 loc) · 2.83 KB
  • Start Date: (fill me in with today's date, YYYY-MM-DD)
  • Approvers (please review by EOD YYYY-MM-DD):
  • Decider:
  • RFC PR: (leave this empty)

Summary

One paragraph explanation of the proposal.

Motivation

Why are we doing this? What use cases does it support? Why does it make sense for this to be part of the design system instead of something applications implement themselves?

Please focus on explaining the motivation so that if this RFC is not accepted, the motivation could be used to develop alternative solutions. In other words, explain the problem or constraints you are trying to solve without coupling them too closely to the solution you have in mind.

If your proposal is a design for a new component that has already been scoped by the Norton Design System team, please provide a link to its specification here.

Detailed design

This is the bulk of the RFC. Explain the design in enough detail for somebody familiar with the Norton Design System to understand it, and for somebody familiar with the implementation to implement. This should get into specifics and corner-cases, and include examples of how the feature is used. Any new terminology should be defined here.

A good approach is to explain the proposal as if it was already part of the Norton Design System and you were teaching it to another developer. That generally means:

  • Introducing new named concepts or components.
    • Note: names may undergo many changes (naming is hard), but the description of functionality should be stable.
  • Explaining the feature largely in terms of examples of how someone would use it.
  • Explaining how Norton engineers should think about the proposal or feature, and how it should impact the way they use the Norton Design System. It should explain the impact as concretely as possible.
  • If applicable, provide sample error messages, deprecation warnings, or migration guidance.
  • If applicable, describe the differences between teaching this to experienced developers and completely new developers.

Avoid the impulse to write actual code or proofs of concept. If you're uncertain whether something is possible to implement or how it would be implemented, say that and move on.

Drawbacks

Why should we not do this? Please consider:

  • Implementation cost in terms of size, complexity, and maintenance.
  • How it will impact other teams outside of engineering.
  • The cost of migrating applications to the proposed solution.

There are tradeoffs to choosing any path, please attempt to identify them here.

Alternatives

What other designs have been considered? What is the impact of not doing this?

Adoption strategy

If we implement this proposal, how will existing applications adopt it?

Unresolved questions

Optional, but suggested for first drafts. What parts of the design are still TBD?