Proposal: Introducing Governance Standards for Filecoin Request for Comment (FRC)

[kaitlin-beegle]

Proposal: Introducing Governance Standards for Filecoin Request for Comment (FRC)

The purpose of this discussion is to propose a new type of Filecoin governance standard: a Filecoin Request for Comment, or FRC.

Much like any other Request for Comment, an FRC is designed to codify standards, methods, and best-practices for Filecoin network development.

Whereas Filecoin Improvement Proposals (FIPs) exist to support the collaborative development and community decision-making around core changes to the Filecoin codebase, FRCs are designed to propose and maintain community standards for network application standards, non-core protocols, etc.

In other words, FRCs govern network recommendations. These recommendations may benefit from universal implementation, but they are not consensus -dependent.

Governing FRCs

Like FIPs, FRCs must be governed by the broader Filecoin community. This means creating a process which supports:

• Open access to all information and knowledge contributed to FRCs;
• Public management of drafts, comments, revisions, and other development artifacts;
• Governing transparency, including full visibility into the management and maintenance of FRCs, and;
• Trusted participation, wherein any member of the Filecoin community can write, comment, question, and/or signficantly contribute to any element of the FRC process, including its governance.

The proposed FRC workflow is thus designed to support these principles, while also considering the needs of the Filecoin community. These needs include the preference for a lightweight acceptance process, limited time for engaging in complex technical proposals, and the fungibility of standards as the network changes and grows.

FRC Workflow

The process of developing FRCs can be broadly broken into the following buckets:

1. Community introduction
2. Technical review
3. Last Call
4. Acceptance

In many ways, this process is identical to the acceptance process for FIPs. In both scenarios, community members are invited to introduce their topic through the creation of a Discussion Post in the FIPs repo, to merge a draft into the repo as soon as it reaches preliminary completion, and to engage in a review process with technical auditors. During this process and prior to final acceptance, community members are welcome to weigh in with questions, ideas, and notes on their support for the FRC, which the FRC author must address.

There are two significant differences between the FIP and FRC workflows. These items concern the role of Core Devs and FIP Editors, as well as the status of accepted FRCs.

First, it is recommended that FIP Editors and Core Devs be given initial approval authority for FRCs. Whereas Core Devs and FIP Editors merely facilitate the FIPs process, providing a neutral assessment of the technical feasibility of proposals, it is recommended that they give initial sign-off for FRCs. In this process, approval by Core Devs and consent from FIP Editors would automatically start the 'last call' period for the FRC.

In short, this process will significantly speed up the process of FRC adoption. In most instances, FRCs will be less complex in their design than FIPs, and are inherently less burdensome to implement. Creating a more explicit approval process for FRCs reflects the fact that FRCs will require fewer rounds of review and are more changeable post-implementation.

Second, the process of updating FRCs should be more flexible than it is for FIPs. Given a FIP's consensus requirements, proposing changes to an active FIP requires authoring and achieving community acceptance on an entirely new FIP. For FRCs, however, it is likely that protocol specifications or other standards will occasionally need to be updated in order to remain current.

In these instances, proposed changes should be opened as PRs against the original FRC, with all changes approved by Core Devs. Notice will be made to the broader community, and community members are always welcome to weigh in or propose alternatives, but no formal community notice period will be required to update an existing FRC.

Notably, FRCs should only be deprecated or entirely superseded with the publication and acceptance of an entirely new FRC. The threshold for changes concerns documentation: if updates can be made to an existing document, without changing the spirit or intent of the original FRC, then the record of change will be preserved in the repo and the change can be simply made. If an item needs to be fundamentally changed, the record of change will need to come in the form of new documentation.

The complete FRC workflow can be visualized as the following

Management & Organization

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.

FRCs ought to be organized in their own folder within the existing FIPs repository.

All other management and oversight will be managed by FIP Editors as it is for the FIPs process.

Open Questions & Needs

The purpose of publishing this proposal is to gather input, ideas, and feedback, so that any eventual FRC process is clearly defined, useful, and legitimate when implemented.

The following represent other considerations and ideas that may be of interest to other stakeholders:

• Renaming the FIPs repo
  • The default term for community decision making is 'governance'. FIPs are merely one mechanism of governance, and introducing an FRC standard immediately makes the name of the repo a bit restrictive. I think we should change the name of the repo to 'governance', but will first need to check and see if this is going to break all of the links in the repo.
• Community Voting on FRCs
  • It seems reasonable for Core Devs to play a more active and executive role in approving FRCs. However, there are principled reasons to be opposed to this. For those who are, it may also be worth considering introducing a voting mechanism for FRCs. Unlike FIPs, opnions on the usefulness of FRCs may be more appropriately executed in a binary (yes/no) decision. I personally think this pathway is unnecessary, and will add complexity to the governing process, but it is an option worth noting.
• Non-technical FRC
  • It is worth considering what non-technical FRCs may look like and whether or not they ought to be outlined as part of this process. Though this would diverge from the traditional definition of what an FRC is supposed to be, I can think of use cases where non-technical standards (e.g., brand elements for community use, guidance for setting up new working groups, the Filecoin Community Code of Conduct, etc.,) may benefit from a being incorporated within a governing process. I'd be eager to hear what others think about this!

[jennijuju]

Jfyi there are a couple typos on FRC -> RFC.

The proposal in general looks great to me. One thing I’m slightly oppose to is to rename FIP repo to governance. I personally think improvement proposals is a much more direct and concrete description of what we are trying to do here than governance. Rather than “FIP is one mechanism of governance”, I personally think it’s more of “improvement proposals are submitted for consideration of filecoin technical development, and they are being evaluated through a governance process defined by filecoin community”.

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

[jennijuju]

I personally would suggest to keep this FIP repo to only cover the technical proposals for the filecoin network development.

Non-technical FRC, like community CoC, may live and governed in another repository/platform(like community repo) ,and governed by different groups other than core devs (like community ambassadors).

[lerajk]

Yes, agreed on the above.

[kaitlin-beegle]

Great point, re: diffuse decision-making for community needs! I agree.

[kaitlin-beegle]

(Oh also I fixed the typos, haha)

[lerajk]

A few initial thoughts:

• it seems that the FRC is the process by which we want to manage the FIPs. So, each new FIP will follow this FRC process ideally
• last call for 2 weeks is too short. We should do at-least 4 or 6 weeks
• not sure if we have it currently, but it would be good to have a few administrators for FIP approval or rejections. This is not the same as the FIP editor or author. These people could be core FRC members. For admin purposes we could maintain a list of these current 'Core Devs', FIP administrators, FRC administrators openly
• FIPs should be generally technical and focus on core technology items for the Filecoin protocol. There could be however tags such as Application Layer FIPs (e.g. ERC) or Governance FIPs (e.g. Meta) for non core FIPs. For core FIPS, we don't necessarily need a large community participation. The core FIPs could be directly managed by Core Devs (PL, node implementations, projects building on the Filecoin network).

[anorth]

Could you clarify how you think "administrators for FIP approval or rejections" is different from the current FIP Editor role?

[kaitlin-beegle]

Hi @lerajk - thanks for your feedback! A few points:

1. The FRC process is not the process by which we govern FIPs; that process is outlined here. FIPs and FRCs are related, but ultimately separate documents, which exist on different levels of complexity. The processes for each are thus differentiated.
2. Can you explain a bit more about why you think 2 weeks is too short? This is also the period of time we use for FIPs. As a reminder, last call is a period for broad community feedback, not for technical review.
3. We do not explicitly approve or reject any proposals. Please remember that this is designed to be an open community process that scales over time with community size and member participation. The FIPs process primarily operates as a decentralized social management layer for technical changes; if we wanted to be as efficient as possible for technical enhancements and implementers, we wouldn't be open source and decentralized :)
4. Respectfully disagree. We originally had FIP tags and they were more confusing than they were meaningful. I think separating out FIPs and FRCs as two different types of community proposal is a simple way to distinguish one from the other. Further subdividing these by type doesn't impact the way they are governed or reviewed.

[lerajk]

sorry, some misunderstanding on my end 😅 Providing some clarifications:

1. thank you for sharing the FIP process @kaitlin-beegle However, it is still a little unclear to me where does FRC fit in and the working relationship between FRC and FIPs. FRCs seem to be like the meta EIPs OR informational EIPs to me at the moment
2. 2 weeks is fine for broad community feedback. I think we should ensure that FRCs or FIPs get their last call in a core dev call. If the call frequency changes, then we should probably change the last call timeframe?
3. this was a misunderstanding on my end for the role of FIP editor. What I proposed for an FIP administrator is basically the FIP editor @anorth
4. not sure if we are talking about the same thing here. By tags I meant what EIPs have currently (e.g. ERC, Core, Networking, Meta, Interface, Informational)

[anorth]

Thanks Kaitlin, broadly 👍 . I have some concrete implementation details to propose, which may then feed back to the high level.

• Unlike FIPs, I think that acceptance for an FRC should come after wide adoption, not as a pre-requisite for it. We see this in many web standards, as well as existing crypto processes like ERCs. The proposal process for FRCs must be lightweight (including getting an FRC number), but there is no rush to invoke an "official" rubber stamp. I would expect FRCs to remain in "draft" for looong periods. So I do think that appointing FIP Editors as approvers makes sense, but not for the reason of speeding up adoption – simply because they're a handy body to delegate the role of observing adoption and subsequently reflecting it in the process.
• A long draft period during implementation/adoption also means that updating FRCs is just by PR, as you describe. Which becomes no different to FIPs. I wouldn't expect an FRC that's widely adopted, and thence accepted, to subsequently change much.
• While not a subtype of FIPs, I think FRCs should share the same numbering namespace, as ERCs do with EIPs. So there can be no FRC with the same number as a FIP. This is quite valuable to avoid confusion to people not intimately familiar with the various gov processes.

To your items of consideration:

• Renaming the repo: I don't think is worthwhile. I largely concur with @jennijuju and think that FIPs is a nice short handle for the stuff that happens here.
• Voting: I don't think necessary, for reasons stated above. Community vote by adopting a standard.
• Non-technical: Unsure. I could imagine some good use case. I propose we wait until a concrete one comes along to use as a test case.

[kaitlin-beegle]

Thanks @anorth! All of these points are great; I agree. We ought to redefine the adoption process in the way you've described.

[kaitlin-beegle]

Given several weeks of feedback, it seems clear that an FRC standard is generally necessary and that the process as specified above works for the Filecoin community.

It will ultimately be necessary for these changes to be solidified as an update to and PR against FIP0001. Prior to this, however, I'd like to propose that we "test drive" this process by creating FRC documentation for two currently available standards: Boost, and the Filecoin Indexer Advertisement Protocol.

Per feedback (above), FRC standards should be adopted through consensus over time; unlike FIPs, there is no necessary threshold for their inclusion. As such, we should move forward with putting the FRC procedure in place, and then pushing formal documentation changes only once we have had the chance to tweak and make adjustments to the practice of writing and documenting FRCs.

One part of this documentation that I think will require considerable iteration is the FRC template. As a starting point, we should adopt the FIP template as-is, and can make adjustments as-needed. Certain clarifications need to be made to the template in general; these will be pushed with other FIP0001 changes.

The only exception to this path forward is the inclusion of DEPENDENCIES in the header. All FRCs should be sure to clearly mark other dependencies or network standards/pathways which may require or be affected by the FRC in question.

As a next step, a folder will be created in the FIPs repo specifically for FRCs, and both the Boost and Indexer Advertisement Protocol documents will be added. Additional supporting documentation- for Core Devs, etc.,- will be added to the TPM repo.

[f8-ptrk]

this should be documented in the FIP README.md as it seems to be actively used - as long as the FRC repo doesn't exist!