Skip to content

Latest commit

 

History

History
33 lines (29 loc) · 2.7 KB

rfc-process.md

File metadata and controls

33 lines (29 loc) · 2.7 KB
Raw

Requesting Features or Deprecations

ember-data participates in the RFC process (GitHub emberjs/rfcs). Most changes to the public API including new features, changes in behavior, or deprecations require community discussion and must go through this process.

While there is no guarantee that an RFC will be accepted, successful RFCs typically follow a pattern of iteration while gathering requirements, addressing feedback, and consensus building. The best RFCs are narrowly scoped with clear understanding of alternatives, drawbacks, and their effect on the community.

Here are a few suggestions of **steps to take before drafting your RFC** to best make your RFC successful.
Often this process will complete quickly, but when it does not, don't despair! Often the best ideas
take the longest to bake.
  1. Bring up your idea in the #dev-ember-data channel on Discord or with individual team members
  2. Reflect on any concerns, alternatives, or questions that arise from these discussions.
  3. Continue to discuss the idea, giving time for everyone to digest and think about it.
  4. Attend the weekly team meeting to discuss your idea
  5. Open an RFC issue to broaden and record the discussion if the idea needs more time for discussion and iteration.
    • label your issue with T-ember-data (or ask someone in #dev-ember-data to add the label if you lack the permission)
    • announce your issue in #dev-ember-data and anywhere else desired such as #news-and-announcements and twitter.
  6. Draft an RFC and share it with those you have been discussing the ideas with.
  7. Publish your RFC by opening a PR to emberjs/rfcs/
    • label your PR with T-ember-data (or ask someone in #dev-ember-data to add the label if you lack the permission)
    • announce your PR in #dev-ember-data and anywhere else desired such as #news-and-announcements and twitter.
  8. Attend weekly team meetings to discuss the RFC, continue iterating on the RFC, and help shepherd it to completion.
  9. Build a proof-of-concept. Sometimes this is best if it occurs alongside drafting the RFC, as it often informs the RFC design, known drawbacks, and alternatives. Often it will become incorporated in the final implementation.
  10. If you are able, help land the work in a release! It is not required that you implement your own RFC but often this is the best way to ensure that accepted RFCs are implemented in a timely manner.