Skip to content

32. Subjective & indirect goals

Robert Phair edited this page Aug 13, 2024 · 4 revisions

How should success of the CIP process “feel”?

The CIP process should be generally seen as sustainable.

Particularly, communications and relationships among CIP editors, Cardano companies, official developers, community developers, and observers should be easygoing and without any resentment over not having a “voice”.

This interaction should be frequent and comfortable enough that community members and Cardano employees alike should periodically express interest in joining the CIP process more officially as editors. Even though the CIP team won’t always require new editors, maintaining a healthy interest in others joining should always be considered beneficial.

Cardano’s standards model must be visible beyond the Cardano community.

A positively evolving CIP process — with a solid & growing CIP repository, plus documentation of positive experience & expectations in the Cardano community at large — will remain attractively visible to developers, companies, writers, investors, and analysts encountering Cardano coming from other blockchains.

This will be especially important through the launch of Cardano's governance process, considering that these efforts are founded in the CIP process. Beyond helping assure public accountability of these governance standards, a viable and well-documented on-chain governance will be highly beneficial to demonstrate to Cardano’s competitors and critics as well as blockchain regulators and legal / financial executives.

How do editors make sure there's enough time to do everything?

Keep aware of increasing time requirements

In the author's experience, at the time of this writing, regular time spent on CIP issues has been increasing about 50% per year since the beginning of 2021, due to the following effects which are not expected to change during Cardano's scaling & adoption period:

  • The range of subjects that CIPs cover is broadening steadily.
  • The number of CIPs pending review (open “pull requests”) has increased linearly.
  • The potential relationships between CIPs are increasing combinatorially.
  • Community discussion of CIPs has increased steadily, with new channels being added periodically.
  • CIPs are achieving more commercial impact (particularly NFTs, token metadata, voting & governance) and therefore have greater demand for usability and precision.
  • Many CIPs, especially the oldest and most popular ones, are now evolving multiple versions.
  • CIPs will be used in a wider variety of contexts (translations into other languages, repurposing onto web sites beyond GitHub).

Likewise in the author's experience, the CIP Process will only survive this scaling period with a balance between these two forces:

  1. existing CIP editors becoming more efficient with the tools of their trade (GitHub work & generated emails, efficient tagging to support cooperation with key developers & reviewers, and fluency in both private and public communication over CIP matters)
  2. new CIP editors willing to perform these duties enthusiastically, to replace any legacy editors who might retain editorial privileges while no longer being actively involved in the CIP process.

The key to a successful CIP process and editing team will be to retain editors who can spend at least a part of every work day on a balance of review, commentary, and developer engagement.

Keep an eye out for CIP process improvements

There is still great potential for automation that could well reduce the amount of time spent on routine editorial tasks, including:

  1. Building the top-level repository README file: currently edited by hand at biweekly intervals some time soon after each CIP meeting
  2. Assessing the PR queue by eye periodically, to identify PRs that might be stale / deprecated / abandoned, or simply needing support or reconnection with newly interested parties to progress

These are good examples to show how a bit of automation work might help reduce editor workload in the long run:

  1. The tables in the README file could be built from a GitHub CI script from merged PRs and appropriately tagged CIP pull requests;
  2. An appropriate tagging vocabulary can be established to ensure that every CIP PR is tagged according to its current state in a progressive "state machine", indicating "what is to happen next" ... so editors can make faster & more frequent decisions about what's needed to progress or close each PR.