<h1>Categories and document types<br>
</h1>
<p>relevant posted threads<br>
</p>
<ul>
<li>New Type? CRC: community standards &amp; best practices (<a
href="https://github.com/cardano-foundation/CIPs/issues/1040">CIPs
#1040</a>)</li>
<li>Managing a Shared Ledger: New CIP-Like Process? (<a
href="https://forum.cardano.org/t/managing-a-shared-ledger-new-cip-like-process/145575">Cardano
Forum</a>)<br>
</li>
</ul>
<h2>comments</h2>
<p>Josh &amp; background from Node Diversity Workshop (<a
href="https://discord.com/channels/971785110770831360/1375190972476035143/1381671604735443045">Discord</a>)</p>
<ul>
<li>elaborating this earlier (<a
href="https://github.com/cardano-foundation/CIPs/issues/1040#issuecomment-2898386756">GitHub
comment</a>)<br>
</li>
<li>discussions have been held in private &amp; on Cardano Scaling
discord already</li>
<li>
Ledger process issue confirmed, but not main concern</li>
<li>mainly considering model Ethereum split into at this point: (<a
href="https://github.com/ethereum/EIPs/pull/7206">Move ERCs to
separate repository #7206</a>) in this discussions are held on
forums instead of GitHub (<a href="https://ethereum-magicians.org/"
moz-do-not-send="true">Ethereum Magicians</a> &amp; <a
href="https://ethresear.ch">Ethereum Research</a>)</li>
<li>specific CIP &amp; CRC types could allow optimised processes for
each... though not necessary to "split" to do this.</li>
</ul>
<p>Robert consideration (<a
href="https://discord.com/channels/971785110770831360/1375190972476035143/1381746606805880913">Discord</a>)</p>
<ul>
<li>Most important would be determining a complete taxonomy,
highlighted by any process differences different between one part of
that taxonomy &amp; another.</li>
<ul>
<li>Example: Ledger if its own category suggested multiple
sub-categories, each with different review / consensus processes
(as offered here).</li>
</ul>
<li>Mainly emphasised that no reconsideration of our originally
conceived model of review on GitHub should ever compromise on "peer"
review itself.<br>
</li>
</ul>
<p>KtorZ, mainly offering that original CIP process encompasses all
this: if devs, architects &amp; reviewers will commit more to using it
(<a
href="https://github.com/cardano-foundation/CIPs/issues/1040#issuecomment-2900043491"
moz-do-not-send="true">GitHub</a>)</p>
<ul>
<li>Nobody can be forced to follow CIPs: so anything requiring
"enforcement" should be elsewhere.</li>
<li>CIPs already contain "implementation details" and "community
standards" so we don't need another category to accommodate these.</li>
<li>Lack of sufficient consensus has <u>not been a shortcoming of
editors</u> since they are not providing (only checking) the
review... <u>we need more reviewers</u> (especially "champions" for
each category).</li>
</ul>
<p>Ryan (editor) made arguments in favour of a conservative processs (<a
href="https://forum.cardano.org/t/managing-a-shared-ledger-new-cip-like-process/145575/10">Forum</a>
&amp; <a
href="https://github.com/cardano-foundation/CIPs/issues/1040#issuecomment-2962393046">GitHub</a>
in parallel)</p>
<ul>
<li>CIP process is already covering most demanding standards work on
the basis of their voluntary, deliberate &amp; close participation
(e.g. Haskell node)</li>
<li>Teams don't have to "collaborate through the CIP process" as long
as their agreements are eventually *defined* in it.</li>
<li>first step: "re-define the core categories (those will require
close collaboration between node teams)"</li>
<li>Creating a divergent category (CRC) would be too radical a change
to allow the necessary focus on improving existing issues.<br>
</li>
</ul>
<h2>questions</h2>
<p>What part(s) of a potentially expanded taxonomy of CIP categories or
types would have different review &amp; acceptance processes than the
bulk of the others would?</p>
<p>Why did Ethereum devs think they could not keep ERCs on same
repository as EIP's?<br>
</p>
<ul>
<li>Was it because they found editorial privileges irreconcilable
between the two efforts &amp; so had to define these through GitHub
itself?</li>
</ul>
<p>How would the quality of "peer review" be established if standards
document were reviewed somewhere other than GitHub &amp; our
conventional PR process?</p>
<p>How can CIP core categories be re-defined to encourage better
participation by teams working on different nodes?<br>
</p>
<p></p>
<h2>proposals</h2>
<p>TBD<br>
</p>
<h2>resolutions</h2>
<p>TBD
</p>