Skip to content

Latest commit

 

History

History
56 lines (36 loc) · 3.82 KB

RFC-Template.md

File metadata and controls

56 lines (36 loc) · 3.82 KB

O3DE RFC Template

This RFC template should be used for any feature that is not a bug or a substantial reorganization of the O3DE product.

If you submit a pull request to implement a new feature without going through the RFC process, it may be closed with a polite request to submit an RFC first.

A hastily-proposed RFC can hurt its chances of acceptance. Low quality proposals, proposals for previously-rejected features, or those that don't fit into the near-term roadmap, may be quickly rejected, which can be demotivating for the unprepared contributor. Laying some groundwork ahead of the RFC can make the process smoother.

Although there is no single way to prepare for submitting an RFC, it is generally a good idea to pursue feedback from other project developers beforehand, to ascertain that the RFC may be desirable; having a consistent impact on the project requires concerted effort toward consensus-building.

The most common preparations for writing and submitting an RFC include talking the idea over on our Discord server, discussing the topic on our GitHub RFCs discussions page, and occasionally posting "pre-RFCs" on the GitHub RFCs discussion page. You may file issues in the RFCs repo for discussion, but these are not actively looked at by the teams.

As a rule of thumb, receiving encouraging feedback from long-standing project developers, and particularly members of the relevant sub-team is a good indication that the RFC is worth pursuing.

Summary:

Single paragraph explanation of the feature

What is the relevance of this feature?

Why is this important? What are the use cases? What will it do once completed?

Feature design description:

  • Explain the design of the feature with enough detail that someone familiar with the environment and framework can understand the concept and be able to explain it to others.

  • It should include at least one end to end example of how it will be used and specific details with outlying use cases.

  • If there is any new terminiology, it should be defined here.

Technical design description:

  • Explain the technical portion of the work in enough detail that members can implment the feature.

  • Explain any API or process changes required to implement this feature

  • This section should relate to the feature design description by reference and explain in more detail how it makes the feature edesign xamples work.

  • This should also provide detailed information on compatibility with different hardware platforms.

What are the advantages of the feature?

  • Explain the advantages for someone to use this feature

What are the disadvantages of the feature?

  • Explain any disadvantages for someone to use this feature

How will this be implemented or integrated into the O3DE environment?

  • Explain how this will be integrated within codebase of O3DE and any special library or technical stack reqruiements.

Are there any alternatives to this feature?

  • Provide any other designs that have been considered. Explain what the impact might be to not doing this.
  • If there is any prior art or approaches with other frameworks in the same domain, explain how they may have solved this problem or implemented this feature.

How will users learn this feature?

  • Detail how it can be best presented and how it is used as an extension or as a standalone tool used with O3DE.
  • Explain if and how it may change the approach of how individuals would use the platform and if any documentation must be changed or reorganized.
  • Explain how it would be taught to new and existing O3DE users.
  • Include any significant impacts to documentation such as; Required official video updates, required product screenshot updates (i.e. Editor UX changes), new documentation site sections.

Are there any open questions?

  • What are some of the open questions and potential scenarios that should be considered?