Who can contribute to the Comet Design System?
Direct contributions to the Comet system will typically come in the form of formal pull requests from the product team. Additional contributions may come in multiple other forms including but not limited to:
- A designer contributing component design via Sketch files, even though the component isn’t built in system code.
- A code-wary designer offering a new colors for charts & visualizations.
- An editor expanding the published word list (XLS) with 50 additional entries along with another Do/Don’t pair for a punctuation page.
Making Changes to the Comet system
While contributions come in many sizes, you can usually classify them as
Minor changes can include fixing a functional, visual, or accessibility defect, objective improvements (such as a focus state), performance, and browser support. For code, such changes can be submitted as a pull request to a designated branch in the system repository, reviewed, and implemented in the team’s normal workflow.
Substantial changes on the other hand can touch upon a system’s architecture, challenge widely applied conventions, or be too large for the normal workflow. These changes include:
- Alterations to the system’s visual languages built into constants woven across many CSS properties, mixins, and/or components.
- Proposing a new component.
- Enhancements that require breaking changes to markup and/or script.
- New documentation for concerns not already covered.
In these cases, we require the requests to be made through the Comet RFC process, so they can be properly evaluated for their effort, impact, and overall effect on the system.
Expectations of Quality
Due to the innumerable use case for the Comet system's parts there is a higher standard that must be met before we ship any new work. In addition, new components and features may trigger additional requirements that were not a consideration at the onset of a proposal.
System solutions must adhere to conventions that may include:
- Additional states and behaviors.
- Accessibility testing for contrast, size, color, and interactivity
- Considerations across contexts, such as themes, darker backgrounds, and viewport sizes.
- Composability in layout and adjacent to other elements.
Expectations on Documentation
No new features or components will be shipped in the Comet system without proper documentation on how, and when, to use them.
Example templates and writing guidelines can be found in the Comet drive folder. All documentation must go through both an editorial and informational reviews before being added to the system.
Common expectations on documentation may include:
- Visual and Code examples of all variations.
- Usage guidelines on how/when to use, including Do/Don't examples.
- Visual style guidelines if necessary.
- Editorial guidelines if necessary.
- Reference tables for class usage.