AIP 1: Proposal How-To

[dmosites]

Summary

To cultivate an open development process, we have introduced a proposal system that follows the style of existing open source projects and those throughout the blockchain development community.

Improvement proposal categories may include new protocols, smart contracts, maker software, network tooling, applications, and tokenomics. We are excited to collaborate with the token and developer communities on the future of the AirSwap network.

Specification

The proposal structure and process are as follows.

Structure

Each proposal includes a summary, specification, rationale, and copyright.

• Summary — A short (200 word) summary describing the proposal.
• Specification — Technical specification for the proposal.
• Rationale — Motivations, justifications, arguments for and against.
• Copyright — All proposals are public domain via CC0.

Process

Each proposal follows a process from idea to implementation.

• Idea — Author tests and discuss initial idea
• Draft — Author drafts and iterates on the idea
• Voting — Author proposes a vote to finalize the proposal
• Acceptance — Contributors prioritize and implement the proposal

A proposal is labeled Draft, Proposed, Accepted, or Rejected depending on where it is in the process.

Voting

Once the author has decided that the proposal is ready, the author may create a new vote referencing the relevant GitHub issue. The vote should run for 3 days minimum. Only proposals created by authors that hold at least 100 AST will be visible for voting. Visit https://vote.airswap.io/ to create a vote.

Acceptance

Once the vote has been completed, the proposal is considered finalized and assessed by core contributors. Based on requirements and feasibility, contributors will either reject or accept the proposal for prioritization and implementation.

Rationale

Our goals are to create more transparency, involve the community, and generate ideas for AirSwap network development. AIPs give the community a process to develop and finalize proposals to core contributors on an ongoing basis.

Metadata. We predict that proposals will be a mix of onchain and offchain development work in addition to contributor and community activities. Therefore, there is a lesser need for metadata and automation for the initial iteration of the process so we’ve opted to forego it.

Discussions. We considered several alternative discussion platforms but decided that our requirements are met most easily by the GitHub Issues feature. If the proposal process or requirements change we will consider alternative platforms.

Copyright

Copyright and related rights waived via CC0.