Open UIOpen UI Working Mode
Welcome to the Open UI working mode and process guide to paving inclusive and accessible best practices into web browsers based on web frameworks and web developer norms.
Open UI is a Web Incubator Community Group (WICG) project. Our goal is to specify web components and controls. We standardize names, anatomies and behaviors based on common patterns in design systems and component libraries.
Open UI specifications can result in two types of outcomes: Web Components and Graduated Specifications. We make standard web components which you can use in a web application for all finished open UI components. Additionally, and depending on the component, we work with standards bodies like WHATWG, and the W3C to add those specifications to HTML, ARIA, and CSS, and work with browser engine teams to add those features to browser engines like WebKit, Chromium and Gecko.
This document covers how Open UI works, including guidance on how to work on standards with open UI, and norms about how Open UI works with WHATWG/HTML, CSS WG, ARIA WG, WPT, and other groups.
Stages
We follow a five stage process outlined in the Open UI Stages proposal March 2021. These stages are:
| # | Stage Name | Purpose | Entrance Criteria | Entrance Signifies | Exit Criteria |
|---|---|---|---|---|---|
| 0 | Research | Share research and synthesize idea. | An idea has been suggested, an issue has been opened. | N/A | A champion has been identified. Research incorporating historical precedence and stakeholder perspectives has been performed and summarized in a proposal. Research and proposal haves approval from two Open UI editors or chairs. |
| 1 | Editor’s Draft | Agree on precise description of component within Open UI. | Initial draft has been written, covering use cases, anatomy, properties, and behaviors. | Open UI plans to work on this component. | Spec has been reviewed and approved by two Open UI editors or chairs. |
| 2 | Community Draft | Get review from stakeholders and incorporate feedback. | Open UI has approved the Editor’s Draft for additional review from external groups and individuals. | Open UI is seeking broad input. | Spec has sign off from stakeholders including ARIA, I18n, privacy, WHATWG, CSSWG, Browser Implementers, Web Developers, library authors, and other stakeholders. |
| 3 | Recommendation | Shepherd proposal to its final state. | The champion has built consensus with community stakeholders. | This will be implemented. Don’t use the implementation in production. | A decision on whether to add component to the web platform. Web component is implemented and/or specification graduated to a standards body. Conformance tests and web developer documentation are written. |
| 4 | Finished | Indicate that the component is implemented. | Component has a stable implementation or specification. | You can use the web component in production. | N/A |
Read more about how to follow this process in the Getting Involved Guide.
Process for making changes to Open UI
In order to ensure transparency and that we have consensus from the community each change to Open UI should come through a pull request to the main repository: https://github.com/openui/open-ui.
Note: Consensus on individual PRs and issues does not equate to the specification’s current stage
Process for resolving disagreement on PRs
If there is a disagreement on the requirements for merging a PR, then the following should happen:
Add the label
agenda+and be prepared to speak to it on the upcoming telecon where your agenda item is discussed.Note: even if it was successfully merged, it will still be raised on the call to draw attention to it in order to ensure if people disagree they can raise their concerns.
If there is a disagreement, a resolution will be sought on the telecon. In order to gain consensus it is the majority opinion of those on the call.
Note: Resolutions can be over-turned upon new information becoming available. Note: It is helpful for efficiency to have denoted in the PR or issue the proposed options so that you can quickly cover the options and the group can discuss it and vote on it.
Process for Selection of Community Group Chairs
Upon the need or desire for adding/changing co-chairs the process will be as such.
- Propose in an issue your chair nomination
- Set label to
agenda+ - The nominee should already be an editor
- On the telecon there will be a formal vote for consensus