Filecoin Foundation FIP0001v2 Initiative

[kaitlin-beegle]

As the steward of the open source governance process for the Filecoin network, Filecoin Foundation is launching a new initiative to ensure that the network’s governance processes and tooling meet the changing needs of the growing Filecoin ecosystem.

Following months of research, we are kicking off the FIP0001v2 Initiative and asking Filecoin community members to collaborate with us on a community-driven effort to enhance the processes and tools of network governance.

There are three main workstreams that are part of this initiative:

1. Updates to FIP0001, which defines the FIPs process, to better reflect community needs.
2. Rolling Out Improved Tooling, to better enable the FIPs process, including tools for temperature checks, voting, and better discussion.
3. Aligning on Community Values, to drive consensus on the goals, needs, and priorities for the Filecoin network’s community governance

Some guiding principles for these workstreams are:

1. Proposed structural changes and improvements must be informed by existing challenges or ways of working, rather than theory and projection;
2. Governance systems must serve the entirety of the network, not just the interests of a few, and;
3. All governance processes are MVPs (minimal viable products) until proven otherwise.

With the above in mind, we welcome any interested community members to collaborate on this effort. Our initial proposed timeline for iteration and implementation is:

Activity	Estimated Date	Status
Initial community consultation on FIP0001v2 work	August	Ongoing :)
Initial publication of FIP0001v2 draft proposal	September	In progress
Iteration of FIP0001v2 proposal	End of September	Upcoming
Scoped tooling MVPs to support community FIP0001v2 proposal	End of September - October	In progress
PR against FIP0001 with final community proposal (start of Last Call)	October	Upcoming

As is the case with any community process, the above is only a projection, and is likely to change.

Call for Participants: FIP0001v2

Anyone who is interested is welcome and able to participate in the FIP0001v2 Initiative.

For this discussion, some initial questions for the community:

• Are there any other workstreams that you think need to be considered?
• Are there other guiding principles or assumptions that should be considered?

Going forward, there are many ways that you can participate:

• Share ideas, get updates, and participate in discussions by joining Community Governance Calls.
• Get updates, ask questions, and follow work developments by joining the #fil_gov Slack channel.
• Stay alert and up-to-date with major changes by following @fil_gov on Twitter.
• Join us in-person for workshops and discussions at the Filecoin Developer’s Summit.
  • Community and Governance Track 1 (Singapore, September 12 - September 14)
  • Community and Governance Track 2 (Iceland, September 25 - September 27)
• Join us in-person for workshops and discussions at FIL-Vegas, October 3 - October 5.

Major developments and updates will also be shared by Filecoin Foundation on its blog and Twitter account. Asking public questions is strongly encouraged, but you’re also welcome to schedule time to talk with me, Kaitlin Beegle, who will be coordinating this initiative – HERE are my office hours.

As an immediate step, we will be opening an initial discussion on both FIP0001 process updates and network tooling on Friday, August 25th. And, of course, we look forward to your ideas and feedback!

[jennijuju]

Updates to FIP0001, which defines the FIPs process, to better reflect community needs.

will have more to comment later once I got a min, but want to firstly capture the concern that's was raised in this thread.

IMHO, the current FIP process is lack of a reliable Peer Review period, where FIP's technical spec/implementation, security consideration, product/econ consideration and so on, are being reviewed before the FIP moves to Last Call. Currently, an FIP has few engagement from either broader community, core dev, or implementers, will just move through the FIP process if the author pushes for it.

This issue has appeared in a couple other occurrences:

• FIP-0057 was not properly reviewed by crypto Econ teams, and was accepted and finalized. It leads to undesired off-margin batch balancer threshold.
• FIP-0045 entered last call and was accepted, without the gas usage impact of the change being fully understood by the community. The change ended up increasing the data onboarding gas cost a lot for Storage Providers, and it is possible that if the gas increase was known, the community will not accept the FIP.
• FIP-0056's author request the FIP to be moved to last call, and. the governance team has proceed to a hybrid process for that FIP. However, the process started before the FIP has a technical spec/implementation prototype, which in fact later on, an implementer discovered that the proposed FIP has made a couple wrong assumptions on how things work and what's technically feasible - and the FIP as it was proposed, was not ready for Last Call.

Generally, the change Im looking for are

• (not only my own opinion) adding a requirement for an FIP should have a detailed spec/PoC implementation, thorough security consideration & product consideration; gas impact estimation if the change is very tied to network users d2d operation, before it moves to Last Call. (Note: This does not imply FIP authors must implement the FIP idea themselves, however, it does suggest that FIP authors should proactively work/collaborate with implementers or source contributors to help prototype and verify the idea could be realized.
• Adding a Peer Review status with sound expectations.
• FF governance team to be more proactively, or even more aggressively, to seek ways to increase high-quality engagement towards FIPs, and avoid lack of engagement on FIP to be considered as the FIP is 🟢 for acceptance.

[anorth]

The FIP process does have a peer review period. It is the period where it is in Draft plus the period in Last Call, and typically lasts for at least a month, sometimes many. I believe the problem underlying the linked slack thread is that the peers are not engaging in the review. People who should or would like to do review are deciding that it is less important than some other activities on their plate and then not doing it. There is no shortage of opportunity to review, the problem is one of priorities. I don't think that adding additional stages or process overhead will do anything to solve this problem.

I oppose preventing FIP acceptance due to lack of review engagement. Such a policy will make the priority problem even worse – it will be even easier to ignore reviewing someone else's work if there are no consequences. The default progress is the feature that can and should force review to be higher on people's priority lists. As a core dev and community reviewer you were free to ignore FIP-0067 for the two months that it was published prior to acceptance, but the proposal cannot be held hostage to your decision to do other things instead of review it. (I also believe something close to the same should go for PRs to draft FIPs, and am frustrated that editors deciding they have other priorities is causing so much friction to the communication of ideas).

I think this issue of lacking peer review is distinct from the question about what level of completeness we should require from a FIP before Last Call. We have learned that we need to set high requirements here, usually requiring a more-or-less complete implementation in order to be confident that all design decisions are explicit and implications discovered. I agree with this recommendation, but it's not really a change: FIP-0001 pretty much already requires this, we were just sloppy.

[Stebalien]

I agree that we need more involvement, but there really are two distinct stages to FIP development:

1. The proposal stage where everyone with a stake in the FIP are trying to figure out how/if something should be implemented.
2. The review stage where everyone else is trying to figure out how this FIP might interact with the rest of the system (security, cryptoecon, performance, clients, etc.).

Unfortunately, many people who need to be involved in the second stage don't have time to keep up with every in-flux FIP in the first stage. So what we need here is a point at which a FIP will actually stabilize for review. This could be the "Last Call", but, IMO, "Last Call" should really just be that: a final period to catch any last concerns.

Additionally:

1. We really do need to hold the bar for last call: last call means there is a solid implementation, analysis, testing, etc.
2. IMO, we need "area DRIs" for FIP review. These aren't gate-keepers and they have no veto power. Instead, they are responsible for reviewing each FIP in "peer review" with respect to their area, and will be replaced if they can't perform. At the moment, we suffer from diffusion of responsibility.

[jennijuju]

@anorth

The FIP process does have a peer review period. It is the period where it is in Draft plus the period in Last Call

This is not specified in FIP0001 - i think we should state it more clearly and setting the expectation of ✅ peer review.

Draft -- After the first Draft is merged, you may still submit follow-up pull requests with further changes until you believe the FIP to be mature and ready to proceed to the next status. A FIP in draft status must be implemented to be considered for promotion to the next status (ignore this requirement for core FIPs).
➡️ Last Call -- If agreeable, the FIP editor will assign Last Call status and set a review end date (review-period-end), normally 14 days later.
❌ Last Call -- A request for Last Call status will be denied if material changes are still expected to be made to the Draft. We hope that FIPs only enter Last Call once, so as to avoid unnecessary noise.
Last Call -- This FIP will be listed prominently on the Filecoin website
❌ -- A Last Call which results in material changes or substantial unaddressed technical complaints will cause the FIP to revert to Draft.
➡️ Accepted (Core FIPs only) -- A successful Last Call without material changes or unaddressed technical complaints will become Accepted.

I oppose preventing FIP acceptance due to lack of review engagement.

While i hear what you are saying and agreeing with most of it. However, generally i would also like to argue, an FIP without any or very low community engagement, core dev engagement and peer review across 3-6 weeks period (ideation, Draft, last call) implies network participants/stakeholders do not see the value of the FIP for the network, and i would further challenge the necessity of the FIP in that case for its to be accepted.

For example, in FIP-0067's case, I personally think it is very important as it is a network security related FIP and introduces potential critical SP operation, i would imagine at least:

• folks who have security insight would provide peer reviews to 👍 the probelm/concern is valid (this got some confirmation from FIP-0047) , the implementation urgency was defined properly, and the solution resolves the issue is valid.
• SPs 👍 the proposed approach is feasible and acceptable for them for the security of the network.

Unfortunatley, FIP-0067 doesn't receive any of the above and we are now at risk of

• unknown implementation challenges
• When the FIP is scheduled for an upgrade and needs to be actually performed, SPs are surprised with the suggested operations and have strong reservations. As a result, we have to revisit the FIP's acceptancence before it can be finalized.

I would like to at least, refine some rules/expectations for FIP authors, or core devs, or FIP editors (ownership to be discussed) to be more proactively "recruiting" high quality peer reviews.

. Instead, they are responsible for reviewing each FIP in "peer review" with respect to their area, and will be replaced if they can't perform.

Starting a FIP peer review pool, is one of the ideas worth considering imho.

[kaitlin-beegle]

I broadly agree with Alex and Steb. The problem is the high bar of diffuse trust that exists amongst reviewers, and a little bit of bystander apathy.

To be clear, I don't think FIP0001 process improvements is actually the context for driving improvements in the FIP review process. FIP0001 should act like a constitution, outlining the high-level purpose, obligations, and guiding structures that build our governance system. The operational choices which define these processes- such as rules and standards for review, the role of Core Devs, processes for merging FIPs, etc.- should be defined elsewhere. They help us do our work, but they are (and should be) relatively malleable as needs change.

Fwiw, we're building out a docs repo, so that these processes and rules can be documented and iterated more clearly. Right now, they more or less live as undocumented norms, in part because of how frequently governance needs have changed over the last 1.5 years. This needs to change.

As far as actually addressing this issue goes, I don't think there's a clear solution.

• This is a typical OS challenge. No one person owns this process, and communication practices can only go so far.
• I am not a fan of having the governance team- me and Lucky- more aggressively chase people down. We already do quite a bit of this, it's fun for no one, and I don't think it will significantly improve this process. It will add more noise, and isn't a solution that generally supports more decentralized, public workflows.
• I am a fan of requiring a full implementation to accompany FIPs before we determine that the draft is finalized- this would certainly help us decentralize the upgrade and implementation processes down the line- but please keep in mind that this would likely cause a significant delay in the average acceptance time for FIPs.

I also like Steb's idea of having designated reviewers in certain focus areas. This is usually a security best-practice for peer review processes. However, this is also more-or-less the intent of FIP Editors right now. As before, we will have a hard time finding qualified folks to step into this role, and it will likely also slow down the FIP acceptance and review process.

• I wonder if one solution is to break out FIP acceptance/governance processes from implementation and technical diligence more formally? So, FIP Editors and the typical review process remain unchanged, but FIP "acceptance" becomes conditional on technical finalization. After acceptance, an implementation is designed and tested, and key auditors have to sign off before the FIP can be scheduled for an upgrade. If a major issue is discovered, we can devise a governance workflow for making changes depending on the scope of the issue/required change.
• The above process would help us formalize and document review processes more concretely, and would require a few more eyes on things before considering it G2G. It also requires more time from those with specific expertise, as always, and would introduce more points of intercession before a FIP can land on-chain. Not problems, it's simply always about trade-offs. 🤷

[jennijuju]

Following months of research

could you please share the research that has been performed, so that we can consume them as an input to our 🤔?

[kaitlin-beegle]

Sure! If there is a part of this proposal, etc., that you'd like to more deeply understand, I'd be happy to provide the reasoning and references that informed that particular choice.

Also looking forward to sharing the high-level research outline and lessons learned during our presentation at the Filecoin Dev Summits!

[jsoares]

It's great to see this effort moving forward. I do have a question on

Scoped tooling MVPs to support community FIP0001v2 proposal

This can be interpreted in multiple ways. Given the guiding principles, does this mean we're looking to bring back some form of voting mechanism and run FIP0001v2 itself through it?

[kaitlin-beegle]

Great, great question. Scary question! But good one.

Yes, we are going to introduce on-chain voting for FIPs. I have long resisted this, but I have since been convinced that voting is likely the best way to balance the apparent community preference that we make decisions, relatively quickly, about big and complex problems.

However, it's also why we would like to implement a community guild structure, to act as an expert representative body that adds an additional layer of approval for our most complex proposals (economics, and governance).

But no, it is not our intent to launch these tools and have them be used to retroactively implement our changes. It's not a fair way of doing things. Our goal is to openly discuss and invite collaboration on the fine-tuning of this proposal, to open up an actual PR against FIP0001 (-3 weeks, after the Iceland Dev Summit), and to have it navigate soft consensus.

[kaitlin-beegle]

As mentioned above, I want to provide more detailed context about the changes we wish to make to the governance process.

First and foremost, most of the changes we'd like to see will need to come as a PR against FIP0001. This document provides foundational rules and workflows for FIPs, and has never been meaningfully updated. As a first step, we will propose:

• The introduction of 5 FIP categories, which meaningfully define the intent of the FIP and describe how it ought to be governed.
  • The five types of FIP include:
    • Network standards (FRCs), non-consensus proposals to document network best-practices and signal key recommendations.
    • Technical FIPs, for consensus -bound changes to the core protocol stack.
    • Cryptoeconomic FIPs, for FIPs that seek to affect economic policy on the network, or which will introduce changes that are likely to substantially affect existing token dynamics and/or network incentives.
    • Community FIPs, which introduce structural or programmatic policies to the Filecoin community, including changes to its governance process.
    • Security FIPs, for emergency technical changes to the core protocol in instances of attack, capture, outage, or other immediate and tangible threats.
  • The above list of FIPs is also ordered in order of increasing complexity and/or risk to the network.
  • FIPs of different complexities will have different pathways for reaching consensus.
    • Doing so will allow us to better align 1) the scope of the FIP and 2) the complexity of the change, with 3) the proper amount of community diligence and participation.
    • It will also allow us to set more appropriate thresholds for acceptance for different kinds of FIP. In other words, the current soft consensus threshold is too damn high!
• The introduction of on-chain voting for FIPs that require it and/or FIP Authors that want it.
  • We are working to spec an on-chain voting tool that allows community members to directly vote to accept/reject FIPs.
  • For simple Technical FIPs that don't receive much community engagement early on, FIP Authors will still have the option to achieve acceptance through soft consensus/last call.
  • For more complicated Technical FIPs, a vote will be optional, depending on community feedback and FIP Author preference.
  • For Cryptoeconomic and Community FIPs- which represent the high-risk, highest complexity changes made on the network- a vote will be mandatory.
• The creation of a guild of community working group representatives to operate as an expert governing body for complex FIPs.
  • In order to protect community interests and guard against vote capture on high-stakes proposals, a guild of community stakeholders will be asked to help make governing recommendations for FIPs.
  • The goal is to give the expertise and participation of working group members an opportunity to contribute meaningful decision-making in the FIP consensus process.
  • The creation of this Guild will replace the 'expert body' role that Core Devs have long been asked to play, opening up that role to a broader cross-section of Filecoin stakeholders and allowing Core Devs to function primarily as a technical advisory group (rather than a governing body).
  • Complex FIPs would be asked to reach complex consensus, a combination of Guild votes and community voting.
• The standardization of emerging norms and preferences, to help drive greater consistency around FIP management practices.
  • Aside from large, procedural pieces of documentation, there are many other things that we have long wanted to amend to include in FIP00001, including:
    • Updated FIP templates corresponding to FIP type.
    • Articulated standards for FIP review and audit.
    • Updated FIP workflows and visual process mappings.
    • Resource links to specs, doc sites, and other key repos that contain critical information for governance wayfinding.

In order to support the above, the Filecoin Foundation has committed to providing support by...

• Coordinating the design of on-chain voting tools, and providing financial support for their development, auditing, and long-term maintenance.
• Providing more targeted resources- both funding and staff- to support the establishment of new community working groups and subgroups.
• Providing resources and support to establish a Community Guild, a governance body that will give a representative voice to WGs on critical FIP topics.
• Developing GovDocs, a documentation site for governance workflows and resources.
• Building, deploying, and maintaining new tools to help inform community priorities on early-stage FIP drafts and complex proposed changes.
• Deploying an interactive UI that will enable community members to contribute the values that inform the Filecoin mission.
• Communications, marketing, and event support to help community members participate, contribute, and understand the role of governance supporting the vision of Filecoin.

The purpose of the above is to ensure the successful roll-out and long-term support of systemic changes that will make Filecoin governance more open, more responsive, and more decentralized in the long-term.

Openly coordinating governance changes at this scale is a difficult task, and we welcome any community members who are interested in supporting this work. To participate, please see above for the various in-person and async channels for sharing thoughts, getting connected, and staying up-to-date.

[jennijuju]

I would second @jsoares , many of the technical FIPs, may ha.ve an economics impact to one or more network participants, even if they are not directly proposing changes to network econ parameters. So clearer definition here might be needed.

similary, it is possible a security vulnerability might need to be resolved with CE changes, what process should we follow in this case?

[jennijuju]

I really like the idea of decoupling technical stewards and governance body, where i imagine the former is a subset of the governance body. I think the establishment/formation/expectation/guidelines of the Guild, might require its own discussion.

[kaitlin-beegle]

Good question, @anorth. We've long discussed "security FIPs", but this will be the first time we're really codifying a process for them. There are two key parts of that:

• Strictly specifying what a security FIP is and is not
• Structuring a process of retroactive governance that is still auditable and accountable.

Ideally, when someone flags an issue that they believe is a security FIP, the process would be:

1. A team assembles and drafts a FIP.
2. An expert body* is called to provide preliminary review of the proposed problem and solution, and to confirm that: 1) this is an active security issue, 2) the problem and solution are appropriately scoped and preliminarily sound, and 3) the risk vector for the vulnerability is understood.
3. A community Guild meeting is called, where representatives are asked to accept or reject the FIP.
4. (Presumably) an emergency upgrade is scheduled, and the change is implemented on-chain.
   • Depending on risk and potential vulnerabilities, the FIP could be published at various points in time.
   • For critical issues with clear risk vectors (i.e., in response to certain network attacks, etc.), the FIP and all supporting decision making materials may only be published after the emergency upgrade has landed.

There are lots of potential forks to the above process, depending on sensitivity. I also added a caveat (*) to "expert body" above, since it's unclear if Core Devs want this role. It appears that Core Devs want to move towards a more open, technical review structure, which does not lend itself to managing these issues. There may be a need for a subgroup, etc., to be set up specifically in order to handle these cases.

However, the intent is to have any final decision-making with the Guild, which exists explicitly to govern. The purpose here is to diffuse the responsibility to actually make decisions away from Core Devs, and to nestle it with a group that could be dissolved/restructured/etc., in the case of poor decision-making. It's also worth noting that the above process more or less reflects what we do in a more ad hoc way now, documenting it more clearly and demarcating exactly where and with whom decisions will be made.

[kaitlin-beegle]

@jsoares and @jennijuju, yep, totally here you. This is a hard line to draw, and is ultimately one that we would ask FIP Editors to make during their initial reviews.

The intent, however, is not merely to flag something as "cryptoeconomic" and put it in its own category. Rather, the intent is to ensure that the governance of a FIP is appropriately weighted to the overall complexity of the FIP itself.

So, should technical policies which may affect cryptoeconomic variables be considered a "cryptoeconomic" FIP? Likely no, if the intent of the policy is primarily technical. Cryptoeconomic effects should be modeled and disclosed as part of the FIP itself, but that's simply another thing that someone ought to consider when they're reviewing a FIP and deciding what they think about it.

However, FIPs which are written with the sole intent of changing existing economic policy, especially in regards to overall function of network economics rather than small adjustments to cryptoeconomic variables? This is a cryptoeconomic FIP, because it deserves broader scrutiny and a higher bar of consensus.

Ultimately, there will be black-and-white cases, and there will be many more grey cases. The intent is not to ask the question "is this cryptoeconomic?", but rather: "how extensive is this change, and who is it likely to affect?". The intent is ALSO to allow for a bit of ambiguity, and require that FIP Editors have these conversations and to publicly negotiate where these boundaries should fall.

[steven004]

I would like define the technical FIPs are those which require code change in core protocol and breaks consensus, which means a network upgrade is required. With this definition, we put the technical FIPs, cryptoeconomic FIPs and security ones as one group. The reason is that sometimes it is hard to put an FIP into one category.

We can still use the sub-category to define that, or simply use some tags to identify an FIP is cryptoeconomic or security related, and there could be more tags add in later. With those tags, an expert from a particular working group is required for review or join the designing.

[jennijuju]

@kaitlin-beegle

There are some common improvement feedback in this thread, how are we capturing potential AIs?

[kaitlin-beegle]

In what sense? AI -generated proposals? AI tools for reviewing or affecting FIP drafts? Etc?

[dcasem]

While i hear what you are saying and agreeing with most of it. However, generally i would also like to argue, an FIP without any or very low community engagement, core dev engagement and peer review across 3-6 weeks period (ideation, Draft, last call) implies network participants/stakeholders do not see the value of the FIP for the network, and i would further challenge the necessity of the FIP in that case for its to be accepted.

By your own words @kaitlin-beegle, this FIP should be abandoned. The proposal is overcomplicated and, in many ways, nonsensical -- hence the total lack of community engagement. I suggest that this is not FIP-able in its current form, and the team go back to the drawing board.

Meanwhile, the most engaged FIP Discussion in Filecoin's history remains in PR Review (Option 1x, Option FCM) for almost two months. The governance team (@kaitlin-beegle. @luckyparadise, @tinkmk) should figure out how to move that along given it's their actual job, especially with all the hoop-jumping the authors have put through to date.

While you've been talking about a voting tool, the community (without any FF support) has built one on the FVM, and pushes updates to the tool regularly.

Do you have anything to show for this multi-month initiative to transform governance?

[The-Wayvy]

This is like writing a patent for a new kind of fire extinguisher while your house is burning down.

There's nothing wrong with your thought experiment, but it is actually escapist when considered in context.

The Fil+ team regularly changes our consensus algorithm without even making a FIP.

The priority of any governance discussion must be removing the privileges of the Fil+ team.

It's irresponsible to spend on time philosophizing about the ideal system of governance while we have an obvious, pressing, and existential governance problem at Fil+.

Dealing with the actual problem, ex. 774, is unpleasant, but it gets community engagement because it actually matters to people.

[anorth]

A PR has been opened at #850

Please use this forum topic for discussion about the big pieces, voicing substantive disagreements etc. Leave the PR review for smaller wording suggestions or comments.

[LukeHolon]

I may have missed this in the thread - so apologies in advance - but I'm keen to understand the metrics (beyond majority or super majority consensus) and mechanism (i.e., protocols, weightings, etc) of the caucusing/gathering support and voting systems, and the thought behind it. Of particular importance is whether there is the ability for "identify verification" of contributors/voters, and that those contributors/voters' "names/businesses represented" are made publicly transparent?

[anorth]

I don't believe this has been specified yet, and a couple of comments in #850 (@jsoares) have pointed out that this spec is a pre-requisite to meaningful community evaluation of this proposal. @kaitlin-beegle will this specification be added to the PR soon?

I did see some brief references to constituencies etc in a recorded talk from Fil Dev Summit, but they were so brief that I won't link it here, because I don't want to spark debate and disagreement about something that might not represent the actual proposal.

[anorth]

@kaitlin-beegle the voting mechanics still appear to be unspecified. I see that a comment below from a non-author has linked to a Google Doc, but I don't know the status of that document, whether it is in fact the proposal etc. I'm sure I will have something to say about it if it is. In my opinion the period of community review for this proposal hasn't started yet, until the voting specification is in the PR. "This PR has been open for three weeks" isn't going to cut it as community review if the critical content isn't all there.

[anorth]

Core devs 🧵

#850 refers to the Core Devs group in a few places, but does not define it. Even though this proposal reduces the obligations and responsibilities of this group (👍 ), important ones still remain and I think the group needs at least a passing definition. It's not clear to me whether Core Devs is to be identified with "Developers" as a Guild community group, but if so then the proposal requires them to "maintain an open membership policy", which is a change from today (depending what open means).

In the draft as it is, Core Devs power/responsibility include:

• Strike down unsound/impossible/unreasonable FIPs prior to their being published
• Decide whether soft consensus has been reached (but this could go to Guild instead?)
• Decide whether a proposal represents a security FIP, and at what level, and for level 2+ unilaterally decide and implement a change

I think FIP0001 should define the group, if it refers to it. We can probably take something fairly informal like "group of contributors experts who regularly make technical contributions to Filecoin network node implementations, core components thereof (including the VM, built-in actors, proofs, and other Filecoin-specific dependencies), protocol definitions and specifications, cryptographic design and analysis, or crypto-economic design and analysis (edit: or governance)."

If an open membership policy can mean one where the group needn't accept any random applicant, but should accept membership from anyone who can demonstrate such regular contributions, then I think "open" will be fine and not an unreasonable risk given the group's powers.

[q9f]

Relevant discussion:

• Review: 'Core Dev' Purpose and Structure core-devs#121 (comment)

[LukeHolon]

Thanks @anorth, appreciate it. #850 raises some good points and agree that this spec fundamentally underpins good governance. Be good to explore further.

[The-Wayvy]

@kaitlin-beegle @momack2

I oppose giving 'clients' 20% of the vote since they are mostly self-dealing miners and DC dealers.

We shouldn't reward gamers with extra votes.

I suggest increasing their weighting from 0% to 20% over 4 years.

voting specification

[kaitlin-beegle]

The current breakdown is just an even, across-the-board breakdown that gives all major Filecoin ecosystem roles an even vote weight. The intention is for these vote weights or groups to be changed as necessary over time. However, we can't do that with no data about who is voting, how, and on what.

[The-Wayvy]

@kaitlin-beegle

Voting

I propose summing the weighted percentages, rather than having each constituency vote as a block.

If each stakeholder group votes as a block, we could see a FIP rejected despite having 70% of voters in favor.

ex. Voters In Favor of FIP XXXX:

100% RBP
100% Token Holders
49.99% Deal Bytes
49.99% Core Devs
49.99% EcoSystem Partners

You'd have ~70% of voting power in favor, but the FIP would be rejected 3-2.

[kaitlin-beegle]

I think there is a misunderstanding- we ARE summing across the constituencies. They are not counted according to a bloc.

[willscott]

I'd like more clarity on intentions around which entities form the guild, and I am somewhat uncomfortable with the foundation as a centralized entity deciding guild composition without other balances.

• could positions with clear membership (token holders, SPs) - hold their position as guild representative directly through staking?
  • clients could maybe also be elected through an on-chain process weighted by how wallet amounts that have paid for storage?
• could developers be 'seated' as core devs directly? is there another entity we would imagine here?

That would only leave 'ecosystem partners', 'pl', and 'foundation' itself in softer seats.

In particular I think there needs to be some process we can imagine whereby if the foundation abdicates it's duties there's a way for the guild to evolve it's composition / elect a new chair. This proposals says the foundation cannot be removed by vote but rather by amending fip1, but it will be the council that decides on such a fip, and so it is still a council vote at that point, right?

[kaitlin-beegle]

Hey @willscott! We finally have more info on how the guild is likely to form given the current proposal, and I'd love to help answer these questions.

The primary intended balance here is that the Foundation can appoint groups for representation, but that a community vote can REMOVE this group and reinstate a new one without the Guild's consent.

• could positions with clear membership (token holders, SPs) - hold their position as guild representative directly through staking?

Practically speaking, yes, we could do this. Operationally, it will be very difficult. It has been extraordinarily difficult to organize resources just for building an on-chain voting tool, and to add additional technical deliverables at this point would add an additional delay in the finalization of this proposal.

Separately, I have quite a few questions about how you envision staking working in this way. To take SPs, for example: is the idea that SPs could stake their own tokens and/or delegate tokens to other representatives, and those with the most get to represent all SPs?

• clients could maybe also be elected through an on-chain process weighted by how wallet amounts that have paid for storage?

Sure- not a bad suggestion at all. However, at this point in time, it feels out of scope for the original proposal. I think the one thing to emphasize here is that a critical Guild function is serving as a coordinating entity between the humans that work and contribute to this ecosystem. Weighting, staking, and delegating (as well as randomization sequences, etc.,) may be useful technical solutions for streamlining and making this process more decentralized in the future. However, the Guild is supposed to serve as a human check on the technicalities of on-chain voting, empowering actual community contributors with an ability to affect outcomes regardless of actual on-chain transactions. It's a check on the worst habits of voting systems, and we'll need to be thoughtful about the design of additional technical processes to support what (I believe) should be a human -centered function.

And lastly, yes- if the Foundation goes away or does not function well in its seat, there should be rules for how the Guild can reconstitute itself. Noted.

[willscott]

It has been extraordinarily difficult to organize resources just for building an on-chain voting tool

This doesn't seem like a huge amount of work compared to the other things that are and have been built in the ecosystem. I want to push back that just because our governance process doesn't have an effective way to build technical artifacts today shouldn't make us shy away from technical processes if they're more in line with what we want than subjective human-in-the-loop approximations.

Staking as a mechanism for delegation of votes / liquid democracy is being used in several crypto projects today, including the optimism 'token house' https://community.optimism.io/docs/governance/ or Uniswap https://docs.uniswap.org/concepts/governance/process

I think there is a tension we should be navigating between the faults present in a technical 'vote' leading to majority-takes-all, and the human process described here where a small number of participants attempt to represent the community. The current structure has real potential for a guild representative to not represent the pulse of their broad constituency, and for governance to diverge from the broader network interests. We describe a multi-stakeholder process that weights the interests of different constituencies equally as the basis for what is considered the will of "the network", but the governance process described here has potential for deviation from that description. We could encourage constituencies to build/use the tooling I've described to make it more clear to their guild representative what constituency opinion they should be representing.

I think the underlying structural choice I'm pushing back on is why an identified, clearly defined group like 'clients' or 'sps' is not empowered to choose it's own representation.

[Fatman13]

I'd suggest the process also adopt a mechanism similar to ostracism in ancient Greece where overpowered individuals can be voted out by network stakeholders so that they are no longer involved with FIP decision making.

Ostracism was a democratic procedure that allowed citizens to vote on whether a prominent individual should be banished from the city for a period of ten years. This process was not necessarily aimed at charismatic individuals alone, but rather at any person who was seen as accumulating too much power or influence and potentially endangering the democratic system.

The term "ostracism" is derived from the Greek word "ostrakon," which means pottery shard. Citizens would write the name of the person they wanted to be ostracized on a piece of broken pottery, and if a certain number of votes were cast against a particular individual, that person would be ostracized.

Ostracism was a political tool, and the reasons for its implementation could vary. It was more about preventing the rise of a potential tyrant or autocrat rather than targeting charismatic individuals specifically. The process was used in the 5th and 4th centuries BCE and involved notable figures like Themistocles and Cimon.

[kaitlin-beegle]

This is an interesting idea, @Fatman13. Do you have any additional ideas about how it would work?

I oppose the idea that community members could pick or choose a person or account to exclude. One thing we could consider, however, is a threshold for power in each voting constituency. So, if you have more than n amount of whatever the vote weight criteria is, it doesn't lend you any additional weight. There are some nice mathematical models that other projects have implemented to curb the effect of "whales".

Once we start voting and start gathering data on who is voting in each category and why, there might be a really compelling case to make for this change.

[Fatman13]

I'd like to also point out the fact that right now the FIP process designers, fip-editors and core-dev are of the same group of people, which is obviously a case of conflict of interest where they are both the players and referees. It is very apparent to me that one should be either an FIP governance facilitator OR an editor / core dev, but one can't be both.

More importantly, lacking engagement of actual network stakeholder to the discussion would also contribute to unchecked power. Team should go back to drawing board like what is suggested here and garner more network stakeholder inputs.

[kaitlin-beegle]

This...isn't true. There is overlap between FIP Editors and Core Devs, almost by definition.

Those group of people have no particular or exceptional role in this process. This proposal came from me- the "FIP governance facilitator" - and the Filecoin Foundation. We wrote this proposal and are investing the resources to build and test this system, just like anyone else can do.

Also, re: engagement, many FIPs have historically pass with almost zero engagement. This proposal, on the other hand, has received hundreds of comments, is discussed at a standing monthly meeting that is solely dedicated to discussing the proposal itself, attendance at that meeting continues to tick up, and dozens and dozens of contributors continue to actively contribute to this work. Engagement isn't a real litmus test for passing a FIP and, if it were, I believe this one would pass.

[jsoares]

I have expressed this before in a live session, but I have a strong objection to the decision matrix as expressed here:

In my view, the asymmetry introduced in cells (4,1) and (1,4) is both unjustified and impractical: the guild should not be able to force a decision against which there is community consensus (>75% reject), but also can't realistically do that. If we ever find ourselves in that situation in practice, I really don't see a way forward that isn't "abort everything and go back to the drawing board".

Now, I know the argument goes that if the guild represents community stakeholders, something like this is both exceedingly unlikely and indicative of a bigger problem. I agree, but that too is symmetrical. That's why we should apply the precautionary principle and reject any proposal that is that polarising, regardless of whether it is case (4,1) or (1,4).

[f8-ptrk]

we have to talk about it - sooner or later:

the fact that miners are able to override any decision the process outlined here outputs needs to be addressed.

[f8-ptrk]

i keep this vague on purpose as i am interested in what others think.

if miners decide to simply not implement an accepted FIP - whats gonna happen? (for example)

[jsoares]

I think this is a key question and one that's underexplored. All stakeholder groups are special, but some are more special than others. And this really is a very concrete scenario to explore:

• FIP-1337 gets accepted with strong opposition from the SP vote (or even from the entire community, overruled by the guild)
• FIP-1337 gets slated for inclusion in nv33, alongside other important/critical FIPs
• We're one week away from nv33, and there are no signals that a majority of SPs will adopt the upgrade

What happens then? Do we cancel nv33? Do we retract FIP-1337? Or do we move forward and fork away from the network. I'm not advocating a particular outcome here, and the realistic answer is likely "it depends", but it's something best considered before we find ourselves in that position -- or, ideally, by defining governance so as to minimise the probability of that scenario.

[f8-ptrk]

imagine miners decide to run both networks and hand the decision about what we call FIL now to the exchanges.

[anorth]

if miners decide to simply not implement an accepted FIP - whats gonna happen?

I don't think it's as obvious as it sounds on the surface. Ethereum 2 presented a great case study. The change away from POW was terrible for all the mining businesses invested in POW hardware and operations (i.e. all miners). But they couldn't prevent the change because what really matters is what the broader world thinks of as Ethereum (or the ETH token). The mindshare was that the real Ethereum is the new POS one, so miners that refused to move ended up mining on a much smaller and less valuable fork of the chain.

Every situation would be different, but Filecoin can likely survive a change that's bad for many SPs if it's "good for the network" and the world perceives it that way. The social consensus is the ultimate arbiter (and yes, exchanges represent that for many people, though they will try to take on both sides).

I don't think this is something that can really be addressed here. You can imagine a governance process fork rather like a protocol fork (and one would eventually create the other). This FIP just has to assume that this is how things are going to work. Something external to the processes defined here could always change it in theory.

(Note I think exactly the same applies to the guild override @jsoares critisizes above. Which way would the community and world go? Probably not with the 7 guild reps if everyone else is against them. So their override is pointless).

[f8-ptrk]

i agree that all this is way more complex than just 50+1 miners going to run a new forked network. nonetheless i also think that the fact that miners provide 100% of the storage on the network (until the day consensus and storage are decoupled) and, by current design, lock 30%'ish of circulating supply isn't represented in the current design of this FIP.

(this obviously goes further - what miners provide to the network goes far beyond what all the other individual groups represented in this FIP provide)

[Fatman13]

The guild design completely violates filecoin mission...

• The network is not dependent on any one party, e.g., not dependent on a company, foundation, or other organization to continue operating.
• No centralized parties can control, stop, or censor the network, its operation, or its participants.

How can a guild of 7 people overrule the vote result of network stakeholders?

[deltazxm]

Make everything simple.Just Token Holders vote.No other roles required

[f8-ptrk]

thats not gonna work. miners can overrule a vote at will - no other groups required in the end.

[jsoares]

Somewhat belated comment on FRCs: so far, out practice has been to leave them at Draft stage and not go through the governance project. This is different from Ethereum practice, where ERCs have the same status and pipeline as EIPs. Moving towards this would likely help with concerns raised re lack of engagement with FRC governance.