Update fip-0001.md

[kaitlin-beegle]

Replaced existing FIP0001 text with FIP0001v2 text.

Introduces all policies introduced in #799, which have been presented, deliberated, and discussed over the past several months via Community Governance Calls, community public forums, at working group meetings, and in-person at various Fil and other events.

Next week during regular working hours, I'll flesh out some additional questions for community consideration, and will open (and link) to PRs against the FIP spec that I think will provide some additional clarifying details.

[momack2]

YES! so glad to have this FIP follow our FIP template!

[momack2]

can probably link to original commit already?

[momack2]

Suggested change

	Different kinds of FIPs have different requirements for consensus, depending on the scope and complexity of those changes. In general, more complex FIPs must meet a higher bar of review and approval in order to achieve acceptance.
	Different kinds of FIPs have different requirements for consensus, depending on the scope and complexity of those changes. In general, more complex or revolutionary FIPs must meet a higher bar of review and approval in order to achieve acceptance.

[kaitlin-beegle]

The standard for including descriptive language in FIP0001 should be illusory. We should only include unspecified, descriptive terms (such as "complex") when they help explain the intent of the stated policy. This is important, as these words tend to become contentious when we encounter new use or edge cases.

"Revolutionary" is a strong word. Can you please explain how adding this word better specifies policy? If there is disagreement in the future about the status of a FIP, how should FIP Editors interpret this word?

[momack2]

Thank you for adding these post discussion at FIL Dev Summit!

[kaitlin-beegle]

Yes! @momack2 we did not dig too deeply into specifics of Security FIP subtypes, so these are definitions that I am putting forth. They were the last part of this document to be added, and are the only part that hasn't been publicly vetted prior to this FIP being opened.

Just flagging, so that you and others can be sure that these definitions map to your experiences/expectations.

[willscott]

It would be great to have a forum by which the community can attempt to reach a higher level of agreement / consensus on aspects of filecoin that are not directly consensus related.

The 'technical fip' secton limits itself to changes that affect interoperability of implementations - which I read as the specific networking protocols and block consensus processes. Things like markets interfaces have been left to FRC level. While some systems like fil+ have had some success in promoting a level of standardization in interfaces, we have a much less developed working group around these interfaces than in the IPFS community (with IPIPs), or in e.g. multicodecs with agreed upon governance for standardizing protocol names.

[kaitlin-beegle]

I think what you're pointing to is the need for greater review, scrutiny, and engagement on FRCs, correct?

When we first started accepting FRCs, the ideal workflow was:

• An FRC is opened as a PR against the FIP repo
• It is reviewed by FIP Editors
• It is merged as a 'Draft' once complete
• It remains as a 'Draft' until Core Devs push for it to be determined 'Final', or else the FRC Author/other community members are able to demonstrate widescale adoption of the standard, etc.

In practice (maybe a structural problem, maybe an issue of time), no one could or wanted to advocate for the adoption of FRCs. They sat as drafts, and this was often confusing to community members.

• The change here is that the threshold for "acceptance" is much lower, which I believe is what you're raising concern about.

Do you have any ideas or preferences about how we could reconfigure this (or another) FIP definition to better account for the use cases you're thinking about?

[willscott]

are these votes made public? what about for security FIPs? we should be up-front with when exceptions can be made and for how long embargos can be implemented

[jsoares]

+1 we should commit to a public record in the FIP text

[kaitlin-beegle]

^ +1 as well.

My preference:

• Any decision from the Guild must be documented and made public.
  • This includes decisions made about security FIPs, which may be made public at a later date (with an impetus to make it available ASAP).
• Any dissenting opinions, or else the voting rationale from individual representatives, should be made just as accessible.
• Agree about consensus decisions in the FIP text. I think we should update the template to include a note on consensus decisions, so that all outcomes are referenced and recorded in the FIP itself.

For security FIPs, the proposed policy effectively defers to Core Devs to make a decision about what is most appropriate, and to then be held accountable to that decision. Do you feel like this is adequate? If not, how do you think we ought to more clearly specify time limits/etc., on security FIP decisions?

[jsoares]

I don't see an issue with the security FIP progress and discretion given to core devs; it's hard to fully specify what will be somewhat ad hoc based on the circumstances. But it's a weakly held opinion.

[willscott]

this is a bit confusing.

• it's a >66% of the 7 guild members that would vote out a member?
• in voting out a member, the foundation would immediately need to appoint a replacement within the same stakeholder group before guild activities could continue?

[anorth]

I'm also confused here. It is unclear above whether FF is appointing a specific person from a group, or just the group, who can nominate their own representative. I don't know what "composition of a Guild seat" means.

[jsoares]

Per live discussion, my understanding is that they are appointing groups and not people. That should be made clear in the text.

[LukeHolon]

I'm keen to understand the metrics (for example, why is supermajority consensus 66%? Most governance models use 75%) and mechanism (i.e., what are the specific voting protocols, including vote weightings, etc?) of the caucusing/gathering support and voting systems. Critical to voting systems and good governance is the ability for "identify verification" (KYC) of contributors/voters, and that those contributors/voters' identities ("names and businesses represented") are made publicly available for audit purposes. Identity verification would also significantly reduce noise and bad actor participation and reaffirm that a genuine and mature, open-source, democratic process, such as the Filecoin Network, requires a commensurate degree of genuine and mature transparency for human participation.

[kaitlin-beegle]

Good flags- I'll update the text to be a bit clearer.

There is a difference between what role the seat is intended to fill (which is specified in the FIP), the group that is selected to fill that seat (as appointed by FF, but open to community veto), and the actual person(s) that show up to Guild meetings (selected/managed by the community group).

The intent here is that a 66% community vote could a group that has been selected by FF to fill a seat; this is the veto mentioned above. If a group were voted out, FF would need to choose a different community group to better represent this function.

• Reasonably, we may also need to specify that any proposed veto of a representative group ALSO needs to name a new group to replace them. This is a bit complicated, which is why I originally omitted it.
• A community veto should/would be a rare thing, in part because active participants and working groups in the Filecoin ecosystem remain small. The intent of this detailed rulemaking is to prevent against future abuse.
  • A reasonable hypothetical for knowing when these rules/requirements may be important is to consider a schism or "fork" of the SP Working Group. If there are two working groups that each claim to represent SP interests, and which refuse to work together, which group legitimately gets to join the Guild?

[kaitlin-beegle]

@LukeHolon 66% is an arbitrary figure! Generally speaking, 66% is considered a statistical "supermajority". The draft spec we have for voting breaks out different community functions with different ways of determining vote power, which reinforces the idea of 66% as a high threshold (I can explain this further if you'd like, but will omit it here for brevity).

A 75% acceptance threshold is more common in blockchain voting structures because:

1. when your vote power is solely a function of your token holdings, your voters are much more likely to operate as a single block, and;
2. there are often few total participants (compared to overall network size). A small pool of contributors means less diversity of opinion, and thus 75% agreement is achievable and appropriate.

It could be with time that 75% is more appropriate than 66% and we need to make that change. Or, if you have a strong argument now as to why we should choose one threshold over another, I'm happy to make the change.

And yes- voting will be anonymous-ish (with votes associated with Filecoin wallets), but Guild votes will not. Representatives will need to represent their groups, and justify their votes/preferences. The Guild exists to provide many checks and balances on voting, and this is one of them. Does that address your concern?

[LukeHolon]

Thanks @kaitlin-beegle. I think its fine to start at 66% and assess effectiveness down the track. Good that Guild votes are not anonymous and open to public scrutiny. Any way to shift/tag/link filecoin wallets to specific identified voters (ie., real people representing their organisation), or is this something being worked on for the future?

[willscott]

That a single foundation guild seat becomes the central decider of who can be on the guild seems like an increase in centralization.

at minimum - it would make sense to define the founding guild members as part of this FIP, rather than delegating that power unilaterally to the foundation.

[kaitlin-beegle]

The Foundation makes decision to coordinate Guild work and function, though there is still a community veto upon the Foundation's ability to make appointments.

I can see this appearing as "centralization" in the sense that one seat has disproportionate power in certain regards, but these rules were written with an intent to check that power. In addition, the role that the Foundation has been given doesn't necessarily affect operations of the Guild; if the Foundation were to disappear, the Guild could still form.

If we remove the Foundation as the seat of the Guild, how should we fund this body, appoint members, and make rules for it? My expectation is that, with time, the role that the Guild is play will change dramatically in operation, and many parts of this functionality could be automated and/or brought on chain. In this initial phase, however, I don't think this scoped role for FF is inappropriate.

[willscott]

• if we define what a community veto looks like for appointments, that would be a reasonable limitation on power.
• how would the guild form without any entity to appoint missing stakeholders? is there a path to legitimacy here if the foundation abstains to name a representative that the rest of the community / some factions of stakeholders favor?
  • I think my main concern in this structure is to make sure that misalignment doesn't potentially lead to deadlocks

[kaitlin-beegle]

Hey @willscott, good points. As background, I spent much of the last two weeks meeting with counsel to review this structure and ensure that is both appropriately scoped and decentralized. The (short) summary of those (long) conversations is:

• If community members can replace a group via a vote, and the Foundation cannot interfere in this vote, this is a reasonable check on the Foundation's authority.
• The explicit assumption is that the Foundation is obligated to name these representatives.
  • There is still an open question about which governing rules need to be specified upfront, and which can exist as norms of behavior. Right now, it's my opinion that any further specification about rules for the Guild should be added to the spec, not to FIP0001v2.
  • The path to legitimacy for an unpopular representative is removal by vote. There are also rules (in the FIP0001v2 draft under "FIP Consensus Mechanisms") about what a group needs to do to be legitimate enough to be named. At this point in the Filecoin community's maturation, there are few (if any) instances where multiple groups are mature enough to claim to legitimately represent a single community faction. For most of these chairs, there is presently but one option.

[willscott]

That highest security level issues are approved before the core devs see the fip and can comment on practicality / path seems to introduce the potential for misalignment and creating worse outcomes.

since implementation will need to happen by the core devs, it seems unclear that having fip decision happen before the issue is shared with core devs dos not save much in this case, but rather opens up additional surface area of another set of, in this case less technical stakeholders that also need to reach understanding and resolution on the security issue.

[jsoares]

My interpretation of lines 165-168 is that core devs are involved all along, and are probably the ones writing the FIP for approval by the community guild. The wording is ambiguous, though, so here's a suggestion:

Suggested change

1. For **Level 1 security threats**, a FIP should be written for review and approval by the Filecoin Community Guild. Guild members will be asked to accept or reject the FIP; they may not abstain. They must also supply documentation explaining the resulting outcome. If the FIP is approved, Core Devs are responsible for determining whether or not an emergency network upgrade is needed, and when the accepted FIP can be publicly disclosed (with a bias towards ASAP).

1. For **Level 1 security threats**, Core Devs should coordinate and propose a FIP for approval by the Filecoin Community Guild. Guild members will be asked to accept or reject the FIP; they may not abstain. They must also supply documentation explaining the resulting outcome. If the FIP is approved, Core Devs are responsible for determining whether or not an emergency network upgrade is needed, and when the accepted FIP can be publicly disclosed (with a bias towards ASAP).

In any case, entirely agree with @willscott that core devs cannot come in after the guild, if that's what's being suggested.

[willscott]

For security FIPs, i would like to understand what expectations around confidentiality are put on:

1. the appointed guild-member groups
2. the representatives from the guild-member groups that show up to a guild meeting.

how large of a circulation are potentially security issues going to see before mitigation? how much risk is that taking on, and what expectations for data protection / siloing are we able to put in place here?

With core devs there's a specific list of humans who are expected to not reveal security issues past that group until after an embargo. With this structure the limits for information sharing seem more risky / less clear.

[kaitlin-beegle]

Hey folks! Making another round of updates and want to close the loop here.

@jsoares is correct - during emergency situations, it is Filecoin Core Devs who should take the lead. Only during minor, future -looking changes should the Guild have any particular ability to block a proposed change, and this is intended merely as a check on a Core Dev body trying to circumvent the governance process. Language was previously added to make this clear.

@willscott, it is my expectation that the terms of confidentiality are managed situationally. This is how it is done today. I believe a fair expectation for the Guild is that they may not disclose discussions, decisions, etc., until materials are public, and we will need to develop intraorganizational trust in order for this to work. There is no rulemaking that will ensure confidentiality.

• The current structure is designed such that security issues are handled quickly and by technical experts, with the Guild primarily playing the role of oversight and documentation post facto.
• The bigger issues/priority should be Core Devs deciding the order of command for security issues. This has always been a bit of a black box, and I would love the group to work towards more clearly codified expectations.
  • Currently, there seems to be interest in opening this group up to more people, which is fine by me. However, it may then require there to be a sub-committee with particular maintainer credentials, etc., for handling security issues.

[anorth]

This is a lie today, and I don't think there is any serious appetite from those responsible and/or capable to actually implement. I suggest we drop this paragraph.

[jsoares]

Suggested change

However, we also require that, where appropriate, Technical FIPs are also reflected in the protocol's specification, which is the primary source of reference for other developers. The [Filecoin Spec site](https://spec.filecoin.io/) will in turn point back to the FIPs that have changed some part of the protocol, as well as the FIP's revision history.

Strong +1. Lack of maintenance of the spec is a much bigger problem but, since we can't seem to get around to fix it, let's at least fix the documentation accordingly.

[kaitlin-beegle]

Addressed.

[anorth]

"should otherwise be deprioritized"

This is huge wiggle room and I think should be tightened a lot, or just dropped. We want something like "are otherwise completely ridiculous", but where that qualifier can't be used to reject any change to anything specified in this FIP. E.g. a FIP to change the Filecoin mission can't be rejected out of hand by core devs if most of the community want it (i.e. it could subsequently pass the necessary processes)

[jsoares]

+1 to limiting rejection power at this stage.

Moreover, I'm unsure on the usage of Core Devs vs. FIP Editors in this paragraph. Moving from WIP to draft requires review and approval from FIP Editors, not Core Devs (both in theory, i.e. codeowners, and in practice, i.e. people who actually engage and have reviewed previous PRs, except for a handful of very controversial ones). It is FIP Editors, too, who should refuse to merge things that are absurd or malformed (but only those).

[kaitlin-beegle]

Firstly, I see @anorth's point, though I'm not sure the language change from "otherwise deprioritized" to "completely ridiculous" leads to a substantive difference in practice. I think the correct balance, perhaps, is with language for WIPs that are "fundamentally underspecified"? Or perhaps "irrelevant to the protocol"?

Ultimately, executing authority here would come down to Core Devs having the collective will to do so, and it's hard to see that happening (at least, with our current balance of participants, which includes both of us). However, I think the two language suggestions above are a bit more reasonable to justify, and thus may work better to limit an abuse of authority.

Let me know if you have further thoughts and/or a preference.

[kaitlin-beegle]

Secondly, @jsoares, not sure I agree. Right now, we require that all proposed FIPs get preliminary proposed to Core Devs. I think it is a reasonable standard to maintain. I know there has been a push lately for FIP Editors to do more of a cursory/quicker sign-off on things, and to move FIPs more quickly into official draft status, but I'm not sure that actually benefits the process overall. This is a low bar for oversight that I think we should keep consistent.

[anorth]

Suggested change

	* **Superseded** -- A FIP which was previously final but is no longer considered state-of-the-art. Another FIP will be in Final status and reference the Superseded FIP.
	* **Superseded** -- A FIP which was previously accepted or final but is no longer considered state-of-the-art. Another FIP will be in Accepted or Final status and reference the Superseded FIP.

[anorth]

Please insert a hash of the specification text so that there is no ambiguity about which version this FIP is enshrining. Or will that document be added here in this PR as a resource or another document hosted in the FIPs repository?

[jsoares]

This is a blocker for the FIP to be properly discussed (let alone accepted). The content of that specification should be brought into the corresponding FIP discussion thread.

[kaitlin-beegle]

I am happy to codify a single document for the voting tool, which can be included as an auxiliary file to this FIP.

The current spec is a dynamic document, the details of which are still being developed. It is also the case that, through testing and initial roll-out, elements of the detailed spec will need to change in order to support the functionality of the tool; however, the key intent of tool design should be unchangeable.

Just as we want an updated version of FIP0001 to only enshrine high-order processes and structures, so too should the auxiliary voting spec structure the design intent of the voting tool without impeding changes to functional details. This can of course be a grey area at times, but I trust that with collaboration and codification we can chart a clear course through it.

Writing this document has been added to the top of my to-do list 👍 I'll flag it when available.

[willscott]

I think it is still true that, especially since we say "the specification can only be changed via FIP", we need to know what we are voting on - to vote on a spec doc that is in limbo means we aren't able to justify any of the specific points in flux as having come through the FIP consensus process. We get more legitimacy by having a fixed spec doc linked here.

[anorth]

Please enumerate the stakeholder groups here rather than link to a resource which could go away.

[anorth]

Please upload the resource here, don't host it on HackMD. Or even better, make a table in text here.

[jsoares]

I'm already getting "forbidden" on the link so can't even assess content

[anorth]

Hybrid Consensus is an opaque term, and the remainder of this document doesn't use it at all. Instead, it tends to say "Community Guild approval" or similar. I suggest removing the jargon-like term and just calling this what it is.

[anorth]

Suggested change

	**Consensus for cryptoeconomic and governance FIPs is determined by both community vote and Community Guild approval.**
	**Consensus for cryptoeconomic and governance FIPs is determined by both hard consensus *AND* Community Guild approval.**

[LaurenSpiegel]

So, in order to remove the Guild in the future by amending this FIP you would need the Guild to agree?

[anorth]

they may not abstain

The Guild process already described that abstain -> majority vote. Why does this need to be a special case? There are good reasons for community guild members to abstain from voting on something technical that they don't understand. I suggest either they always can abstain, or always can't.

[jsoares]

"may not abstain" is impossible to enforce. Guild members always have the option of not responding, especially on tight security deadlines.

We could have it as a rule that abstention would lead to replacement but that's a matter of guild management and shouldn't be a part of the security FIP process description. It's also probably a bad rule for the reasons @anorth explained.

[anorth]

While probably fine, this is another FF-controlled single point of power. An alternative is to define the group to self-manage, like a guild member group, FF to step in only if the group disappears.

[jsoares]

I have mixed feelings about the approach of replacing FIP-0001 in place and still referring to it in the text. That seems more suitable for a new superseding FIP (see @willscott's comment). If we were to replace instead of supersede, then I'd prefer to cleanly present the current status instead of referring to its history.

[jsoares]

Will governance processes go on the Filecoin spec? That seems wrong.

[LaurenSpiegel]

Why are these different from FRC's?

[jsoares]

Suggested change

However, we also require that, where appropriate, Technical FIPs are also reflected in the protocol's specification, which is the primary source of reference for other developers. The [Filecoin Spec site](https://spec.filecoin.io/) will in turn point back to the FIPs that have changed some part of the protocol, as well as the FIP's revision history.

Strong +1. Lack of maintenance of the spec is a much bigger problem but, since we can't seem to get around to fix it, let's at least fix the documentation accordingly.

[jsoares]

Suggested change

2. A **Cryptoeconomic FIP** primarily seeks to affect economic policy on the network. Though most technical changes could affect network economic elements- including gas fees, token utilization, or other metrics- these secondary effects are not enough for the FIP to be considered cryptoeconomic in nature. Cryptoeconomic FIPs fundamentally change the economic logic of the Filecoin ecosystem, and are thus suspect to heightened scrutiny and consensus requirements.

2. A **Cryptoeconomic FIP** primarily seeks to affect economic policy on the network. Though most technical changes could affect network economic elements- including gas fees, token utilization, or other metrics- these secondary effects are not enough for the FIP to be considered cryptoeconomic in nature. Cryptoeconomic FIPs fundamentally change the economic logic of the Filecoin ecosystem, and are thus subject to heightened scrutiny and consensus requirements.

[jsoares]

+1 to limiting rejection power at this stage.

Moreover, I'm unsure on the usage of Core Devs vs. FIP Editors in this paragraph. Moving from WIP to draft requires review and approval from FIP Editors, not Core Devs (both in theory, i.e. codeowners, and in practice, i.e. people who actually engage and have reviewed previous PRs, except for a handful of very controversial ones). It is FIP Editors, too, who should refuse to merge things that are absurd or malformed (but only those).

[jsoares]

Suggested change

	A bad reason to transfer ownership is because you don't agree with the direction of the FIP. We try to build consensus around a FIP, but if that's not possible, you can always submit a competing FIP.

This is in direct conflict with the paragraph below. If an author no longer agrees with the direction a FIP is taking, they should withdraw as authors and someone else should take over.

[jsoares]

Suggested change

	- Check the FIP for language (spelling, grammar, sentence structure, etc.), markup (GitHub flavored Markdown), code style
	- Check the FIP for language (spelling, grammar, sentence structure, etc.), markup (GitHub flavored Markdown), code style.

[jsoares]

Suggested change

- Check whether the FIP needs to be accompanied by an update to the specification and if so, make sure that a PR to spec repository has been submitted and that the text that updates the spec is reflecting the changes that the FIP proposes.

Same reason

[jsoares]

Why is this relevant?

[jsoares]

Suggested change

	`spec-sections:` A list of spec sections that the FIP is updating.
	`spec-pr:` The URL for the PR updating the Spec.

Unused, same argument as above

[anorth]

I, too, am very glad to have this FIP following our FIP template. However the current draft does not finish the job. It's missing a few key sections that are important to participants understanding the impacts of a proposal. While they usually apply to the technical/protocol impacts, I think it's just as important for a governance/community FIP to address the governance impacts.

Incentive considerations

• What are the behaviours incentivised for individuals or groups to gain and hold governance power? Details here probably depend on not-yet-specified voting constituencies.
• What are incentives re guild groups or members thereof?
• What behaviours are incentivised for FF to retain its power/influence?

Security considerations

• What are the weakest points of governance, and how strong are they? To (a) non-participation/incompetence, and (b) motivated/resourced attack?
• What are the minimum groups of people that can (a) block change, (b) force change of various types? Who is trusted for what?
• Perhaps a note about the limitations of this FIP? I.e. it can define a notion of legitimacy, but can't actually constrain real world action. Power centres remain, such as token holders/exchanges defining what Filecoin "is" in the event of fork, developers to actually implement any technical change, or SPs to decide what protocol to actually execute with their hardware.

We all accept that governance can't be perfect, the mechanisms will be a compromise. This will certainly be an improvement over status quo. But just as with technical systems, understanding the limits and weaknesses (which must exist) is part of gaining confidence that it's "good enough".

[anorth]

The FIP template includes incentive considerations, and product considerations. They should be included here too.

Alternatively, to de-duplicate I think it would be fine to remove all the text here and instead link to the template (and include a note in the template that it's governed by FIP0001 so we don't accidentally make substantive changes).

[rvagg]

Suggested change

	Generally speaking, they are standards or recommendations and can be published by anyone. Though they will be edited and maintained by FIP Editors, their publication does not indicate the collective preference or endorsement of the Filecoin community.
	Generally speaking, they are standards or recommendations and can be published by anyone. Though they will be reviewed and maintained by FIP Editors, their publication does not indicate the collective preference or endorsement of the Filecoin community.

aligning language with the two previous instances that mention FIP Editor involvement in this process

[LaurenSpiegel]

no "material" outstanding or previously...

[LaurenSpiegel]

what does this mean in this context? the Guild member entities need an open membership policy?

[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

[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.

[jennijuju]

"more complex" could be subjective - maybe give some examples?

[jennijuju]

what in https://spec.filecoin.io are we referring to here?

[jennijuju]

I don't think Filecoin spec https://spec.filecoin.io covers governance process. if I missed it - could you please share a link?

[f8-ptrk]

the specs at https://spec.filecoin.io do not cover governance

[jennijuju]

Suggested change

1. A **Technical FIP** 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, 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/).

1. A **Technical FIP** describes any change that affects most or all Filecoin implementations, such as a change to the network protocol, a change in block or message validity rules, 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/).

[jennijuju]

if warranted- an update to the formal specification.

if the spec fully reflects the filecoin protocol - then won't any technical FIP guaranteed to warrant an update to the filecoin spec?

[f8-ptrk]

it would.

as by now the specs DO NOT reflect the filecoin protocol in it latest state, nv20/21. mandatory updates to the specs were consistently argued against by FIP'ees, FIP editors and core devs as it adds a not insignificant overhead to the process.

it needs to be at least clear at what stage of the process the update to the specs needs to be written to avoid wasting resources on this for FIPs that do not get accepted.

it might make sense to remove this from 0001v2 and deal with the specs in a separate FIP/FRC to assure that they are up to date and consistent with the protocols state.

[jennijuju]

Please elaborate and define more clearly on what count as in "fundamentally change the economic logic", maybe some example: minting mechanism; mining reserves, consensus pledge system; gas mechanism, & etc

[jennijuju]

Suggested change

1. A **Technical FIP** 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, 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/).

1. A **Technical FIP** describes any change that affects most or all Filecoin implementations, such as a change to the network protocol that is consensus breaking, a change in block or transaction validity rules, 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/).

to differentiate from FRC as FRCs could propose changes towards network protocol as well, like market protocol, however such changes don't require networks upgrades for adoption and realization

[jennijuju]

could you please add what an FRC consists of? (i.e: for technical FIPs, it is specified it requires a design, an implementation, and an update to spec. I think for an FRC, a design and an implementation are needed at least

[jsoares]

I don't think a FRC needs an implementation. It's potentially useful for things that require interoperability (e.g. NFT standards), but option for things like consistent broadcast that are local decisions.

[jennijuju]

I think at least ONE reference implementation is needed to demonstrate the spec could be realized in production, Imho it's a part of review process of the FRC - ensure the spec is clearly stated and can be verified

[jsoares]

I think that's an artefact of the current process, in that we often don't specify things properly and instead rely on the code to do so. A clearly specified FIP FRC can be clearly stated and verifiable, though, particularly when it doesn't impact the line protocol and can be implemented with differences by different clients (think e.g. TCP congestion control [local] vs. segment structure [global]).

[f8-ptrk]

A clearly specified FIP can be clearly stated and verifiable

@jsoares you mean FRC, right?

[jsoares]

I did, thanks for catching it!

[jennijuju]

TE is a part of the network security. if an CE change is required for the network security, does it follow the security FIP governance process over the CE FIP governance process?

[jennijuju]

I recommend change this to FIP discussion - as that's the starting point of all FIPs today. an WIP status has no where to capture as the FIP only gets to merged and getting recorded when the Draft is approved and merged.

edit: reading the next line - do you maybe mean all FIPs' initial PR should start as status WIP, and gets updated to Draft when its ready to be merged?

[jennijuju]

and approval from Core Devs.

confirm you meant core dev not fip editor here? (asking cuz that's not the expectation today)

[jennijuju]

should otherwise be deprioritized.

Is there a reason why prioritization is ought to be defined at this stage? I personally an idea should only be "strike down" if and only if it is 'non sense" and would be wasting time for FIP editors / community to engage.

Core Devs maintain the right to strike down WIP Technical FIP drafts

Do you mean core dev or fip editors here?

[f8-ptrk]

the group represented by a guild seat should be able to autonomously decide the mechanism used to appoint a representative to the seat.

For example, there is one seat reserved for Storage Providers; the Storage Provider Working Group may be identified as the group that best represents this seat. It would thus be their obligation to provide a representative or representative(s) to represent the interests of Storage Providers and surface insight and expertise from within the SP community.

this should be removed. instead this FIP should provide a clear outline for groups represented by a guild seat on how to provide their own ways to propose/appoint a representative for the seat.

[f8-ptrk]

given that a Filecoin community stakeholder group will not vote to remove themself:

66% means that one of the founding institutions has to agree. this is questionable

[f8-ptrk]

do i get this right?

who is voting here? the guild members or "the community"? whats meant here with "the community"? how is that voting taking place if its not the guild members?

i am confused...

[f8-ptrk]

Votes cast in abstention will automatically count towards the majority preference

this is dangerous and can lead to a single votes favor accepting FIPs.

there should be a minimal active vote count to avoid this.

[f8-ptrk]

Guild members will be asked to accept or reject the FIP; they may not abstain

what happens if do abstain? there are clear mechanisms defined on how abstention is handled above. are those void in case of level 1 security thread fips?

this needs to be clear to avoid deadlocks

[f8-ptrk]

No minimum quorum must be reached in order for the poll to be valid.

this is dangerous

[f8-ptrk]

is policy the right word here?

[f8-ptrk]

When changes are necessary, it is important that these changes be subject to appropriate scrutiny prior to acceptance.

When changes are considered necessary, it is important that these changes be subject to appropriate scrutiny prior to acceptance.

[jsoares]

Suggested change

	* **Withdrawn** -- A FIP which was merged into the repo, but has sense been abandoned by its Author. FIP drafts should be considered 'withdrawn' after six months of inactivity.
	* **Withdrawn** -- A FIP which was merged into the repo, but was then (explicitly) withdrawn or (implicitly) abandoned by the Author. FIP drafts should be considered withdrawn after six months of inactivity.

This new withdrawn status might be a future solution to the discussion here (even if I still believe that we have a solution today in rejected). For that to be the case, though, we should expand the definition to allow for explicit withdrawal by the author.

[willscott]

who is allowed to 'vote' in such a poll / how are votes weighted?

[jsoares]

@kaitlin-beegle what's the status here? The PR has been open for 5 months and inactive for close to 2 months. We should convert it to draft if not in active review.

[kaitlin-beegle]

@kaitlin-beegle what's the status here? The PR has been open for 5 months and inactive for close to 2 months. We should convert it to draft if not in active review.

Hey @jsoares - I'd prefer if you leave it open, not as a draft, though I don't feel strongly about that request. I've left a lot of feedback yet unresolved because we aren't ready to incorporate final changes and push for the next stage of review.

We've been giving updates in Community Governance Calls; I've also written up the most recent update HERE.

tl;dr - we're about a quarter behind where we projected to be, and all of it is due to unforeseen complications with on-chain voting specification. This is a single blocker affecting all other parts of this effort.

• To support and resolve this, I'm looking to hire a TPM (familiar with smart contracts) to provide support for the next 8 weeks. Fully compensated, of course; I expect the work will require ~25% of their daily capacity. If you know anyone, I'd be grateful if you sent them my way!