This repository tracks the ongoing evolution of YodaRT as the following:
- Goals for upcoming YodaRT releases.
- The tracking proposals to change YodaRT.
- The YodaRT evolution process that governs the evolution of Yoda.
- Commonly Rejected Changes, proposals that have been denied in the past.
This document describes goals for YodaRT on a per-release basis, that includes minor and major releases. YodaRT Evolution is to provide platform where all the developers and users of Yoda shall be involved with the community. We hope anybody no matter who you are is easy to contribute the Yoda in anyway that improved something.
The Yoda evolution process covers all the changes to the YodaRT and the YodaRT API, that contains:
- The built-in modules API changes.
- Changes to existing user interface features or APIs.
- Deprecations of existing features.
- The ShadowNode, Node.js runtime at low-end device, features or APIs.
And the smaller changes, such as bug fixes, optimizations and diagnostic improvements should be contributed via the normal contribution process on our YodaRT Contributing.
The Yoda Evolution process is to leverage the collective idea, insights and user experience of the Yoda community to improve the development experience for developers, and the user experience to the voice-based products that based on Yoda.
The Yoda TSC is responsible for the strategic direction of Yoda herself. TSC members initiate, participate in, and manage the public review of proposals and have the authority to accept or reject changes.
What goes into a review
The review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of YodaRT. Here are some questions you might want to answer in your review:
- What is your evaluation of the proposal?
- Is the problem being addressed significant enough to warrant a change?
- Does this proposal fit well with the feel and direction of YodaRT?
- How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Please state explicitly whether you believe that the proposal should be accepted into YodaRT.
How to propose a change
- Check prior proposals: the brain of human beings is always in activity, that there was some ideas comes up frequently, and maybe in active discussion on the yoda-evolution or have been discussed already and have joined the Commonly Rejected Proposals list. Please search the above places for context before proposing something new.
- Socialize the idea: propose a rough sketch of the idea what the solution looks like, etc., to gauge interest from the community.
- Develop the proposal: from starting with Yoda Evolution, using the proposal template, and continue to refine the proposal on your Pull Request on yoda-evolution. Prototyping an implementation and its uses along with the proposal is required because it helps ensure both technical feasibility of the proposal as well as validating that the proposal solves the problems it is meant to solve.
- Request a review: create a pull request to yoda-evolution to indicate to the TSC that you would like the proposal to be reviewed. When
the proposal is sufficiently detailed and clear, a member of TSC could label this pull request as
active review, then it could be discussed and accepted/rejected on next Yoda Dev Day(YDD).
The review process for a particular proposal begins when a TSC member leaves review comments on a pull request. The TSC member becomes the review manager for the proposal. Every proposal must be assigned a proposal number (if it is a new proposal), then enters the review queue.
The review manager will work with the proposal authors to schedule the review. Reviews usually last a single week, but can run longer for particularly large or complex proposals. Once the pull request is submitted, the proposal authors and review manager should be available to answer questions, address feedback, and clarify their intent during the review period.
After the review has completed, and marked as
active review, the review manager should guides the author to prepare the presentation on the next
Yoda Dev Day, where the proposal could be accepted, returned to feedback and rejected by TSC and developers. After Yoda Dev Day, the review manager
is responsible to update the proposal's state in yoda-evolution.
A given proposal can be in one of several states:
- Drafting: Yoda Evolution accepts someone is drafting their proposal online, which makes proposal authors could get feedback earlier.
- Awaiting review: The proposal is awaiting review, commonly when the proposal authors has completed the
Drafting, the TSC member is required to update the state to
awaiting reviewon yoda-evolution.
- Active review (The date of Yoda Dev Day): The proposal is undergoing public review at next Yoda Dev Day, when the review manager accepts a
proposal that can be reviewed publicly, review manager should label this pull request as
- Revision required: After a proposal with
active reviewstate and returned with feedbacks, the review manager should label this pull request as
- Accepted: After a proposal with
active reviewstate is accepted, the review manager should label this pull request as
- Rejected: After a proposal with
active reviewstate is rejected, the review manager should label this pull request as
rejectedand close this pull request.
- Implemented (Yoda Version): The proposal has been implemented with the version that implements this proposal.