Skip to content

Latest commit

 

History

History
151 lines (98 loc) · 4.43 KB

qip-specification.md

File metadata and controls

151 lines (98 loc) · 4.43 KB
Raw

QIP Frontmatter Specification

1. QIP

Initially left blank and is assigned after the PR is submitted with the numerical ID of the pull request.

Having the QIP ID reflect the pull request allows for easier tracking and avoids QIP ID collisions.

2. Title

The title of the QIP that describes the rest of the content.

3. Status

Status hierarchy is concatenated into a string with forward slashes.

  1. draft
    1. incomplete
    2. abandoned
    3. deferred
    4. withdrawn
    5. rejected
  2. proposal
    1. open
    2. review
    3. accepted
      1. available
      2. in_development
      3. awaiting_hardfork
      4. completed
    4. deferred
    5. rejected

3.1. Drafts

3.1.1. Incomplete (Open)

Once an idea is vetted through the community, it can be formed into an initial draft.

Drafts open to feedback are marked as incomplete and remain this state until fleshed out and ready for the request for proposal.

3.1.2. Abandoned

If there's been no movement on a draft, it may be marked as abandoned during QIP maintenance.

3.1.3. Deferred

A draft may be deferred for any number of reasons, such as new information that's presented itself or is still developing which may make the draft unsuitable.

3.1.4. Withdrawn

At any point during the draft process, it can be withdrawn.

3.1.5. Rejected

It's possible a draft gets merged, but doesn't meet the criteria for a QIP. In this case it may be rejected.

3.2. Proposals

Before a proposal can be opened, it must first complete the draft stage and go through a request for proposal.

3.2.1. Open

Public comment is invited on open proposals. Once the proposal is sufficiently mature it will be moved by the QRL Foundation maintainers to the next stage.

3.2.2. Under review

Proposals under discussion will be considered at the next QRL Developer meeting. Particularly complex or in depth QIPs may require a separate meeting or face-to-face discussions by the QRL development team prior to decisions being made as to the outcome. As this point they may be returned to 2.1 for further refinement.

3.2.3. Accepted

Accepted proposals require development until such a point when they are released or they are ready for release at the next hard fork of the network. As such, an accepted QIP may be in one of four states:

  1. Available (for a developer/team to take on engineering the QIP; avoiding duplication of effort)
  2. In development
  3. Awaiting hard fork
  4. Completed

3.2.4. Deferred

Deferred proposals have merit to the project but for operational reasons are held back from entering development. Deferred proposals may enter development at a later date or may move into a different category as the network matures.

3.2.5. Rejected

Rejected proposals will not enter development without commencing the QIP process from the beginning and re-working the proposal.

4. Author

The author of the QIP.

5. Layer

QRL Improvement Proposals are for core improvements, either to the network or security layers. This can be described as core, core/networking or core/security. Most use core.

There is also a meta layer, which is for fundamental changes to the QIP Process, including its governance and structure.

6. Comments URI

Full URI of the comments.

7. Comments URI Summary

Full URI of the comment summary made after the proposals review process.

8. Created

Date that the draft was created.

9. Modified

Date that the QIP was modified.

10. Requires

The QIPs that this QIP depends on, by UUID.

11. Replaces

The QIPs that this QIP replaces, by UUID.

12. Superseded By

The QIPs that supersedes this QIP, by UUID.