Skip to main content

Contributing

Foreword#

The Holium protocol is a community-driven project and first implementations and related utilities follow the free and open-source software (FOSS) principles. Be sure to check at our design principles for more details on the ethos.

In this regard, any amendment to the protocol can be discussed as a Holium Improvement Proposal (HIP) taking part in a framework described below.

The primary changelog can also be found on the current documentation.

Most discussions within the community takes place on Discord.

Repositories#

Early software related to the Holium protocol can be found on GitHub.

Main repositories include:

  • holium-rs: the reference CLI-enabled implementation of the protocol.
  • holium-rs-sdk: the SDK for developers of Rust transformations, detailed in a dedicated page.
  • HIPs: reference of Holium Improvement Proposals.

Holium Improvement Proposals (HIP)#

Project goal#

The Holium Improvement Proposals repository is meant to create a space where users and members of the Holium community can discuss and track standards for the protocol.

Proposal validation#

HIPs must pass some validation tests that can be enforced with the hip-validator.

Proposal lifecycle#

A Holium Improvement Proposal (HIP) is a design document providing information to the Holium community, or describing a new feature for Holium or its processes or environment. The HIP should provide a concise technical specification of the feature and a rationale for the feature. The HIP author is responsible for building consensus within the community and documenting dissenting opinions.

A HIP can go through 5 different phases:

Draft#

The first formally tracked stage of a HIP in development. A Pull Request is opened on the HIP repository by any contributor. Then, the HIP is merged by a maintainer into the HIP repository.

Maintainers are initially members of the Polyphene team. The circle of maintainers will be extended later according to conditions that are still to be defined.

A HIP should be written in Markdown format and a template should be followed. The template can be found on the HIP GitHub repository.

Review#

A HIP author marks a HIP as ready for and requesting peer review.

Last call#

This is the final review window for a HIP before moving to accepted. A maintainer will assign last call status at the request of a HIP author and set an end date, typically 14 days later.

A HIP is moved to accepted when it has been in last call for at least 2 weeks and any technical change that was requested has been addressed by the author. The process for implementation developers to decide whether to integrate a HIP into their clients is not part of the HIP process.

If this period results in necessary normative changes (at a maintainer’s discretion), it will revert the HIP to the review status.

Accepted#

The HIP becomes a final standard. An accepted HIP exists in a state of finality and should only be updated to correct errata and add non-normative clarifications.

Withdrawn#

The HIP authors have withdrawn the proposed HIP, or the HIP in draft or review is inactive for a period of 6 months or more. This state has finality and the HIP can not be resurrected using a similar HIP number. If the idea is continued at a later date, it is considered a new proposal.