Deep-Dive: Filecoin Improvement Proposals (FIPs) #314
Replies: 6 comments 12 replies
-
|
Thank you for creating this! I think it’s important in implementation section we specify that: FIP implementation May be proposed, contributed/implemented by non-core devs. |
Beta Was this translation helpful? Give feedback.
-
|
Yes!! But, I think that should perhaps be specified elsewhere. There's a long list of documentation needs that I'm keeping track of, and 'What is a Core Dev?' is one of them. This is a great call-out, though. |
Beta Was this translation helpful? Give feedback.
-
|
@kaitlin-beegle thank you for doing this, this is a great thing to have. 🎉 What is the expected time window for any community member to raise things and does this mean that we need to close all open comments we have in the FIP discussion before we move things into the accepted state? |
Beta Was this translation helpful? Give feedback.
-
|
Hi Dragan! Good question- I was worried that this phrasing may be confusing, actually. However, community members have until the expiration of the 'Last Call' period to raise new issues; that's the window. Open comments don't need to be closed, necessarily, but addressed. Importantly, the things which would prevent a FIP from being accepted would be new, significant concerns, including questions about the security of a proposal, it's impact on a certain stakeholder group within the Filecoin ecosystem, or the spirit of change. Once a FIP has passed into 'accepted' status, it's my opinion that the discussion post can remain open. If anyone wants to ask additional questions about implementation, prepare a post-implementation impact study (as some cryptoecon folks sometimes do), or re-open a conversation about the status of the FIP, they're welcome to do so there. However, the author can also lock the post if they wish. I don't think it matters too much. Someone can always just open a new discussion. Does that answer all of your questions? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks Kaitlin, this is great. I've a question about acceptance. Who exactly is the body responsible for and empowered to accept FIPs? That's not clearly spelled out here, but I think your proposal is the FIP editors (by what internal process need not be set in stone). Not, the implementers / core devs (whoever they are). Of course the editors would pay attention to input from the implementers, but ultimately own the decision. I also read that the threshold for acceptance is not having a majority of community members (by some metrics) voice disagreement. I think (weak opinion) that this threshold may be too low. It sets up a default outcome of acceptance for a persistent author that is not based on technical or other merits of the proposal, as much as lack of obvious flaws. In fact there may even be flaws, but if informed but busy people like the implementers are not reliably drawn in, they might not be voiced. We will always have a surfeit of ideas and a shortage of people to realise them, and change is costly, so I think this balance is off. I think we should hold a higher standard of expected benefit, given that implementers become obliged to follow through. And I'm not sure the editors are the right people to make that call from a pulse of the community. From the EIP process: "The editors don’t pass judgment on EIPs. We merely do the administrative & editorial part." Maybe there's enough wiggle room in "They are allowed to prioritize FIPs for inclusion as their interest and capacity allows" to indefinitely defer implementation of low value FIPs, but I don't think that's what you're aiming for, and could look like a governance flaw. I think balance could be restored if acceptance required a somewhat active acceptance by a committee of people or organisations (probably needs to be named, and would change over time) representing the core devs / implementations at least (+maybe others), rather than only a passive lack of opposition. And they should be able to defer based on "just not important enough". The editors might still administer this, but require the asset of this committee. I still like the decoupling of the timing of FIP acceptance from implementation, and I think this proposal does that well. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @anorth! Thanks for taking the time to leave this feedback! These are great questions. To your first point, the "body" responsible for reaching consensus is the broadly defined "Filecoin community". You're correct that implementers and Core Devs are not singularly responsible for approving and/or accepting FIPs. You're also correct that this creates a scenario of "default outcome of acceptance" for certain FIPs. This is not a byproduct of the process, however, but is quite intentional. There are several reasons for this:
I'd also note that certain teams/people (such as the Protocol Opportunities org) are uniquely positioned to write and push FIPs. These orgs have deep knowledge about the Filecoin protocol and have been involved in the network since its founding. For these people/groups, the FIPs process likely seems like more of a technicality than a procedure. That's probably because the goal of the FIPs process is to deliver high-quality, meaningful proposals that generate positive improvements for broad swaths of network participants, which is exactly what a select group of deeply involved people/groups are designed to deliver. For community members outside of these structures, however, the FIPs process is much more exacting, and requires much more public collaboration and development of ideas, multiple iterations of a proposal, and guidance from Core Devs and FIP editors to get to a point at which the FIP can be considered reasonable and complete. The effect is a process that is long and requires consistent engagement- if your idea isn't fundamentally good, it won't make it. Re: a committee, I'm not opposed on principle, but I will say that this type of structure would be quite difficult to design and implement. If one shared goal for the network is increasing decentralization over time, implementing committee deliberation may be difficult to justify. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks Kaitlin, very helpful. I still take issue with the poorly defined empowerment to make decisions. "The Filecoin Community" cannot make a decision; we can't even identify who they are. Some much smaller and clearly defined group needs to make actual decisions on their behalf. This proposal implicitly puts the editors in that role. I think we should make it explicit, perhaps clarifying the mandate upon which the editors should act. |
Beta Was this translation helpful? Give feedback.
-
|
I certainly hear what you're saying. I think it's important to remember that open governance is predicated on community processes, and that's who this process is designed to serve. So while I agree with your concern, I want to be thoughtful about how rigid we make barriers to FIP acceptance. Why don't I write up a proposal to more firmly codify the roles of both FIP Editors and Core Devs, and we go from there? Also happy to discuss at the next Core Devs call. |
Beta Was this translation helpful? Give feedback.
-
|
Confirmed! Discussion item added to this week's Core Devs agenda. |
Beta Was this translation helpful? Give feedback.
-
|
I'm also a little concerned by the "majority of community members voicing disagreement" test which can prevent a FIP progressing. Without defining the in-group for this community, this could make it easy for a vocal group to halt a change that is good for the network as a whole, because it disadvantages them. An example such group might be SP's who invested early to extract block reward, but don't take deals and are not committed to the long term service goals of Filecoin – they'll cut and run when better opportunities come up elsewhere. They might have a very big stake in, say, preventing changes that raise the required quality of service provided by SPs, or adjusting reward schedules to incentivise future participants. I don't think all potential commenters are equal. Some are more bought in than others. The developers are an obvious group. SPs as a whole are another obvious one, though with different time orientations. Clients are a big one, probably well aligned, though perhaps less necessarily committed. |
Beta Was this translation helpful? Give feedback.
-
|
From my perspective, issue capture by a single stakeholder group is one of the biggest risks we'll have to design against as we scale! |
Beta Was this translation helpful? Give feedback.
-
|
Once a FIP is accepted and implemented, would there be metrics to evaluate the long-term successfulness of the FIP? Say if a FIP turned out to be disastrous/ineffective to the protocol, the community and stakeholders, will there be a process to overturn the said FIP? |
Beta Was this translation helpful? Give feedback.
-
|
That's a great question! Importantly, there is a lot of work that currently goes in to ensuring that FIPs won't be disastrous for the protocol. Security, cryptoeconomic, and technical feasibility concerns are always considered by FIP editors and Core Devs while considering FIP drafts, and we're working to make these processes clearer and more open (beginning with formal procedures for cryptoeconomic audits!) That said, you're right: if something disastrous was put in place, it would need to be overturned. That overturning would be a protocol change, so it would also be a FIP (FIPs can supersede other FIPs). In an emergency situation, it would likely be expedited, and an all-hands-on-deck and crisis communication approach would be taken to ensure community members are aware, in-sync, and alerted to what was happening. Re: metrics, this is something that is quite challenging to do! All FIPs are different, and each affects different components of the community and/or protocol. It's very hard to standardize post-implementation analyses because the variables we might look to measure are either variable or not easily measured. That said, a few teams (including CryptoEconLab, Block.science, and Starboard) are looking for ways to provide better models and analyses for FIPs, so we may see them become more vocal contributors to the FIPs process in the coming months! Do you have specific types of metrics you'd like to see measured, or any particular analysis you think we should implement? |
Beta Was this translation helpful? Give feedback.
-
|
Haven't fully contemplated on that regard either. But using example of hyperdrive, I think one of the metrics could be general "activeness" of the overall filecoin storage on-boarding activities. If the goal is to have a higher bandwidth while maintaining the designed token economics (protocol revenue etc.), then daily growth of storage power before the upgrade should be at least same or less than after the upgrade for span of at least a year or so. That said, even the result turned out to be unfavorable, it wouldn't be necessary to overturn such FIP. More like a reflection for future precaution I guess? |
Beta Was this translation helpful? Give feedback.
-
|
Definitely; that's a good point. One thing to consider is the protocol's current stage of development. It's easy to think of Filecoin as a mature entity since we work in it every day, but there are still many years of technical development ahead of us. As a result, a lot of current FIPs (such as Hyperdrive, or the upcoming FVM) are focused on providing greater network capacity and functionality. At worst, realized growth doesn't meet expectations, but there is no concrete risk of "failure" other than poor prioritization of needs. I think there are two sides of this coin! On the one hand, we can keep working to be smarter and more informed about FIPs and network changes. This is slow and difficult work, but we should still continue to do it! On the other hand, however, we're all just community members in an open-source project. If there are particular analyses that community members want to see, or concerns that they have, they need to make them known in order for us to allocate resources to address them :) |
Beta Was this translation helpful? Give feedback.
-
|
In case of #390, it seems that once a FIP is in stage 2 then as long as the FIP editors and core dev approves the FIP then the community has little ways to influence the FIP anyway. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for asking about this. This is certainly not the case, so I want to be sure to clarify: Anyone can open or push a FIP draft at any time. If it's complete, then great, it can stay in the repo for review. We ask everyone to open up discussion posts so that we have a place to ask questions, raise concerns, etc. It is preferred that teams open up discussion posts as soon as they start thinking about a FIP, so that 1) the community can weigh in early on, and 2) so that Core Devs and FIP Editors are aware of what's in the pipeline. However, teams don't always do this. In this case, the team shipped a FIP draft and then opened up a discussion post. Although this is not preferred, and is not a best practice, it doesn't change the fact that all FIPs are only accepted by the community. Currently, community members can raise issues and conversation topics around this proposal, or even request changes be made. Once the draft is completed, the FIP will only be accepted after a successful Last Call period, which is a community process. Neither Core Devs nor FIP Editors "approve" FIPs outright. They may review them for technical feasibility and are broadly responsible for implementation, but acceptance is a community process. CC: @vkalghatgi |
Beta Was this translation helpful? Give feedback.
-
|
Got it! Thanks for the clarifications! So stage 2 is largely just for technical evaluation, correct? The wording on...
seem to leave a lot of rooms for ambiguity.
|
Beta Was this translation helpful? Give feedback.
-
As an open-source and decentralized protocol, FIPs play a critical role in the public governance of the Filecoin network. FIPs are the central mechanism through which changes to the Filecoin ecosystem are proposed, deliberated, and implemented, as well as the primary way in which community members collectively govern the network.
The first purpose of this document is to provide a detailed overview of the FIPs process and workflow. For FIPs to operate as a community tool, documentation must be ample. The intent of this piece of documentation is to outline the FIPs process, agnostic of any particular stakeholder or specific community member's experience writing FIPs or participating in governance.
The second purpose of this document is to codify as process the organic changes that have occurred through the Filecoin Community's practice of governance. Although the FIPs process was originally modeled on the Ethereum Process Improvement (EIP) process, it has since diverged in nuanced ways. Governance design is ultimately a process unique to each project, and the below guidance is premised on the evolving preferences of the Filecoin community.*
Stage 1: Idea
All FIPs start as ideas. These ideas can originate in any place, and come from anyone. As a large and diffuse community, ideas for FIPs often originate in public Filecoin Slack channels, working group meetings, in-person ecosystem events, and various project repos.
In order to ensure that the decentralized origin of ideas does not affect the transparency and accessibility of ideas, community members are asked to add their ideas to the FIP Discussion Forum as soon as they begin working on them.
Community deliberation is a central component of the FIPs process. Adding ideas to the Discussion Forum is important for flagging the idea to others, gathering early input, and identifying other community members who may want to collaborate on developing the FIP. Even if the idea is quick and unrefined, the discussion forum is the primary governance repo, keeping tabs on what community members are thinking about, and how they're thinking about them.
However, it is important that community members who wish to author FIPs (especially those who may be new to open-source environments) recognize that discussion posts are not optional. The person who opens the discussion post will be considered the FIP Author and is responsible for 1) updating their discussion post, and 2) moderating and responding to community feedback on their post.
When opening up a discussion post:
Once opened, discussion posts will permanently remain in the Discussion Forum.
Stage 2: Refinement
Once FIP Authors deem their ideas ready for formal review, they are welcome to push a FIP proposal to the Filecoin FIPs repo. Though discussion posts can be written in any format, FIP PRs must be formatted according to the FIP template.
Once a Pull Request is submitted, FIP Editors and Core Devs will review the proposal for completeness and feasibility.
In essence, submitting a Pull Request is an indication that your proposal is worthy of serious consideration and community resources. FIP Editors are stewards of these resources, and may reject your PR for failing to be reasonably complete or feasible. When this happens, feedback will be provided to the FIP Author, and additional work in the discussion post will be requested.
If your PR is accepted, additional work will commence. FIP Editors will review both content and specs, provide feedback, and request changes. Community members are likewise welcome to review, provide feedback, and ask questions on FIP PRs. The FIP Author will also be contacted and asked to present their proposal to Core Devs.
As before, the process of refining a FIP proposal can take quite a while. FIP Authors can significantly speed up this process by keeping their discussion post up-to-date, responding to questions, and addressing reviews on the PR.
Once preliminary feedback and review has been completed, and the PR updated, the FIP proposal will be merged into the repo. At this point, final work and refinements will continue until the FIP Author and FIP Editors consider the draft complete. Once this occurs, the FIP Author will be contacted to schedule their FIP for 'Last Call' status.
Stage 3: Acceptance
Throughout the process of creating a FIP, community members are asked to review, ask questions, and make suggestions on proposals. It is expected that the FIP Author is a public steward of their FIP, continuously seeking community feedback on their proposal, addressing questions and concerns, and moderating any public discussion which may arise in the discussion forum.
Once there is neither 1) outstanding technical work to be completed, nor 2) significant, unresolved community concerns about the proposal, the FIP Editors will schedule the FIP for 'Last Call' status.
Last Call status:
If the Last Call period expires without community members raising new and significant or previously unaddressed concerns, or without a majority of community members voicing disagreement with the spirit of change, the FIP will be accepted.
In the case of general disagreement with the FIP, or the raising of new questions or concerns, the FIP will fall out of Last Call status and revert to being a FIP draft. If community members overwhelmingly disagree with the FIP, it may be deferred. Otherwise, the FIP Author will need to fully address community questions and concerns before restarting the Last Call period at a later date.
Stage 4: Implementation
Within the Filecoin ecosystem, decisions about FIP implementation fall solely within the jurisdiction of Core Devs. Because of the role network implementers play in upgrading and driving network consensus, it is their responsibility to prioritize accepted FIPs and schedule them for inclusion in upcoming network versions. Implementers are also responsibile for working with FIP Authors to design the method of implementation (as necessary).
Importantly, network implementers are not allowed to opt out of incorporating an accepted FIP. They are instead allowed to prioritize FIPs for inclusion as their interest and capacity allows.
Summary
Governance is a community process driven by the Filecoin Improvement Proposals.
Anyone is able to write, review, or contribute to the creation of FIPs. Regardless of your role in the Filecoin community or level of technical knowledge, community members have equal access to the FIPs Discussion Forum and Repo and are invited to participate.
The stages outlined above- idea, refinement, acceptance, and implementation- represent a high-level workflow for anyone onboarding to Filecoin governance for the first time. As a next step, updates to existing documentation (including FIP0001) will be made, in order to bring all governance documentation into alignment.
As always, community members are invited to provide input directly on this post as well. Questions, ideas, or suggestions for improvement will be incorporated, and this post iterated over time.
*In 2021 Q1, Suggested Changes for Improving the FIPs Process identified community developments in FIPs stewardship, synthesized common points of failure, and proposed a revised process and set of expectations for FIPs. This proposal was implemented between the v14 and v15 network upgrades; feedback and revisions were captured in Core Devs meetings, as well as Github and Slack discussion posts. Recognizing that governance process design (i.e., 'metagovernance') is itself an act of governing, it is important to note that the guidance provided in this document is the result of months of community iteration, feedback, and public deliberation.
Beta Was this translation helpful? Give feedback.
All reactions