Alias informational to FRC

[jsoares]

The type listing in lines 27-31 defines 4 categories of technical FIPs: Core, Networking, Interface, Informational

FIPs/FIPS/fip-0001.md

Lines 27 to 31 in 440bbb4

	1. A **Technical FIP** (Filecoin Technical Proposal or **FTP**) describes any change that affects most or all Filecoin implementations, such as a change to the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Filecoin. Technical FIPs consist of three parts: a design document, an implementation, and, if warranted, an update to the [formal specification](https://filecoin-project.github.io/specs/). Furthermore, technical FIPs can be broken down into the following categories:
	- **Core** - improvements requiring a consensus upgrade, as well as changes that are not necessarily consensus critical but may be relevant to future consensus upgrades.
	- **Networking** - includes improvements to data propagation, or any of the Filecoin network protocols (see [Network Interface](https://spec.filecoin.io/#systems__filecoin_nodes__network) in the spec for a full listing).
	- **Interface** - includes improvements around client [API/RPC](https://spec.filecoin.io/#systems__filecoin_nodes__node_types__node-interface) specifications and standards, and also certain language-level standards like method names.
	- **Informational** - describes a Filecoin design issue, or provides general guidelines or information to the Filecoin community, but does not propose a new feature. Informational FTPs do not necessarily represent Filecoin community consensus or a recommendation, so users and implementers are free to ignore Informational FTPs or follow their advice.

The preamble spec in lines 114-116 defines 4 categories of technical FIPs: Core, Networking, Interface, FRC

FIPs/FIPS/fip-0001.md

Lines 114 to 116 in 440bbb4

	` type:` \<Technical (Core, Networking, Interface, FRC) | Organizational | Recovery\>
	` * category:` \<Core | Networking | Interface | FRC\>

Nowhere in the document is Informational aliased to FRC. In fact, FRC is never defined or mentioned outside of the preamble. Short of changing one of the two, this is the minimal edit to make that connection.

Note that this differs from EIP practice, in which ERCs are application-level standards and Informational EIPs are largely unused. Moving towards that would be a larger, substantive change, and one of questionable utility.

[jsoares]

This is not the only inconsistent practice. FRCs, despite being a subtype of FTPs (itself a type of FIP), are archived in a separate folder /FRCs, whereas entirely separate types of FIPs (FOPs, FRPs) are still archived under /FIPS. This breaks expectations with regard to hierarchical organisation.

[jennijuju]

I think the suggested change make sense - tho would like at least one more @fip-editors to ✅

[jennijuju]

Suggested change

	- **Interface** - includes improvements around client [API/RPC](https://spec.filecoin.io/#systems__filecoin_nodes__node_types__node-interface) specifications and standards, and also certain language-level standards like method names.
	- **Interface (FRC)** - includes improvements around client [API/RPC](https://spec.filecoin.io/#systems__filecoin_nodes__node_types__node-interface) specifications and standards, and also certain language-level standards like method names.

[jennijuju]

kinda wanna tagging along

according to the definition here: _ an FRC is designed to codify standards, methods, and best-practices for Filecoin network development._

[jsoares]

I completely missed that discussion, possibly because I was expecting to find a governance FIP instead.

It's not obvious to me that alignment was reached in that discussion, as @kaitlin-beegle's proposal explicitly stated:

FRCs are a component of the Filecoin governance system; they are not sub-types of FIPs. FIPs are distinct proposals for core network changes, while FRCs are non-consensus-bound network standards.

Whereas you counter-proposed:

I think FRC should be a subset of FIP, as core FIPs helps define the evolution of filecoin protocol, FRCs may help standardize non consensus parts of the protocol.

I think both are valid routes but what we have now is a Frankenstein of sorts. Beyond the inconsistencies in the file, for which the fix differs based on which approach is picked (option A: s/frc/informational/g, option B: s/informational/informational (frc)/g), the approach of using separate folders only really makes sense under Kaitlin's proposal.

In either case, and this is largely separate, we should better document the approval pipeline for FRCs.

[kaitlin-beegle]

Hey @jsoares, thanks for raising this issue. Part of how we get better standards, definitions, etc., is by opening these sorts of questions, so I appreciate that you took the time.

From a governance perspective, it doesn't matter much whether FRCs are considered a subset of FIPs, or a separate category of documentation.

My personal preference is for them to be separate only because the approval process is a bit different, and matters significantly less in the case of standards versus protocol changes.

I think the bigger issue is that FIP0001 is terribly out of date- we're actually in the process of updating the document, and the proposal I've been trying to socialize would remove some of the technical FIP subcategories. Since we do not often update FIP0001 (and, in fact, never have), we may want to collaborate on a single, large slate of updates, rather than modifying FIP0001 with this PR just to clarify FRCs/informational FIPs/etc. I think the clearest way forward would be to create a few distinct FIP categories for consensus -bound changes, and FRCs for standards. We can then iterate and add nuance to the FRC definition over time.

And, in the case of the open EC broadcast issue, I think it ought to be an FRC, if only because it's already been implemented/put into Lotus production and isn't consensus/upgrade dependent.

[jsoares]

@kaitlin-beegle I agree with you on the FRCs being a distinct type of document.

As for this PR, it doesn't represent an update to FIP-0001 or a substantive change, but a minimal fix for an internal inconsistency. It's almost inconsequential, and it seems that the problem may go away with the update, so fine if you want to wait. However, as a general principle, we should not delay fixing inconsistencies on account of things to come (I see the FRC discussion dates back to May...).

[kaitlin-beegle]

@jsoares great point! I agree; let's merge.