Process Flow

Updated on: 14/6/2024

This page is still being developed by the Core Infrastructure Roadmap Working Group. The process flow is continuously being refined and will evolve as the group progresses. If you have any feedback or questions, please reach out to the working group.

Introduction

This process is not exhaustive and the Core Infrastructure Roadmap Working Group (CIR-WG) may from time to time make exceptions in order to accommodate work packages deemed critical to the future of the ecosystem. Additionally it is presumed that the committees and working groups may have additional communications beyond those required by the CIR-WG - these are simply defining the key steps to add, change, progress, and remove items from the Roadmap Roadmap.

Crucially, the CIR WG performs these all of these discussions in one of two forms:

  1. Triage - Triage may occur at any time.

  2. Cycle Planning - Cycle planning will occur once per CIP-1694 onchain vote/budgetary approval from the community.

Adding an Item (Triage Stage)

The criteria to be added to the roadmap should include any 3 of: CPS, business case document, security case document, CIP. However, not all items that have all of these will be considered Roadmap or sufficiently mature to prioritize. The CIR-WG may include or not include an item entirely at its own discretion.

It is presumed that this process is friendly to both software deliverables that can be shipped, and research-phase projects which may have different kinds of output (white papers, proof of concept, feasibility studies, etc).

From this step, the CIR-WG will recognize a champion as the comms leader/champion for a given roadmap item.

Progressing an Item (Cycle Planning)

Once an item is accepted onto the roadmap, there are additional requirements that must be met in order to show that the item is sufficiently mature for funding:

  1. A set of well-scoped deliverables (whether for research or for production software) ready to be made into a work-package (which may define future phases/partitions as well as feasibility)

  2. Acceptance of those deliverables by the relevant TWG and/or SIGs

Once these criteria have been met to the satisfaction of the CIR-WG - then all work packages that meet these criteria will be omnibussed into a proposed set of budgetary items.

This proposed set of work packages will then be routed to the TSC and budgetary committees, where a vendor and budget can also be assigned to the work package, and any final approvals can be made by Intersect*.

Following final approval and a CIP-1694 onchain vote, Intersect will receive funds and kick off activities.

*The exact nature of this final approval is to be determined.

Change Management & Delivery (Cycle planning)

Reviewing, accepting, and managing requirements changes for approved work packages is out of scope for the CIR-WG and is managed by Intersect at it’s sole discretion.

However, CIR-WG cycle planning sessions may include projects that have completed a work phase, and here the CIR-WG can choose if the next phase is sufficiently mature to proceed, or if priorities and changes are needed in the next set of work.

Removal and Regression of an Item (Cycle Planning)

During cycle planning, the CIR-WG may remove or regress an item in the following circumstances:

  • Item is complete/delivered

  • Item is no longer a priority

  • Research has determined that the solution is unsound or otherwise infeasible

Last updated