Skip to content

Latest commit

 

History

History
92 lines (62 loc) · 3.06 KB

TEMPLATE-IP.md

File metadata and controls

92 lines (62 loc) · 3.06 KB
Raw
IP ID Status Category Created Replaces Requires
<number>
Draft | Review | Approved | Rejected | Superseded
NEAR Social | Proof of Personhood | ...
YYYY-MM-DD
ip-xyz
ip-xyz

IP-: <Title>

Summary

"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the problem or feature. Keep it short. Max 200 words.

Context

This section contains all the context one needs to understand the current state, and why there is a problem. It should be as succinct as possible and introduce the high level idea behind the solution.

Proposal

This section records the decision that was made and how it should work. It is best to record as much info as possible from the discussion that happened. This aids in not having to go back to the Pull Request and comments to get the needed information. You can include diagrams.

  • What new data structures are needed, what data structures will be changed?
  • What are the efficiency considerations (time/space)?
  • What are the expected access patterns (load/throughput)?
  • Are there any privacy considerations?
  • If the change is large, how will the changes be broken up for ease of review?

User requirements

Specify expected user behavior or a process structure

Outcomes

Here are some common questions that get answered as part of the detailed design:

  • What are the expected outcomes?
  • What systems will be affected?
  • Are there any observability needs?
  • Are there any security considerations (social, systematic, engineering, ...)?
  • Are any of these changes in conflict with the existing solution?
  • Does this proposal require coordination with other teams?

Alternative Approaches

This section contains information around alternative options that are considered before making a decision. It should contain a explanation on why the alternative approach(es) were not chosen.

Consequences

This section describes the consequences, after applying the decision. All consequences should be summarized here, not just the "positive" ones.

Positive

Negative

Neutral

Backwards Compatibility

All proposals that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The doc must explain how the author proposes to deal with these incompatibilities. Submissions without a sufficient backwards compatibility treatise may be rejected outright.

Further Discussions

This section should contain potential followups or issues to be solved in future iterations (usually referencing comments from a pull-request discussion).

Open Questions and Comments

  • potential future improvements
  • summary of open discussion

References

Are there any relevant PR comments, issues that led up to this, or articles referenced for why we made the given design choice? If so link them here!

  • {reference link}

Changelog

Copyright

Copyright and related rights waived via CC0.