| hip | title | author | working-group | type | category | needs-council-approval | status | created | discussions-to | updated | requires | replaces | superseded-by |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
<HIP number (this is determined by the HIP editor)> |
<HIP title> |
<a list of the author’s or authors’ name(s) and/or username(s), or name(s) and email(s).> |
a list of the technical and business stakeholders' name(s) and/or username(s), or name(s) and email(s). |
<Standards Track | Informational | Process> |
<Core | Service | Mirror | Application> |
<Yes | No> |
<Draft | Review | Last Call | Active | Inactive | Deferred | Rejected | Withdrawn | Accepted | Final | Replaced> |
<date created on> |
<a URL pointing to the official discussion thread> |
<comma separated list of dates> |
<HIP number(s)> |
<HIP number(s)> |
<HIP number(s)> |
Please provide a short (~200 word) description of the issue being addressed.
The motivation is critical for HIPs that want to change the Hedera codebase or ecosystem. It should clearly explain why the existing specification is inadequate to address the problem that the HIP solves. HIP submissions without sufficient motivation may be rejected outright.
The rationale fleshes out the specification by describing why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages.
The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during the discussion.
Provide a list of "user stories" to express how this feature, functionality, improvement, or tool will be used by the end user. Template for user story: “As (user persona), I want (to perform this action) so that (I can accomplish this goal).”
The technical specification should describe the syntax and semantics of any new features. The specification should be detailed enough to allow competing, interoperable implementations for at least the current Hedera ecosystem.
All HIPs that introduce backward incompatibilities must include a section describing these incompatibilities and their severity. The HIP must explain how the author proposes to deal with these incompatibilities. HIP submissions without a sufficient backward compatibility treatise may be rejected outright.
If there are security concerns in relation to the HIP, those concerns should be explicitly addressed to make sure reviewers of the HIP are aware of them.
For a HIP that adds new functionality or changes interface behaviors, it is helpful to include a section on how to teach users, new and experienced, how to apply the HIP to their work.
The reference implementation must be complete before any HIP is given the status of “Final”. The final implementation must include test code and documentation.
Throughout the discussion of a HIP, various ideas will be proposed which are not accepted. Those rejected ideas should be recorded along with the reasoning as to why they were rejected. This both helps record the thought process behind the final version of the HIP as well as preventing people from bringing up the same rejected idea again in subsequent discussions.
In a way, this section can be thought of as a breakout section of the Rationale section that focuses specifically on why certain ideas were not ultimately pursued.
While a HIP is in draft, ideas can come up which warrant further discussion. Those ideas should be recorded so people know that they are being thought about but do not have a concrete resolution. This helps make sure all issues required for the HIP to be ready for consideration are complete and reduces people duplicating prior discussions.
A collections of URLs used as references through the HIP.
This document is licensed under the Apache License, Version 2.0 -- see LICENSE or (https://www.apache.org/licenses/LICENSE-2.0)