Tracking protocol parameters definitions

[Ryun1]

Following discussions from CIP Editors call # 92, inspired by comments on #847 (here, here, here).

What?

• Protocol parameters being to referred to with different names increases the chances of mistaken identity
  • This is increasingly more important under the age of Voltaire, where DReps, CC and SPOs are expected to evaluate and vote on changes to the protocol parameters.
• Historically naming and description has been achieved via CIPs, such as CIP-09 | Protocol Parameters (Shelley Era)
  • Although continuing to track protocol parameter value settings via CIPs is probably an unnecessary burden post Voltaire

[rphair]

I put in a suggestion in the above referenced discussion to list & define the parameter terms on a GitHub Wiki (which would provide alphabetised [but not groupable] navigation for & sort them, without requiring a quorum of editors to update even "little" changes).

@WhatisRT had offered one of the Ledger repos (one possibly too technical to be much in the public eye) which could house a Wiki but the additional reservation came up with the community (one which I had also felt) that housing this list in a neutral territory not explicitly controlled by any Cardano entity would be considered politically neutral & perhaps better maintainable.

I was very happy to conceive at the meeting we could simply store parameters in a single file or directory starting at the root of the CIPs repository. The existing maintainers of this parameter list (cc @lehins @Hornan7) can submit an initial PR against the repository to add a file or directory according to file/directory names & organisational principles they think are best.

The initial posting & updates will be approved by CIP editor quorum (@Ryun1 @Crypto2099) after documenting that they are valid changes from a valid source, and we will avoid the bureaucratic fatigue pointed out by @kevinhammond that I also observed: having to classify these changes through one or more CIPs, and providing agreed-upon checkpoints at era boundaries (I believe the GitHub commit history will serve just as well for the latter, when required: an idea expressed for CIPs themselves originally by @KtorZ).

The result would be easily findable and linkable, and make it possible for PR's to be filed against the file(s) by anyone in the Cardano community who thinks they have identified a mistake or a necessary update, as well as Issues and even Discussions if appropriate. And of course let me reiterate that it won't be practical to store the values of these parameters in the file... being changeable soon by any governance decision... it will just provide a high profile location for unambiguous, official names & definitions.

[Ryun1]

we could simply store parameters in a single file or directory starting at the root of the CIPs repository.

If we are storing a file in the CIPs repo, it might as well be a CIP 😆

Im happy to take a swing at this, Im thinking a single CIP that is versioned/ updated per era
primarily focussing on explaining purpose of each parameter as well as its nicknames as such

having to classify these changes through one or more CIPs

I think with Conway forward, multiple CIPs is the wrong approach
Past iterations of these CIPs have tried to record the current protocol parameter values, this unnecessarily adds burden, and would be difficult to maintain post post Chang

And of course let me reiterate that it won't be practical to store the values of these parameters in the file...

100% agree

[rphair]

@Ryun1 it sounds like it would work well that way. The main composers & reviewers in the "old days" of the parameter CIPs (@kevinhammond @KtorZ @JaredCorduan) would recall the irreconcilability that led to abandonment of the process... but the two key differences of a single CIP + no recorded values would avoid the main point of contention as I recall: whether to update prior CIPs with new ledger eras or create new ones.

I also think your approach would be more readable & usable by implementors and governance participants, allowing them to see an evolution over time... not so important to save clicks into other documents, but rather that they won't have to switch with each ledger era CIP to a differently authored document having different style and organisation.