Please describe your proposed solution.

What are CIPs, and why does Cardano needs a CIP process and editors?

Cardano Improvement Proposals (CIPs) fulfil the same role for Cardano as the standards of other blockchains, including BIPs for Bitcoin and EIPs for Ethereum. The success of a blockchain is demonstrated, at least in part, by how broad and useful to developers these document collections are.

Not only do CIPs document what official Cardano blockchain developers are doing to improve core technologies, they also expand the scope of what Cardano is attempting to deliver: through standards submitted by independent developers and architects. Once a standard is proposed through a CIP, it becomes a reference point upon which other developers and agencies can build: which promotes new applications and broadening markets for Cardano.

Each well defined standard promotes more rapid development since developers have an increasing number of CIP-based tools and methods to employ in their projects. The best example of this so far in Cardano has been the proliferation of NFTs which are built by third parties entirely according to CIPs coming from the community itself rather than from Cardano's core developers.

Any developer, engineer, scientist, entrepreneur, or user should have a means of proposing one of these standards. This process is documented in CIP-0001, which defined and created this process… a document which itself is regularly updated as editors continue to refine this process in practice.

CIP Editors (click for current members) are the only GitHub users with the permission to merge documents into the CIP repository. This happens after a period in which any concerned party can review the document to find faults and suggest changes. Often the most demanding reviews come from CIP editors and generally all potential flaws in a standard or its documentation are identified and fixed through GitHub comments and biweekly meeting discussions.

Therefore CIP Editors as a group must be familiar with all existing proposed standards documented in the CIP repository above, while remaining aware of all the pending CIP documents (submitted as GitHub "pull requests"): staying in communication with authors, developers and advocates until these documents are refined and "merged" or ultimately deprecated or abandoned.

How is the author involved? How can the impact of this involvement be observed?

All original members of the CIP Editors group were employees of the official Cardano sponsoring companies (IOG, Emurgo, and the Cardano Foundation). In keeping with open source tradition and to maintain an impartial process, the members have looked for membership outside those companies. I was the first (and so far the only one) of these "community" editors to be added (in Q3 2021).

The amount of time spent on CIP editing responsibilities varies widely from editor to editor. Current editors employed with the Cardano Foundation and IOG often must focus on CIPs of well defined commercial interest to their respective companies.

As I had hoped, my increased freedom from employee responsibilities (CIP and otherwise) has allowed me to respond to CIP postings and enquiries daily, rather than forcing them to wait for a historically bi-weekly review cycle.

For most of the last year I have been funded through a Catalyst Fund 9 budget (Community CIP Editor: 1 year budget) allocating a typical number of hours per week: in which to attend CIP review meetings, review and help authors with proposals, and confirm the viability of the CIP process as its interest to the Cardano community continues to grow.

The result has been an assured baseline of quality and responsiveness to the developer community. Proposal authors must often wait for a deeply technical review… of the kind one of our more highly technical CIP editors can provide… but often there are project team representatives in other Cardano companies or specialised developers who can review a proposal in the meantime. My work in this aspect of "developer relations" has helped assure a good turnaround time for CIPs even though our number of technical reviews on the editing team itself remains small.

Ever since my arrival into the CIP process based on community advocacy (through the CIP-0013 updates for stake pool links, intended for a better delegation experience) I have also helped build bridges to the CIP process for interested users: not just developers. This includes engagement on the CIP Discord and Matrix channels and the CIP category on the Cardano Forum (see [CAPABILITY/ FEASIBILITY] What is your capability... for such "profile" and membership links).

How can this be continued and improved upon, going forward into the next year?

Over the last few months, other editors and I have been spending more time on routine CIP issues (see "detailed budget breakdown" section for a list of reasons), and so must still ensure enough time exists in our personal or employee time allocations to handle the non-routine matters without delaying them indefinitely. Therefore the first requirement is an increase in time allocated to my own efforts.

Given sufficient time, the second challenge is to keep this time balanced over all open CIP submissions: with straightforward, documented GitHub comments and reviews to keep lines of developer communication open. We have seen some cases in point recently which resulted not from lack of time or attention but from not having enough resources to poll developers proactively, as in the following examples:

• CIP versioning: A developer for a popular Cardano database aggregator would have preferred versioning for a popular token metadata standard, but was not vocal about their concerns until after the relevant CIP was updated without installing an explicit version number, so the problem had to be addressed retroactively (CIP-0068 versioning and similar cases: issue #520).

• CIP writing and refinement support: Sometimes a CIP is developed with initial support from IOG and then requires additional work for it to meet practical requirements that emerged later (see CIP-0067 | add ADA Handles Virtual SubHandle: PR #504), so development of these standards may be stalled while the responsibility we look for in proposers and CIP authors cannot yet be supplied by editors or advocates due to time constraints.

The three regularly active CIP editors (from CF, IOG, and myself from the community) have been applying conscious effort in advance to address these new types of problems, for instance:

• CIP translations: evolving a process that will work for all CIPs, even the most demanding, e.g. (CIP-1694 | Adding French translation: PR #539)

• Support for community-mandated RSS (Reward Sharing Scheme) proposals (Update for CIP-0084 consequences to RSS proposals: PR #536)

… but employers (and in my case, Catalyst) will have to assure a balance of time to cover this expanding scope of work, as well as agree upon goals and metrics for the community to measure its visibility and value.

**Additional goal for next year: documentation with potential recruitment ** The CIP editing team currently (July 2023) has 3 routinely working editors (Bitcoin has 2 BIP editors and Ethereum has 7 EIP editors. We may not be in a position where additional editors must be designated from Cardano companies or the community… although logically the survival of the CIP process depends upon the ability for others to step in and expand the group of permissioned CIP Editors in case the group might contract in the future.

These possible changes make it clear to me that the overall process of CIP Editing must be documented far beyond what is currently included in the few Editor related paragraphs of CIP-0001 (beginning here). All current editors are following a process that they learned by observation over months: so, although the results are always visible on GitHub and other forums, most complexities and demands of our process are still only documented in our own habits and memories.

Unfortunately this does not help with the goal of inviting or even encouraging new CIP editors… even the decision about whether one would invest the time as a CIP reviewer is still lacking HOW-TO pages or any other documentation. Periodically potential CIP editors from the community have asked for such information, and although tempting to say (as we often have) "GitHub itself contains the documentation and the process", this does nothing to bridge the gap between the CIP editor workflow and the community's full understanding of this process.

I consider myself the logical choice for this effort, and have included it as the Q2 milestone for this project (see Milestone question below), because:

• Between my Fund 9 proposal and this one, I have already gone into more depth than any other Cardano writer about the actual work a CIP editor does.
• Purists on our current CIP Editor committee might resist the idea of popular documentation for a subject that should remain completely objective: but due to my experience working in both camps I am the best hope of bridging this gap.

Since this "CIP Editor's workflow" will logically take the form of a GitHub Wiki, it will also become a starting point for other editors to contribute documentation according to their own observations: including some tips after 2-3 years of learning experience about what it takes to write a "good" CIP. Most of all, this effort will satisfy the repeated but unmet demand from the Cardano community that we provide a "window" into the CIP process.

How does your proposed solution address the challenge and what benefits will this bring to the Cardano ecosystem?

Highlighted benefits from F10: Development & Infrastructure challenge page

1. Main statement: What research, tools or software can improve the developer ecosystem or infrastructure to make it easier to build and scale on the Cardano blockchain?
   The CIP process is considered part of Cardano's developer infrastructure itself: repeatedly endorsed by Cardano agencies IOG and the Cardano Foundation. Project Catalyst representatives have declared that "standards" are part of the Development & Infrastructure effort, and the CIP process is the most definitive embodiment of Cardano standards.

2. Proposal type Technical standards:
   This defines an effort to "improve the overall quality of software deployed." The standards process of CIPs not only suggests new Cardano applications, it also identifies entirely new markets for Cardano when more than one agency (e.g. NFT services) implements these standards.

It also ensures that the rush to develop new commercial applications does not either a) waste developer time, money and credibility trying to reinvent something already done & documented in the public domain; or b) develop something only to find its commercial life is short-lived due to lack of interoperability with other Cardano products and services.

3. Proposal type Technical documentation & education:
   A good percentage of CIPs are documentation themselves: e.g. Cardano's protocol parameters (and the decisions behind them), wallet keys and addresses, and procedures to evolve languages like Plutus and data structures like the Ledger. Supporting the CIP framework also invests time in quality documentation that developers and new converts to Cardano can learn from quickly.

The corresponding success metric "Amount of people viewing resources, reduction in number of common questions for contributors due to better resources" has always been abundantly observable on the CIP Repository: with all Cardano's public-facing standards available as widely read, shared, and implemented documents.

4. Consideration of Open source plan:

Not only are all CIPs open source (free to re-use themselves by open source license) but the methods they describe, being open to the public, also encourage the Cardano community to converge on open-source implementations, and to open-source their APIs and other interfaces even their products may use proprietary components internally.

5. Key Metric Number or quality of standards:
   Defined as "making it easier for node operators and developers to understand the ecosystem" … with community-based developers involved in the review process for nearly every published CIP, their feedback has always guaranteed this growing number of standards will be well received, understood, and maintained by the community going forward.

What impact will this project have for Cardano, and what value does it bring to the Cardano ecosystem?

By "this project" (language taken from more detailed proposal question) I have to point out that my status and funding as an editor is not the same as the whole of the CIP process itself… but also that my own deep time commitment and breadth of involvement has made me an essential part of the process since early 2022.

Therefore my continued funding through this proposal will have all the same benefits as supporting the Cardano standards process itself. Continued representation by a "community" CIP editor will help ensure that standards evolve in a decentralised manner not dependent on any company in particular.

The evolution of the Internet, followed by the emergence of astonishingly valuable blockchain assets, has shown us that robust open source standards in Cardano's design and governance will lead to:

• higher & more sustainable native asset values
• more & better interrelated business propositions
• increased adoption relative to other blockchains
• an anticipated freedom from regulation if claims of decentralised governance can be upheld.

How do you intend to measure the success of your project?

Answer:
1) Quantitative goals (KPIs / performance measurement)

A rough estimate of the CIP Editing total workload can be obtained through GitHub search URLs (statistics as of proposal final editing on 17 July 2023):

• Total number of CIP open PRs (currently 62)
• Total number of open CIP issues (currently 32)

The total number of open PRs can be compared with the number of merged CIPs on our front page: at this time still updated and tabulated manually (currently 68). To demonstrate efficiency of the CIP process, all editors should ensure the number of open PRs stays as small as possible relative to the number of active CIPs.

Whether this ratio is acceptable depends on how "normal" it is for a posted CIP draft to remain in the review process as a Pull Request before being "merged" as a Proposed (planned) or Active (already implemented) document.

• Editors often believe that most documents are waiting for legitimate reasons in this intermediate state: since we cannot force developers to respond to reviews of their posted documents, and can't assume responsibility for testing and documenting the ideas that come from developers' unique expertise.
• For my plan to qualify, quantify or challenge the conception that this queue is "understandably" large rather than "bloated" — by producing and maintaining a more detailed accounting of reasons for delay — see this project's Q3 milestone.

The contributions of individual CIP editors can also be checked manually by GitHub query on how many CIP PRs they have individually helped progress (open PRs at this time considered "current", and closed PRs "prior"; measured before proposal submission on 17 July 2023):

• PR search term commenter:rphair = 49 current, 220 prior
• PR search term commenter:KtorZ = 40 current, 267 prior
• PR search term commenter:sebastiengllmt = 21 current, 150 prior
• PR search term commenter:Ryun1 = 21 current, 36 prior

Note there is no "competition" between individual editors and that these total statistics don't reflect particular CIPs that editors have written and/or for which editors have spent extraordinary amounts of time on review, update, and community engagement.

• My own contributions have higher measurements because of my current and long-term focus on introductory submissions ("triage") and status responses/replies to ensure the CIP process never appears stalled nor partial to any particular interest.

2) Documentation and readable public statements

As promised in my Fund 9 proposal, I have produced monthly reports on GitHub with progress initially focused on progress at meetings as anchors into GitHub CIP PR discussion, and more recently including individual GitHub summaries of discussions outside the scope of meetings:

• CIP monthly report archive: https://github.com/rphair/cip-editing
• Most recent & representative monthly report (2023-07-15)

Note the links above are also included elsewhere in this proposal to illustrate goals, activities and project / community outputs. Specific content for monthly reports is inventoried in [CAPABILITY/ FEASIBILITY] Please provide a detailed breakdown of … main tasks or activities under "Monthly reporting".

The Q2 milestone will also produce a best effort to document the CIP process as it would concern new editors, reviewers, and the community at large (see [CAPABILITY/ FEASIBILITY] Please describe the deliverables, outputs and intended outcomes of each milestone section for planned content).

3) Community goals (engagement)
The initial main output of the CIP Editors team, at the time when I arrived as a regular observer, was in the recorded and eventually transcribed minutes of the biweekly CIP editors' meeting. These minutes were posted in the hope that interested members of the community would be able to find & reference items they were interested in by reading transcripts categorised by the CIP pull request under discussion.

This was outgrown over 2021-2022 for a number of reasons:

• nobody from the community seemed to read the verbose CIP meeting minutes
• transcriptions were horribly flawed, especially for foreign accents, and required more time to correct than the meeting itself
• discussions of current CIP PRs were disconnected from the discussions occurring in parallel on GitHub… the latter being where they really needed to be recorded and focused on resolutions & action items.

Therefore our primary community output has been though GitHub ever since, with our success demonstrated whenever developers and community advocates can follow GitHub threads for the CIP topics they are interested in, and get a complete picture of CIP developments simply by email subscription to all activity on the CIPs repository (as I & some other editors do).

Besides GitHub we have also had to evolve into other message streams to serve the following community needs:

• Non-developers often feel anxious about committing their thoughts to GitHub publicly and permanently, and so might only feel comfortable commenting on CIPs through social channels like Discord and Matrix or the more personal discussion format of the Cardano Forum.
• Non-KYC platforms like Matrix have served users unwilling to offer mobile number- or device-based identify verification as required on Discord.

Therefore CIP discussions sometimes span multiple channels for purposes of polling and temporary discussion. These are more fully inventoried in section [IMPACT] Please describe your plans to share the outputs and results of your project?) … with the often repeated understanding that only the discussions taking place in official GitHub PR threads are considered relevant to CIP review.

Successful effort in categories (2) and (3) above will be seen through reports of CIP social discussion and official GitHub activity occurring regularly across all progressive CIP pull requests, plus resources for the Cardano community as a whole to understand the CIP process itself, with confidence (especially for developers) that CIP discussions are taking place regularly and robustly.

4) Qualitative goals
A number of general, subjective goals have already been given in the section [IMPACT] How does your proposed solution address the challenge and what benefits will this bring to the Cardano ecosystem? particularly with respect to maintaining confidence and participation from both the developer and general Cardano communities.

I also elaborate in the section [CAPABILITY/ FEASIBILITY] What are the main goals for the project and how will you validate if your approach is feasible? a definition of how parts of our community will perceive whether the CIP process "is working" and how this can be defined by recent challenges, successes, and pathological cases.

Beyond these direct observations, I believe there are also two qualitative success measurements that can be observed indirectly from a successfully executed CIP process:

4a) The CIP process should be generally seen as sustainable. Particularly, communications and relationships between CIP editors, Cardano companies and official developers, community developers, and observers should be easygoing and without resentment.

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 if the CIP team doesn't always require new editors, maintaining a healthy interest in others joining should still be considered beneficial… as expressed more fully in this project's Q2 "Editor Wiki" documentation milestone.

4b) 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 — would be attractively visible in the next year to developers, companies, writers, investors, and analysts encountering Cardano coming from other blockchains.

This will be especially important this year considering that Governance improvements are founded in the CIP process… and viable on-chain governance will be highly beneficial to demonstrate to Cardano's competitors and critics as well as blockchain regulators and legal / financial executives.

Please describe your plans to share the outputs and results of your project?

Answer:
This question is already answered in several other sections of this proposal: the CIP process is unique in that the entire process, except for certain conclave discussions among editors about logistic issues, is visible to the public.

I will try to enumerate these channels again here; please also refer to the routine tasks inventoried above and below for a complete list of public communications, including:

• primary activity on GitHub
• secondary activity on social channels: Discourse, Discord, Matrix, and occasionally Twitter
• regular reporting of CIP activity (for me, also on GitHub)
• occasional interaction with SPO and Dev communities through Marketing channels (none so far in 2023 yet)

The work is, by its nature, spread over a "reasonable timescale" (a phrase appearing in the more detailed form of the question above) because it manifests continuously in response to contributions, questions from unrelated parties.

CIP editors cannot control daily, weekly, monthly or quarterly how much work will come in: we can only commit to staying ahead of whatever must be done during each of these periods.

Finally the question above has a sub-question: How do you expect to use the results generated from the project in further research and development activities?

The work I am doing in the scope of this project, because it most generally supports communications with a broad spectrum of developers, will promote a "feedback" process:

• We have a growing number of CIPs, approaching a larger & more diverse body of standards such as seen on Ethereum's EIPs.
• Observers from other blockchains note that Cardano's standards process demonstrates growing functionality, interoperability, commercial application, etc. to support their current and upcoming projects.
• Developers migrate to Cardano from other blockchains and bring their ambitious applications and expectations with them.
• These in turn require new CIPs to define them, which feeds back into Step 1… continuing cyclically with more CIPs, containing better research and covering more applications, with more standards-driven adoption & developer engagement expanding the Cardano ecosystem.

What is your capability to deliver your project with high levels of trust and accountability?

Answer:
GitHub: @rphair

Twitter crypto handle: @COSDpool

Cardano Forum: @COSDpool

Web site: cosd.com

General CIP-related qualifications:

• An official editor of Cardano Foundation CIP repository
• Discord > CIP Editors Meetings official server (invite): listed with Editor role; most frequently seen editor in #general channel
• Group moderator of CIP Room, Cardano Professional Society (independent MBO)
• CIP-0013: co-authorship (providing & advocating the Stake Pool Links component)

Relevant experience with blockchain (as of 2020):

• Cardano Summit, September 2021: Standards panellist on Governance track
• Cardano Developer Portal: most prolific contributor outside Cardano Foundation.
• Wrote Security section of official Cardano community documentation on Dev Portal (standards of Air Gap Environment & Secure Transaction Workflow)
• Frankenwallet - invention & documentation of this bootable USB-based secure environment, to eliminate need for dedicated "air gapped" hardware for crypto security: effectively an open-source DIY hardware wallet
• Stake pool operator (COSD: low-fee single pool) since Q3 2020; six-time winner of Cardano Foundation community delegation

Relevant experience prior to blockchain (pre-2020; see C.V. / Resume)

• UNIX/Linux systems integrator, project manager, and software standards architect since late 1980's.
• Computer industry consultant with thirty years of professional experience in systems integration, networking, programming / design, technical writing, and project management.
• Business advisor for cloud computing, online marketing & commerce, data security, technical training and emerging technologies.

NOTE there will be no "funds management" required for this project, so demonstrating competence in this area is not relevant.

What are the main goals for the project and how will you validate if your approach is feasible?

Answer:
The first part of this question (What are the main goals for the project?) has already been answered in the first major question ([IMPACT] Please describe your proposed solution) because, at least for the CIP Editing process, the "goals" and the "solution" are the same thing:

• Given that the "solution" is to implement all the components of a superior and constantly improving standards process, the "goal" is simply to follow this implementation plan.

The second part of the question (How will you validate if your approach is feasible?) is not applicable to the CIP process itself, because:

• This process was ongoing before my arrival as an editor and well before I secured any Catalyst funding: likewise it presumably will continue after my role as an editor and/or Catalyst funding have come to an end.
• The fact that the CIP process is currently required in the Cardano ecosystem pre-defines it as "feasible".
• If my own working style or chosen goals prove incompatible with the CIP process, eventually I would be dismissed as an Editor and (as explained in the "Dependencies" section above) would no longer be eligible for Catalyst funding.

However, beyond the quantitative KPIs of relative work volume, progress and backlog of the CIP issue and pull request queues, and my own measurable involvement in these — and beyond the particular threads that emerge in developer discussion online over particular CIP-related issues — there will always be an overall, subjective sentiment of the Cardano community about whether the CIP process is "working" which is the ultimate validation of "feasibility" for both my colleagues and myself.

So I will address this single question here in terms of perceived difficulties, criticisms, and failures that might interfere with community satisfaction with the CIP process as a whole:

Does the CIP process work? Some challenges & responses:

About straightforward standards issues we can always clearly demonstrate that user and editor feedback has been used to build a complete proposal… for these CIPs the objective will simply be to progress all proposals within the time available to us as editors. Therefore the main measurement for developer satisfaction for the bulk of proposals will be a lack of visible complaints online: the simple metric of "no news is good news" (though there will often be "thank you" messages posted which can be seen in many GitHub PR threads).

But ultimately the feasibility of the CIP process, and of my own "community" role in this process, will be whether the Cardano community is also satisfied by handling of CIP issues which border on external issues beyond our control, especially "political" factors. Even after all the routine work is done, communities will often remember only the most dramatic issues: so the ultimate test of performance will be whether we have handled these pathological cases with enough objectivity and sensitivity.

Two examples are helpful to illustrate this subjective criteria: one to show how it's been applied successfully in the past, and another illustrating our ongoing efforts at this time:

Handling of RSS (Reward Sharing Scheme) proposals
From 2020 through 2022, members of the Cardano community submitted CIPs to argue for often requested updates to blockchain stake rewards: particularly to change the minimum pool fees, the K factor (number of ideal stake pools), and/or the effects of pool pledge. These CIP authors understood that CIP editors had no control over whether these policies were implemented by IOG core developers, but still became disappointed with the CIP process as a whole because this lack of institutional support led to older RSS proposals being apparently ignored and newer ones accepted with an "Inactive" status.

Eventually a combination of internal communications and editor & community advocacy led to a resolution of this problem by defining these proposals as under the purview of the Ledger team at IOG (see key factor in resolution). Once this opportunity became available, although the long exclusion was "not our fault" we were still responsible for maintaining faith in the CIP process by promoting the acceptance of these proposals (see Tweet & its link). The positive response from the community suggests that our attention to community satisfaction has been successful after a long period of unavoidable difficulty on this sensitive issue.

Governance and CIP-1694
During nearly 8 months of posted updates to the Ledger based governance mechanism of CIP-1694, the sensitive "political" nature of this proposal invited unprecedented amounts of feedback about issues of constitution, representation and ethics which were literally outside the scope of the proposal. This presented a difficult moderation problem (over 700 comments) and some routine commenters complained bitterly when we were obligated to merge this proposal (see announcement) so that further edits and focus-group ("governance workshop") testing could then be applied regularly.

For this realm of proposals, CIP editors will face criticism that we have somehow appointed ourselves "gatekeepers" who only represent the interests of the Cardano established companies. On my own part I definitely have no such obligation (I am unpaid by and unaffiliated with these companies) and am confident that all other editors consider only technical factors in whether or not proposals are merged.

Still we have to accommodate this negative feedback (seen in response to the announcement above) which may be inevitable from the community. Although we may not respond when this presents criticisms that are beyond the scope of a particular CIP or the CIP process, the community will have to see that we remain impartial and keep taking this criticism into account. As in the case of the successful RSS proposal issue above, there is often a resolution that can come from somewhere, even if we ourselves cannot provide it… so we need to remain attentive to the most intractable issues in the meantime.

Please provide a detailed breakdown of your project’s milestones and each of the main tasks or activities to reach the milestone plus the expected timeline for the delivery. Answer:
NOTE: Since this project contains both regular monthly funding checkpoints and unique milestones between each project quarter (effectively 12 + 3 = 15 milestones in all), a detailed breakdown of funding by milestone will be prepared later (in the onboarding process for funded projects) according to Fund10 Milestone-Based Funding Guidelines.

• I would suggest dividing the project funding total into 12 equal monthly parts, and adding the quarterly milestones as requirements for further monthly funding but with no additional funding themselves… how exactly that is phrased will be determined in the Statement of Milestones phase of Fund 10.
• The timeline for this delivery will therefore begin immediately after my previous Fund 9 project in the 12 months from November 2023 through October 2024.

Regular activities (summarised in monthly checkpoints)
The goal of all CIP review activities is ultimately for all editors to be aware of the status of open CIPs, and not to move any proposal forward without the appropriate indication of consensus. Everything below has evolved to demonstrate, to the entire Cardano community, that a quorum of CIP editors are convinced that all qualified reviewers in the community cannot find any further technical or writing flaws with a proposed standard.

Daily GitHub review: The CIP process is mostly cyclical, with tasks loosely allocated between CIP Editors. Each editor accepting the tasks they feel most qualified to deal with. Routinely editors review the CIP repository PR queue and issue queue, but ultimately every CIP event such as a CIP posting, comment, or review has to be read and often responded to.

For 2 years I have subscribed to all these events from the GitHub CIP repository page through the Watch button in the header: selecting "All Activity". This generates a variable but continuous stream of email messages across time zones: with a few peak periods primarily in the work week (it's not possible to measure the number of these events exactly).

Therefore work comes in continuously and is generally not predictable a month or even a day in advance. These items can be observed in any CIP PR or issue thread, but most often include the following:

• requests for review from a CIP author
• reviews from a developer or another CIP editor
• comments on reviews from CIP authors or editors (generally all these must be resolved when they request changes to the document, whether or not a change is made)
• requests to authors from editors, advocates, implementors, or any interested member of the community
• editorial comments that a CIP is ready for promotion or "merging" or that we discuss this at a regular CIP meeting
• merge notifications, when a fully reviewed CIP becomes official: which requires some maintenance on the table in front of the repository.

Personally my loosely defined schedule (having no "employee" responsibilities to other Cardano companies like all other current editors do) often makes me the first responder to these requests: hence my higher apparent involvement in routine CIP work through the last year, as other editors are often focussed on particular CIPs (see GitHub link KPIs in "performance measurement" section).

Irregular activities: Some of these lead directly or indirectly to efforts outside of the stream of GitHub comments. When significant, other editors or community members will become involved in these, and the work is planned spontaneously (for the last year I've been documenting these in my monthly Catalyst reports):

• Creating discussions on Cardano Forum (generally the CIPs category) to bring CIP related questions, information, and sometimes new CIP drafts to a larger audience.
• Monitoring user-to-user discussion on the Discord or Matrix where particulars of CIPs are discussed, to bring back the most relevant feedback to the GitHub discussion thread.
• Engaging with IOG or Cardano Foundation technical teams and SPO forums regarding highly technical or scientifically inclined proposals, to bring back the results of out-of-band consultation into the documented CIP process.

When possible, long-standing issues must also be undertaken on GitHub for maximum accountability. Other editors and I will schedule these when we observe or forecast that a particular problem or issue is becoming important.

• For examples, see the special CIP topics in the section [IMPACT] Please describe your proposed solution. (CIP versioning, CIP writing help, translations, RSS proposal integration).

Bi-weekly meetings:

The public CIP process goes in bi-weekly cycles as defined on our Discord server (see Qualifications section for links & invitation), with dates generally posted 1 or 2 meetings in advance. The conversation at this meeting determines the goals that are set for the next 2 weeks: in which actions taken for each CIP related pull request or issue are documented publicly on GitHub.

According to our own involvement with each CIP over time, we will generally declare in advance our presentation of that CIP submission or update in the meeting agenda, which we prepare as a group and suggest items for in parallel: https://hackmd.io/@cip-editors

Preparing for this meeting is often the most time-consuming portion of our bi-weekly schedule, since we must make sure all items on the agenda (often with a community or CF convenor suggested theme like Plutus or Ledger) have been reviewed and understood as well as possible in advance, so that we can cover all outstanding issues while the relevant developers are all in one conversation for that hour.

Finally, since it has no longer been possible to transcript the meetings since 2022 (too many voice recognition problems), each responsible editor must accept responsibility to document the resolutions that were made at the meeting: a summary comments on the meeting agenda, and a comment for benefit of all CIP participants on the GitHub PR thread for that CIP.

The latter task (GitHub summary of meeting progress) is one role in which I have been outstanding in the last year, which has ensured that all discussed CIPs remain in engagement between authors, advocates, reviewers, implementors and editors and stay on track each meeting cycle until reaching the goal of merging the CIP.

Monthly reporting (only for my own work):
While the CIP process above runs in bi-weekly cycles, I also document my own activities in monthly intervals in Catalyst reports, posted at this public link so they remain easily accessible to the community: https://github.com/rphair/cip-editing

These reports include, according to a semi-regular format which evolves over time:

• Quantitative factors: KPIs for open issues and my own work with them (as quoted elsewhere in the "progress reporting" section of this proposal)
• Qualitative factors (subjective progress): Written descriptions of high-level objectives achieved with any outstanding issues
• GitHub progress: Links and summary of CIP achievements undocumented or undiscussed at CIP meetings
• with (recently) annotated & summarised notes from all that month's (usually 2) CIP meetings.

See latest example monthly report: https://github.com/rphair/cip-editing/blob/main/2023-07-15.md

Long-term projects & planned improvements = quarterly Milestones

Beyond the regular tasks above, and beyond the irregular tasks appropriate to my currently unique "Community Editor" role, there are also three long-term objectives which I believe the CIP process would be served by achieving in the first three project quarters (beginning with the Fund 10 proposal launch date October 2023), as per the

Milestones section below:

• Milestone project Q1: Remediation of old non-compliant CIPs
• Milestone project Q2: CIP workflow & editor Wiki
• Milestone project Q3: Process & tagging to eliminate backlog

Please describe the deliverables, outputs and intended outcomes of each milestone. Answer:
Beyond the monthly documented work detailed in [CAPABILITY/ FEASIBILITY] Please provide a detailed breakdown of your project’s milestones, here detailed are the specifically budgeted tasks for each project quarter:

Milestone project Q1: Remediation of old non-compliant CIPs
CIP-0001, which defines the CIP process and document format, went through a major overhaul in mid-to-late 2022 (concluding in (new) CIP-0001 & CIP-9999: Cardano Problem Statements: PR #366) to allow CIPs to be better categorised for implementation and to use a more machine-readable format to facilitate their building into generated web microsites like cips.cardano.org and the Developer Portal CIPs section.

Although all new CIPs since then have followed this more useful standard format, so far nobody in the CIP Editors group since December 2022 has had the time allocation to go back and update all older CIPs to use the newer standard. At the time of this writing (July 2023) there are 44 still to rewrite, listed here: CIP-0001 update: issue #389

Some of these can just follow a standard rearrangement of text, while others will require communication with developers and/or IOG project teams to review or reconstruct what might have been done to implement or activate a CIP in the meantime. All of these CIPs, in any case, will have to pass the editorial review process again. The average work time for each of these CIP remediations will therefore about 1 hour.

It is sensible for me to accept this as my own project milestone since so far, except for an initial demonstration effort, none of the officially employed CIP editors have been able to justify the time to spend on this. Comments in the related issue threads indicate this is why the derived web sites above remain only partially and sometimes intermittently functional (for instance, you can't link between CIPs without arriving back at the GitHub source document).

Completion in the first project quarter (by end of January 2024) would allow the Cardano Foundation maintainers and/or third parties to remediate the function & design of the two web sites again, as well as paving the way to improved site builders that will handle other CIP formats (e.g. translations) and categorisation.

PROOF OF COMPLETION: Issue #389 finally closed: only possible when all its dependent issues are created and closed with all their PRs merged (can be easily checked at GitHub link), no later than the February 2024 Catalyst report.

TIME ESTIMATE: 1 hour x 44 currently open unremediated CIPs = 44 hours.

Milestone project Q2: CIP workflow & editor Wiki

This officially defines as a milestone the Additional goal for next year: documentation with potential recruitment described earlier in [IMPACT] Please describe your proposed solution.

Elaborating on that section, I am proposing we build a set of CIP Editing documentation which will include, organise, and impersonalise the workflow description already written in this Catalyst proposal. Content will be, roughly:

• Workflow of CIP editors: both regular and irregular components
• Meetings: why we have them, what we do, how to prepare & follow up
• Community engagement: groups and suggestions for interacting with them
• Ethos: what the CIP process does and doesn't do (expanding on this from CIP-0001)
• Reviews: how specifically a GitHub review is processed when preparing to accept a CIP draft… this will also be directly useful to developer and community members engaging with the CIP process, including but not limited to those who may be "training themselves" for an eventual application as a CIP editor.

This goal was determined by community demand as per this conversation on the Matrix MBO:

> Question that's been bugging me. For CIP reviewers and others, is there a "Constitution" guiding light to make decisions again? Is it the Cardano whitepaper or ethos on the website? What to a CIP Editor do you use for a source of truth to vet decisions against?

> Would you have a "getting started" or "recommended reading list" for CIP training? Obviously the Whitepaper and CIP-0001. Maybe it already exists in Cardano.org Docs or Developer Portal? … I think it would be wise at some point to start planning for training material (maybe just a few slides or a 2-pager best practice and lessons learned).

My response, which explains why we've taken a very sparse approach to documentation, but admits we might now have to drop that restriction:

> … the "unwritten constitution" of CIP editing is that any defensible technical idea that is well-conceived and -documented enough to be accepted as rational by editors, peers and potential implementors has a place as a merged CIP. Anything emotional or political that surrounds this strictly logical process can and should be ignored. …

> From the beginning the first CIP editing committee intended (and I supported, being the first person to arrive beyond the original group) that there should be complete visibility on the GitHub repo alone. That has the maybe unfortunate consequence that the entire body of CIPs, reviews, comments, tags, commits & merges (plus meeting agenda & notes now) is the training material.
It has the advantage that this steep learning curve reinforces the idea to ourselves & others that subjectivity cannot be part of the process, as there would be if there were "training materials" in writing or video to narrow reviewers' and editors' focus to the most "essential" things. Without that, we can only continue the precedent of attention to every detail about how any CIP might be technically contested or poorly documented.
… but in writing the Catalyst proposal for my next years' funding you are making me want to include something about a time budget to expand the CIP committee… so I might include a statement about training, documentation & maybe even mentorship.

Based on this dialogue I realised the importance and timeliness of having this documentation element as part of our overall CIP process (though not in the strictly defined CIP-0001): both to "future proof" its evolution and to assure that we would have a pool of potential new CIP editors based on assurances that the consequences & responsibilities of their participation could be well understood in advance: something we cannot offer them today.

When I prepare this material it should be posted in the commonly used Wiki tab on the official CIP repository GitHub page (currently undefined). This will require editor consensus about the posting of the material, the appropriateness of contribution, and the accuracy of the content:

• It could be that the CIP editor consensus will be that any material outside of CIP-0001 is subjective and therefore should not be elaborated upon, sticking to strictly logical principles (which are assumed by all of us but difficult to put into words unless we see the importance of follow these instinctively).
• If this is the case, I will disclaim "official" status, accept sole responsibility for managing the resulting material for my term as a CIP editor), and post that same Wiki archive here, adjacent to my existing & growing body of Catalyst reports: https://github.com/rphair/cip-editing/wiki

PROOF OF COMPLETION: the May 2024 Catalyst report will confirm… with a brief, current content summary like the one above and publicly accessible links… a first complete and well-formatted version of this additional documentation around the end of April 2024.

TIME ESTIMATE for writing, posting, and obtaining consensus with other CIP editors: 1 work week = 40 hours.

Milestone project Q3: Process & tagging to eliminate backlog

The currently observable backlog in the CIP pull request queue, in both the long term memory of CIP editors and any exhaustive review by a new observer, shows that the older a PR is, the less likely it is for the reason for its inactivity to be documented. This leads to a queue "bloat" typical of open source projects from most efforts being focused on high profile or community demanded issues.

We have a tagging vocabulary for these PRs, but this only lists the states of Deprecation and Waiting for Author as explanatory tags for inactivity. Unfortunately there are many long-stalled CIPs which don't fall into either of these categories, and would be better characterised by new tags which reflect what can be done by a CIP editor (whereas there's little progress we can make if waiting for an author or if deprecated).

The PR queue (and perhaps the issue queue, since most issues are about current or proposed modifications to CIPs) therefore needs a tag for each PR reflecting its "editing state", i.e. what is needed next in order for the CIP to progress either towards merging or closure. This would involve creating new status tags such as:

• "Need help in authorship" (e.g. PR #504)… not the same as "Waiting for Author" because CIP editors can also help with the authorship or find developers who might do so.
• "Incompletely specified"… something editors can often help with, since many of these old PRs survive from days when a CIP submission was considered an "idea" rather than a request for implementation support (today we have the Cardano Problem Statement (CPS) for such loose definitions).
• "Needs CIP number assigned": this review state is often realised after the CIP meeting but relies on editors' medium-term memory or personal notes to be merged later in a "Housekeeping" update to the CIP tables in the top level README file.
• (et cetera, according to item-by-item review)

Some of these tags would also invite community support as defined in the Q2 milestone, because interested reviewers, potential CIP editors, and Education / Developer Relations staff at IOG and the CF would be able to search by such tags and contribute help according to their ability, interest, and available time.

I will be proposing a tagging vocabulary of which one and only one tag will be appropriate for, and then applied to, each CIP PR and issue: so a view of those queues or any tagged subset will show editors a clear view of exactly the steps needed for each item to progress. Therefore these queues would no longer have the dysfunction or stigma of "backlog" because every stalled item will offer its own way forward.

This will require some agreement between current CIP editors: especially since a different tagging vocabulary and state progression was attempted during the earliest stages of the CIP process but then not maintained and eventually retracted. As I am newly revisiting this issue, all editors will have to agree on a different implementation of state tagging which:

• can clearly be seen to reduce rather than increase routine work, and therefore:
• will not go out of date because each CIP editor will therefore want to maintain it rigorously, and will be able to easily see when a PR is missing one of the obligatory state tags
• will also reduce CIP editor workload by eliminating manual updates to documents upon CIP state changes: particularly the impractical Stalled / Waiting For Authors list.

This effort can be started as soon as the Q2 milestone Wiki can host a page with a description of the proposed tags, eventually linking to the tagged subsets with a simple flow diagram for the CIP "state machine" (as notably different from the "CIP status" diagram of early CIP-0001 versions).

PROOF OF COMPLETION: Linking to an observable structure of tags, as a page on the proposed CIP Editors' Wiki, with every CIP PR tagged accordingly (both old and new) no later than the August 2024 Catalyst report.

TIME ESTIMATE for creating, getting consensus among all editors & documenting tag vocabulary: 16 hours (cycled through meetings, online chats and several passes of approving the process and its documentation) + imposing on all currently open CIPs (over 60, at about 3 CIP discussions & tags per hour: 20 hours) = 36 hours.

Q4: No milestone defined yet, though budgeted. (Why?)
Based on past experience, my CIP work will need a similar time allocation for some effort(s) which have not been determined yet (about 40 hours per quarter) in the last quarter of the project (August through October 2024).

It is logical to anticipate we will need some adjustments to the CIP process through an anticipated bull market return, with increases in both the volume and complexity of the CIP space, so the balance of this time might well need to be spent on ongoing CIP tasks alone. From what we have seen in multi-lingual CIPs this year, translation and localisation issues themselves could well account for this additional workload.

Because the Q1 through Q3 milestones above are responses to new requirements that could not have been anticipated 1 year ago; it's also likely there must be a time budget for the new CIP-based tasks that will emerge over the next 6 to 9 months. Therefore some freedom must be included in my own budget to pivot to emergent requirements and choose any appropriate long term task(s) for that quarter.

My current status as the sole CIP editor not employed full time with a Cardano company makes the default choice to perform such tasks. But my independent status also makes it impossible for me to arrange the prerequisites for some important CIP efforts, until perhaps some time later when those needs are declared more urgent.

For instance, such a suitable CIP effort could be to assist or execute the coding and styling for a new cips.cardano.org which has long been anticipated in the two-year-old CIP issue #109. As much as CIP team support will be required to make this site remediation a reality, it couldn't be committed at this time for the following reasons:

• This domain is considered a property of the Cardano Foundation, which means their own bureaucratic process must determine who is given "authority" over it.
• It makes more sense for auditing and budget to define this as another Catalyst project: which would still be impossible for an independent designer unless the assistance of the CF in granting control over this politically significant domain were arranged in advance (a "Catch-22").

Though unconventional by Catalyst standards, the indeterminate nature of the CIP process requires that I leave this Q4 milestone "open" in some good faith that I (and other editors) have always undertaken CIP improvements whenever budgeted time permits, and will always use this allocated time to fulfil emerging needs in order or priority.

PROOF OF COMPLETION: Statements in final quarter (3 months) of Catalyst reporting and in the required close-out video that this allocated time has been put to appropriate use.

TIME ESTIMATE: average of Q1 through Q3 milestones above = 40 hours.

Please provide a detailed budget breakdown of the proposed work and resources. Answer:
NOTE Over the last year, regular time spent on CIP issues has approximately doubled: hence the time allocation increasing from 8 to 15 hours per week since my Fund 9 application 1 year ago, mainly because of the following demands (while our CIP team has remained the same size):

• 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).

Time estimates

According to the tasks summarised in the 2 section answers above ("detailed breakdown" and "each milestone") broken down into groups most easily measurable in time:

Daily GitHub review and short-term irregular activities: 7 hours every week (14 hours each 2 weeks). An average 1 hour per day for:

"Triaging" new CIP submissions on GitHub (clarifying titles, linking to proposal documents, closing duplicates, tagging initial reviewers) Identifying issues needing attention (and attending to them) based on all email coming from CIP GitHub repo in response to all events (comments, reviews, review comments, issues posted, issue comments) Reading, and responding to when expected, all CIP related comments on Discord, Matrix and Cardano Forum groups (including Governance topics when touching upon the CIP process) Help (for git, GitHub, and CIP process) with improperly submitted CIPs (example) Condensing statements of regular progress into a form that can be easily included in monthly community / Catalyst reporting

Biweekly meetings and related workflow: 6 hours each meeting week (6 hours each 2 weeks):

3 hours (on meeting day and/or previous day) to collect & index all comments on proposals for agenda, to update the proposed agenda, and to connect on GitHub & other channels to help assure presence of relevant parties at meetings. 1 hour for meeting itself. 2 hours to summarise resolutions for developers, make follow-up comments, and post relevant dialogues to community channels.

Longer-term irregular activities and quarterly milestones: 5 hours every week (10 hours each 2 weeks; 65 hours per quarter)

Rewriting existing CIPs when the need arises (recent example efforts of mine: CIP-72 asset files, CIP-13 protocol definitions) Evolutions of the CIP process (e.g. translation / localisation for CIPs, admitting RSS proposals into CIP process) Any presence required in IOG or Cardano foundation events such as workshops and SPO / Developer calls Work on milestones over all 4 quarters (defined Q1 through Q3; open in Q4) at 40 hours each quarter: leaving 25 hours per quarter (2 hours per week) for non-milestone work.

TOTAL 14+6+10 = 30 hours every 2 week period = average 15 hours per week with these stipulations:

Nothing happens in the New Year period (2 weeks each year), but so far this is the generally the only period free from CIP activity (over 2 years of my observation). There is no negative budget for my own absences. For all editors these require that we "catch up" on our customary tasks when we return… if we don't do the particular thing we typically do then other editors assume we will do it when we get the chance. In weeks when the bi-weekly meeting is cancelled, the inevitable discussion and review gets done in written form on GitHub instead… so balance of editors' time is the generally same even in the occasional event that a meeting is postponed or cancelled.

Who is in the project team and what are their roles?

Robert Phair (proposal submitter and CIP Editor) will undertake the entire workload for this project.

For qualifications, see section: [CAPABILITY/ FEASIBILITY] What is your capability to deliver your project?

How does the cost of the project represent value for money for the Cardano ecosystem?

Question: Why doesn't the Cardano Foundation (or IOG) just support & pay for the whole CIP process directly?

From the number of currently active editors factored into the current time estimates above, the total amount of work in the CIP process could likely be done in a 40-hour work week, i.e. by a single employee doing nothing else. So why all this fuss about division of labour and arranging Catalyst funding for independent, part-time editors? Because of the factor that makes blockchain possible in the first place: consensus.

A solitary bureaucrat would be the direct opposite of a team with finely distributed skills and dispositions: such a diverse team makes broad community outreach possible as defined above. Internal connections to IOG and the Cardano Foundation are impossible to arrange from my own position (and have been vital to validate implementation paths for CIPs), while my own diverse work focus allows me to cover more ground in community, communication, and documentation.

More importantly, CIP editors from multiple organisations provide consensus about CIP decisions and processes from multiple points of view and a mixture of technical, social, and academic dispositions. Since we cannot make everyone in the Cardano community a CIP editor, we can achieve the next best thing by diversifying the CIP Editor group to cover large segments of that community through practical understanding as well as empathy.

As hoped in mid-2021 when I was tentatively invited to be a CIP editor, last year's precedent of funding editors on Catalyst has more fully decoupled the CIP process from bureaucratic constraints including potential or perceived conflicts of interest that might result from the Cardano Foundation paying editors directly to manage its own repository.

Is my hourly rate justifiable?

1) My budgeted hourly rate for last year's (Fund 9) Catalyst project was US $50 and remains at the same rate ($50) this year. This Fund 9 proposal was #1 ranked in its category (the "Ethereum" challenge) in both the review phase and the popular vote: with this huge popularity confirming the feasibility of the budget based on a $50 bill rate.

2) It is both a concession to the crypto "bear market" and a cooperative gesture to the Cardano community that I am leaving this rate unchanged at $50 this year as well, despite the additional experience acquired by myself and all the current CIP editors in the previous year. (Note, as stated in my Fund 9 proposal, all my work the previous year was as an unpaid volunteer.)

3) Other budgets of popular projects from Fund 9 confirm that the $50/hour rate is on the low end of billing rates for specialist work. For instance, the F9: subHandles | ADA Handle project quotes the following hourly rates for its own budget:

• [Most similar to CIP Editing work] Project Management: $70/hour
• Web & Graphic Design: $100/hour
• Programming & Development: $120/hour

Does <u>the CIP process itself</u> offer a "return on investment"?

Yes, according to these observations of CIP-based standards in the past and expected in the near future:

• NFT standards have supported the most economically valuable of Cardano's interactive components (ref: Mandala blog).
• Wallet standards will drive many commercial implementations, promoting ada as a currency and therefore increased market capitalisation and utility driving a higher ADA value.
• Governance standards will help dismiss claims of centralised control including the notion that Cardano is a "security" and must be registered as an investment proposition: while irrefutably decentralised governance will promote less regulated adoption with greater capitalisation and liquidity also supporting a higher ADA value.

(https://cosd.com/meta/catalyst-f10-ada-usd-2.png)) (XLS): 17 Jul 2023 08:43 UTC

• (as close as possible to proposal finalisation date: 17 Jul 2023 11:00 UTC)
• (note outgoing Fund 9 Catalyst payments have also used 4 significant digits in conversions)

37500 / 0.2910 = 128866 ada

(https://docs.projectcatalyst.io/catalyst-basics/how-to-submit-a-proposal/fund10-milestone-based-funding-guidelines/what-milestones-should-be-included-in-the-statement-of-milestones) after funding approval. I will suggest equal parts over 12 project months unless Catalyst milestone requirements indicate otherwise, in which I will try to make those payments as equal as possible for 12 months.

Payment period: First Fund 9 payment was on 08 November 2022, for a 12-month funding period. Therefore, to ensure continuity of both project and payments:

• The first payment should be delivered in November 2023.
• The final payment should be delivered in the final month beginning October 2024.