Skip to content

Latest commit

 

History

History
74 lines (52 loc) · 2.76 KB

proposal-template.md

File metadata and controls

74 lines (52 loc) · 2.76 KB

Meta

  • Name: (fill in the feature name: My Feature)
  • Start Date: (fill in today's date: YYYY-MM-DD)
  • Author(s): (Github usernames)
  • Status: Draft
  • RFC Pull Request: (leave blank)
  • Relevant Issues:
  • Supersedes: (put "N/A" unless this replaces an existing RFC, then link to that RFC)

Summary

One paragraph explanation of the feature.

Definitions

Make a list of the definitions that may be useful for those reviewing. Include phrases and words that OpenFGA authors or other interested parties may not be familiar with.

Motivation

  • Why should we do this?
  • What use cases does it support?
  • What is the expected outcome?

What it is

This provides a high level overview of the feature.

  • Define any new terminology.
  • Define the target persona: authorization model author, application developer, platform operator, platform implementor, and/or project contributor.
  • Explaining the feature largely in terms of examples.
  • If applicable, provide sample error messages, deprecation warnings, or migration guidance.
  • If applicable, describe the differences between teaching this to existing users and new users.

How it Works

This is the technical portion of the RFC, where you explain the design in sufficient detail.

The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work.

Migration

This section should document breaks to public API and breaks in compatibility due to this RFC's proposed changes. In addition, it should document the proposed steps that one would need to take to work through these changes. Care should be give to include all applicable personas, such as application developers, authorization platform operators, DevSecOps users and end users whose lives depend on the authorization system.

Drawbacks

Why should we not do this?

Alternatives

  • What other designs have been considered?
  • Why is this proposal the best?
  • What is the impact of not doing this?

Prior Art

Discuss prior art, both the good and bad.

Unresolved Questions

  • What parts of the design do you expect to be resolved before this gets merged?
  • What parts of the design do you expect to be resolved through implementation of the feature?
  • What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC?