Add fip-0001 and initialize the repo #1

whyrusleeping · 2019-04-03T02:15:30Z

This is largely just ethereums process. It's a good one that has been adapted from bitcoins, which was adapted from pythons, and has served the community pretty well over the years.

I don't want to bikeshed things too much here, but there are a few points that we should figure out before proceeding (and several TODOs i wrote into the docs that need to be addressed).

Note that this process will not be actually used until the protocol and initial implementations are complete.

whyrusleeping · 2019-04-03T20:01:20Z

One change I want to make from the EIP process, is requiring a signoff from some representative[s] of the development team[s] before merging the draft. Often times in the ethereum ecosystem an EIP will get merged, and then when implementers go to implement it to move it on to the next stage of the process, they find all sorts of issues and the EIP ends up being rejected.

FIPS/fip-0001.md

dignifiedquire · 2019-04-03T20:07:50Z

FIPS/fip-0001.md

+* **Active** -- Some Informational and Process FIPs may also have a status of “Active” if they are never meant to be completed. E.g. FIP 1 (this FIP).
+* **Work in progress (WIP)** -- Once the champion has asked the Filecoin community whether an idea has any chance of support, they will write a draft FIP as a [pull request]. Consider including an implementation if this will aid people in studying the FIP.
+  * :arrow_right: Draft -- If agreeable, FIP editor will assign the FIP a number and merge your pull request. The FIP editor will not unreasonably deny an FIP.
+  * :x: Draft -- Reasons for denying draft status include being too unfocused, too broad, duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the [Ethereum philosophy](https://github.com/ethereum/wiki/wiki/White-Paper#philosophy). (TODO(why): we don't have a philosophy type thing... delete this?)


I think we should really have a small philosophy section somewhere, this will help a lot down the road when deciding how to change and expand Filecoin

I think instead of having a philosophy section, which is nice, but less directly actionable, we should have a 'Filecoin Project Goals' section, that details what Filecoin is trying to accomplish.

I think this should be an expanded version of the Filecoin mission statement. I'll sketch up a draft of that today.

sounds great

+1. I think it would be really helpful to have a documented set of "principles" of operation, as more actionable than philosophy. These would represent "how" to complement the mission's "what".

@whyrusleeping do you have the expanded version of the Filecoin mission statement? Can you point me to the most complete version available?

@anorth looks like @momack2 started a principles doc here, will iterate based on this.

@anorth @whyrusleeping - I'm working on this here.

dignifiedquire · 2019-04-03T20:12:19Z

FIPS/fip-0001.md

+* **Draft** -- Once the first draft has been merged, you may submit follow-up pull requests with further changes to your draft until such point as you believe the FIP to be mature and ready to proceed to the next status. An FIP in draft status must be implemented to be considered for promotion to the next status (ignore this requirement for core FIPs).
+  * :arrow_right: 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.
+  * :x: 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 on the RSS feed.
+* **Last Call** -- This FIP will listed prominently on the https://eips.ethereum.org/ website (subscribe via RSS at [last-call.xml](/last-call.xml)). (TODO(why): should we have a website for this?)


ethereum website links should be removed

I think a website is not really needed if we have an easy way to link to all the final call ones and link from the website

so we should have somewhere on our website that points to these, not necessarily a dedicated website though, agree?

dignifiedquire · 2019-04-03T20:14:34Z

FIPS/fip-0001.md

+  * :arrow_right: Accepted (Core FIPs only) -- A successful Last Call without material changes or unaddressed technical complaints will become Accepted.
+  * :arrow_right: Final (Not core FIPs) -- A successful Last Call without material changes or unaddressed technical complaints will become Final.
+* **Accepted (Core FIPs only)** -- This FIP is in the hands of the Filecoin client developers.  Their process for deciding whether to encode it into their clients as part of a hard fork is not part of the FIP process.
+  * :arrow_right: Final -- Standards Track Core FIPs must be implemented in at least three viable Filecoin clients before it can be considered Final. When the implementation is complete and adopted by the community, the status will be changed to “Final”.


three seems high given we currently don’t have that many impls, maybe sth like two thirds of all main clients or sth similar

Yeah, we could just say "two major client implementations" for now

whyrusleeping · 2019-04-03T20:59:50Z

One change I want to make from the EIP process, is requiring a signoff from some representative[s] of the development team[s] before merging the draft.

Thinking about this some more, I still think its probably a good idea. But we could also put more emphasis on the 'being technically sound' requirement of merging a draft.

dignifiedquire · 2019-04-03T21:35:14Z

thinking about it I wonder if we actually need to make that formal, or simply hold the proposals to a high technical standard with prototype implementations for complex changes

anorth

This looks broadly good to me.

The "Filecoin Core Developers" label is not well defined. Maybe this isn't the place, a bit more detail here would help.

FIPS/fip-0001.md

anorth · 2019-04-04T00:05:55Z

FIPS/fip-0001.md

+* **Active** -- Some Informational and Process FIPs may also have a status of “Active” if they are never meant to be completed. E.g. FIP 1 (this FIP).
+* **Work in progress (WIP)** -- Once the champion has asked the Filecoin community whether an idea has any chance of support, they will write a draft FIP as a [pull request]. Consider including an implementation if this will aid people in studying the FIP.
+  * :arrow_right: Draft -- If agreeable, FIP editor will assign the FIP a number and merge your pull request. The FIP editor will not unreasonably deny an FIP.
+  * :x: Draft -- Reasons for denying draft status include being too unfocused, too broad, duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the [Ethereum philosophy](https://github.com/ethereum/wiki/wiki/White-Paper#philosophy). (TODO(why): we don't have a philosophy type thing... delete this?)


+1. I think it would be really helpful to have a documented set of "principles" of operation, as more actionable than philosophy. These would represent "how" to complement the mission's "what".

anorth · 2019-04-04T00:12:43Z

README.md

+* **Accepted** - a core FIP that has been in Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author. The process for Core Devs to decide whether to encode an FIP into their clients as part of a hard fork is not part of the FIP process. If such a decision is made, the FIP wil move to final.
+* **Final (non-Core)** - an FIP that has been in Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author.
+* **Final (Core)** - an FIP that the Core Devs have decided to implement and release in a future hard fork or has already been released in a hard fork. 
+* **Deferred** - an FIP that is not being considered for immediate adoption. May be reconsidered in the future for a subsequent hard fork.


Link to FIP-1?

momack2 · 2020-08-15T01:20:36Z

FIPS/fip-0001.md

+
+Parties involved in the process are you, the champion or *FIP author*, the [*FIP editors*](#fip-editors), and the *Filecoin Core Developers*.
+
+:warning: Before you begin, vet your idea, this will save you time. Ask the Filecoin community first if an idea is original to avoid wasting time on something that will be be rejected based on prior research (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Filecoin is used. Examples of appropriate public forums to gauge interest around your FIP include [the Issues section of this repository], [the Filecoin Discourse Forum], and [the Filecoin community chat]. In particular, [the Issues section of this repository] is an excellent place to discuss your proposal with the community and start creating more formalized language around your FIP.


Suggested change

:warning: Before you begin, vet your idea, this will save you time. Ask the Filecoin community first if an idea is original to avoid wasting time on something that will be be rejected based on prior research (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Filecoin is used. Examples of appropriate public forums to gauge interest around your FIP include [the Issues section of this repository], [the Filecoin Discourse Forum], and [the Filecoin community chat]. In particular, [the Issues section of this repository] is an excellent place to discuss your proposal with the community and start creating more formalized language around your FIP.

:warning: Before you begin, vet your idea, this will save you time. Ask the Filecoin community first if an idea is original to avoid wasting time on something that will be be rejected based on prior research (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Filecoin is used. Examples of appropriate public forums to gauge interest around your FIP include [the Issues section of this repository](https://github.com/filecoin-project/FIPs/issues), [the Filecoin Discourse Forum](https://discuss.filecoin.io/), and [the Filecoin community chat](https://filecoin.io/slack). In particular, [the Issues section of this repository](https://github.com/filecoin-project/FIPs/issues) is an excellent place to discuss your proposal with the community and start creating more formalized language around your FIP.

mishmosh · 2020-09-04T19:33:18Z

fip-XXXX.md

+
+## Simple Summary
+<!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the FIP.-->
+If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the FIP.


Suggested change

If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the FIP.

If you can't explain it simply, you don't understand it well enough." Provide a simplified and layperson-accessible explanation of the FIP.

momack2 · 2020-09-07T07:37:25Z

README.md

+When you believe your FIP is mature and ready to progress past the draft phase, you should do one of two things:
+
+TODO: core devs meeting? Where should these things be discussed?
+ - **For a Standards Track FIP of type Core**, ask to have your issue added to [the agenda of an upcoming All Core Devs meeting](https://github.com/filecoin-project/pm/issues), where it can be discussed for inclusion in a future hard fork. If implementers agree to include it, the FIP editors will update the state of your FIP to 'Accepted'.


Suggested change

- **For a Standards Track FIP of type Core**, ask to have your issue added to [the agenda of an upcoming All Core Devs meeting](https://github.com/filecoin-project/pm/issues), where it can be discussed for inclusion in a future hard fork. If implementers agree to include it, the FIP editors will update the state of your FIP to 'Accepted'.

- **For a Standards Track FIP of type Core**, ask to have your issue added to [the agenda of an upcoming All Core Devs meeting](https://github.com/filecoin-project/tpm/issues), where it can be discussed for inclusion in a future hard fork. If implementers agree to include it, the FIP editors will update the state of your FIP to 'Accepted'.

momack2 · 2020-09-07T07:37:56Z

README.md

+
+When you believe your FIP is mature and ready to progress past the draft phase, you should do one of two things:
+
+TODO: core devs meeting? Where should these things be discussed?


Suggested change

TODO: core devs meeting? Where should these things be discussed?

Created a repo and scheduled the first Core Devs meeting: https://github.com/filecoin-project/tpm

androowoo · 2020-09-08T23:19:01Z

FIPS/fip-0001.md

+There are three types of FIP:
+
+- A **Standard Track FIP** describes any change that affects most or all Filecoin implementations, such as a change to the the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Filecoin. Furthermore Standard FIPs can be broken down into the following categories. Standards Track FIPs consist of three parts, a design document, implementation, and finally if warranted an update to the [formal specification].
+  - **Core** - improvements requiring a consensus fork, as well as changes that are not necessarily consensus critical but may be relevant to [“core dev” discussions](https://github.com/filecoin-project/pm). (TODO(why): need to think through this one a bit)


Suggested change

- **Core** - improvements requiring a consensus fork, as well as changes that are not necessarily consensus critical but may be relevant to [“core dev” discussions](https://github.com/filecoin-project/pm). (TODO(why): need to think through this one a bit)

- **Core** - improvements requiring a consensus upgrade, as well as changes that are not necessarily consensus critical but may be relevant to future consensus upgrades.

androowoo · 2020-09-08T23:22:40Z

FIPS/fip-0001.md

+* **Draft** -- Once the first draft has been merged, you may submit follow-up pull requests with further changes to your draft until such point as you believe the FIP to be mature and ready to proceed to the next status. An FIP in draft status must be implemented to be considered for promotion to the next status (ignore this requirement for core FIPs).
+  * :arrow_right: 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.
+  * :x: 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 on the RSS feed.
+* **Last Call** -- This FIP will listed prominently on the Filecoin website (TODO(why): need to get this set up at some point)


Suggested change

* **Last Call** -- This FIP will listed prominently on the Filecoin website (TODO(why): need to get this set up at some point)

* **Last Call** -- This FIP will listed prominently on the Filecoin website.

androowoo · 2020-09-08T23:25:35Z

FIPS/fip-0001.md

+
+This document was derived heavily from [Ethereum's EIP 1] written by Martin Becze and Hudson Jameson, which was derived from [Bitcoin's BIP-0001] written by Amir Taaki which in turn was derived from [Python's PEP-0001]. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Filecoin Improvement Process, and should not be bothered with technical questions specific to Filecoin or the FIP. Please direct all comments to the FIP editors.
+
+April 2, 2019: FIP 1 created from EIP 1


Suggested change

April 2, 2019: FIP 1 created from EIP 1

Sep 8, 2020: FIP 1 created from EIP 1

Co-authored-by: MollyM <[email protected]>

FIPS/fip-0001.md

jsoares

Adds security considerations, mirroring EIP amendment in ethereum/EIPs#1963. Misc fixes.

jsoares · 2020-09-09T16:08:58Z

FIPS/fip-0001.md

+- Rationale - The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.
+- Backwards Compatibility - All FIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The FIP must explain how the author proposes to deal with these incompatibilities. FIP submissions without a sufficient backwards compatibility treatise may be rejected outright.
+- Test Cases - Test cases for an implementation are mandatory for FIPs that are affecting consensus changes. Other FIPs can choose to include links to test cases if applicable.
+- Implementations - The implementations must be completed before any FIP is given status “Final”, but it need not be completed before the FIP is merged as draft. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of “rough consensus and running code” is still useful when it comes to resolving many discussions of API details.


Suggested change

- Implementations - The implementations must be completed before any FIP is given status “Final”, but it need not be completed before the FIP is merged as draft. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of “rough consensus and running code” is still useful when it comes to resolving many discussions of API details.

- Security Considerations - All FIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. FIP submissions missing the "Security Considerations" section will be rejected. A FIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.

- Implementations - The implementations must be completed before any FIP is given status “Final”, but it need not be completed before the FIP is merged as draft. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of “rough consensus and running code” is still useful when it comes to resolving many discussions of API details.

Mirrors security section added to the EIP process in Dec 19.

jsoares · 2020-09-09T16:13:08Z

fip-XXXX.md

+## Implementation
+<!--The implementations must be completed before any FIP is given status "Final", but it need not be completed before the FIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.-->
+The implementations must be completed before any FIP is given status "Final", but it need not be completed before the FIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.
+


Suggested change

## Security Considerations



All FIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. FIP submissions missing the "Security Considerations" section will be rejected. A FIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.

Mirrors security section added to the EIP process in Dec 19.

jsoares · 2020-09-09T16:17:23Z

README.md

+
+If your FIP requires images, the image files should be included in a subdirectory of the `assets` folder for that FIP as follow: `assets/fip-X` (for fip **X**). When linking to an image in the FIP, use relative links such as `../assets/fip-X/image.png`.
+
+Once your first PR is merged, we have a bot that helps out by automatically merging PRs to draft FIPs. For this to work, it has to be able to tell that you own the draft being edited. Make sure that the 'author' line of your FIP contains either your Github username or your email address inside <triangular brackets>. If you use your email address, that address must be the one publicly shown on [your GitHub profile](https://github.com/settings/profile).


Suggested change

Once your first PR is merged, we have a bot that helps out by automatically merging PRs to draft FIPs. For this to work, it has to be able to tell that you own the draft being edited. Make sure that the 'author' line of your FIP contains either your Github username or your email address inside <triangular brackets>. If you use your email address, that address must be the one publicly shown on [your GitHub profile](https://github.com/settings/profile).

Once your first PR is merged, we have a bot that helps out by automatically merging PRs to draft FIPs. For this to work, it has to be able to tell that you own the draft being edited. Make sure that the 'author' line of your FIP contains either your GitHub username or your email address inside <triangular brackets>. If you use your email address, that address must be the one publicly shown on [your GitHub profile](https://github.com/settings/profile).

Fix spelling

jsoares · 2020-09-09T16:18:22Z

FIPS/fip-0001.md

+
+Each status change is requested by the FIP author and reviewed by the FIP editors. Use a pull request to update the status. Please include a link to where people should continue discussing your FIP. The FIP editors will process these requests as per the conditions below.
+
+* **Active** -- Some Informational and Process FIPs may also have a status of “Active” if they are never meant to be completed. E.g. FIP 1 (this FIP).


Suggested change

* **Active** -- Some Informational and Process FIPs may also have a status of “Active” if they are never meant to be completed. E.g. FIP 1 (this FIP).

* **Active** -- Some Informational and Process FIPs may also have a status of “Active” if they are never meant to be completed. E.g. FIP-1 (this FIP).

Fix inconsistent use of FIP-1 vs. FIP 1.

jsoares · 2020-09-09T16:19:23Z

FIPS/fip-0001.md

+
+This document was derived heavily from [Ethereum's EIP 1] written by Martin Becze and Hudson Jameson, which was derived from [Bitcoin's BIP-0001] written by Amir Taaki which in turn was derived from [Python's PEP-0001]. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Filecoin Improvement Process, and should not be bothered with technical questions specific to Filecoin or the FIP. Please direct all comments to the FIP editors.
+
+April 2, 2019: FIP 1 created from EIP 1


Suggested change

April 2, 2019: FIP 1 created from EIP 1

April 2, 2019: FIP-1 created from EIP-1

Fix inconsistent use of FIP-1 vs. FIP 1

jsoares · 2020-09-09T16:56:22Z

FIPS/fip-0001.md

+
+Once the FIP is ready for the repository, the FIP editor will:
+
+- Assign an FIP number (generally the PR number or, if preferred by the author, the Issue # if there was discussion in the Issues section of this repository about this FIP)


Suggested change

- Assign an FIP number (generally the PR number or, if preferred by the author, the Issue # if there was discussion in the Issues section of this repository about this FIP)

- Assign a FIP number (generally the PR number or, if preferred by the author, the Issue # if there was discussion in the Issues section of this repository about this FIP)

jsoares · 2020-09-09T16:56:51Z

FIPS/fip-0001.md

+
+Many FIPs are written and maintained by developers with write access to the Filecoin codebase. The FIP editors monitor FIP changes, and correct any structure, grammar, spelling, or markup mistakes we see.
+
+The editors don't pass judgment on FIPs. We merely do the administrative & editorial part.


Is this true?

I find that hard to believe/implement when the FIP editors are also key core developers. Is it even possible to have a substantive discussion around the merit and feasibility of a FIP without Dig and Why offering their opinions?

jsoares · 2020-09-09T16:57:41Z

FIPS/fip-0001.md

+
+## History
+
+This document was derived heavily from [Ethereum's EIP 1] written by Martin Becze and Hudson Jameson, which was derived from [Bitcoin's BIP-0001] written by Amir Taaki which in turn was derived from [Python's PEP-0001]. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Filecoin Improvement Process, and should not be bothered with technical questions specific to Filecoin or the FIP. Please direct all comments to the FIP editors.


Suggested change

This document was derived heavily from [Ethereum's EIP 1] written by Martin Becze and Hudson Jameson, which was derived from [Bitcoin's BIP-0001] written by Amir Taaki which in turn was derived from [Python's PEP-0001]. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Filecoin Improvement Process, and should not be bothered with technical questions specific to Filecoin or the FIP. Please direct all comments to the FIP editors.

This document was derived heavily from [Ethereum's EIP-1] written by Martin Becze and Hudson Jameson, which was derived from [Bitcoin's BIP-0001] written by Amir Taaki which in turn was derived from [Python's PEP-0001]. In many places, the text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Filecoin Improvement Process, and should not be bothered with technical questions specific to Filecoin or the FIP. Please direct all comments to the FIP editors.

Adjust to revised EIP naming conventions (EIP-1)

jsoares · 2020-09-09T16:59:08Z

FIPS/fip-0001.md

+[pull request]: https://github.com/filecoin-project/FIPs/pulls
+[formal specification]: https://github.com/filecoin-project/specs
+[the Issues section of this repository]: https://github.com/filecoin-project/FIPs/issues
+[markdown]: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet


This looks like a pretty arbitrary selection of links. I'm not sure the whole bibliography section adds value.

jsoares · 2020-09-09T16:59:48Z

FIPS/fip-0001.md

+[Ethereum's EIP 1]: https://github.com/ethereum/EIPs
+[Bitcoin's BIP-0001]: https://github.com/bitcoin/bips
+[Python's PEP-0001]: https://www.python.org/dev/peps/


Suggested change

[Ethereum's EIP 1]: https://github.com/ethereum/EIPs

[Bitcoin's BIP-0001]: https://github.com/bitcoin/bips

[Python's PEP-0001]: https://www.python.org/dev/peps/

[Ethereum's EIPs]: https://github.com/ethereum/EIPs

[Bitcoin's BIPs]: https://github.com/bitcoin/bips

[Python's PEPs]: https://www.python.org/dev/peps/

Text matches URLs

yiannisbot

Looks really good. Left some suggestions.

yiannisbot · 2020-09-10T06:17:42Z

FIPS/fip-0001.md

+  - **Core** - improvements requiring a consensus upgrade, as well as changes that are not necessarily consensus critical but may be relevant to future consensus upgrades. (TODO(why): need to think through this one a bit)
+  - **Networking** - includes improvements to data propogation, or any of the filecoin network protocols, see [Network Protocols] in the spec for a full listing. 
+  - **Interface** - includes improvements around client [API/RPC] specifications and standards, and also certain language-level standards like method names. 
+- An **Informational FIP** describes a Filecoin design issue, or provides general guidelines or information to the Filecoin community, but does not propose a new feature. Informational FIPs do not necessarily represent Filecoin community consensus or a recommendation, so users and implementers are free to ignore Informational FIPs or follow their advice.


Suggested change

- An **Informational FIP** describes a Filecoin design issue, or provides general guidelines or information to the Filecoin community, but does not propose a new feature. Informational FIPs do not necessarily represent Filecoin community consensus or a recommendation, so users and implementers are free to ignore Informational FIPs or follow their advice.

- An **Informational FIP** describes a Filecoin design issue, or provides general guidelines or information to the Filecoin community, but does not propose a new feature. Informational FIPs do not necessarily represent Filecoin community consensus or a recommendation, so users and implementers are free to follow or ignore Informational FIPs.

FIPS/fip-0001.md

yiannisbot · 2020-09-10T07:06:45Z

FIPS/fip-0001.md

+
+:warning: Before you begin, vet your idea, this will save you time. Ask the Filecoin community first if an idea is original to avoid wasting time on something that will be be rejected based on prior research (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Filecoin is used. Examples of appropriate public forums to gauge interest around your FIP include [the Issues section of this repository], [the Filecoin Discourse Forum], and [the Filecoin community chat]. In particular, [the Issues section of this repository] is an excellent place to discuss your proposal with the community and start creating more formalized language around your FIP.
+
+Your role as the champion is to write the FIP using the style and format described below, shepherd the discussions in the appropriate forums, and build community consensus around the idea. Following is the process that a successful FIP will move along:


I suggest that although discussions can take place in multiple places, there is a single source of truth for decision-making. Someone who wants to follow history of discussion should be able to find it in one place. I think this should be highlighted. The most convenient place in this case seems to be GH.

yiannisbot · 2020-09-10T07:24:19Z

FIPS/fip-0001.md

+  * :arrow_right: Final (Not core FIPs) -- A successful Last Call without material changes or unaddressed technical complaints will become Final.
+* **Accepted (Core FIPs only)** -- This FIP is in the hands of the Filecoin client developers.  Their process for deciding whether to encode it into their clients as part of a hard fork is not part of the FIP process.
+  * :arrow_right: Final -- Standards Track Core FIPs must be implemented in at least two viable Filecoin clients before it can be considered Final. When the implementation is complete and adopted by the community, the status will be changed to “Final”.
+* **Final** -- This FIP represents the current state-of-the-art. A Final FIP should only be updated to correct errata.


I believe there are two parts to the FIP process:

The proposal itself, which comes in text form with its argumentation, e.g., "I propose to change the behaviour of an algorithm to do xyz, instead of zyx as in today's protocol, because..".

The actual code that implements the proposal.
Both of these will come as PRs. The first one in this repository and the second one in the code repository(ies) that the proposal touches.

The text above touches step 1) only, but any subsequent PRs that work on the implementation should be linked to the FIP PR, e.g., through a codename/FIP number. I think it would be useful to clarify this and also indicate when implementation should start (e.g., only after the FIP gets the "Final" stamp).

To get the Final stamp the FIP must be implemented by 2 clients - so FIPs should be implemented when Accepted

yiannisbot · 2020-09-10T07:38:11Z

FIPS/fip-0001.md

+
+Once the FIP is ready for the repository, the FIP editor will:
+
+- Assign an FIP number (generally the PR number or, if preferred by the author, the Issue # if there was discussion in the Issues section of this repository about this FIP)


Numbering FIPs by the PR number only will be confusing IMO. I would be in favour of having a sequence number instead, or in addition. For example, a convention of FIP-2.1321 could stand for the second FIP in history, proposed in PR #1321.

yiannisbot · 2020-09-10T07:57:44Z

fip-XXXX.md

+
+## Implementation
+<!--The implementations must be completed before any FIP is given status "Final", but it need not be completed before the FIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.-->
+The implementations must be completed before any FIP is given status "Final", but it need not be completed before the FIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.


IMO, it should be made clear earlier in the doc when the suggested time to start implementation is. I guess it is not suggested to start implementation before getting initial feedback from the community on whether this is a "go vs no-go" to avoid having people invest their time when there's no chance of a FIP being accepted - although this is down to the proposers of course.

An idea is to have a checkpoint at which proposers are given the OK to go on with implementation (probably the "Accepted" stage), suggesting that unless something turns out to be terribly wrong the FIP will most likely make it to "Final". On the other hand, a FIP should not get to "Final" unless there is the implementation to support the arguments made.

All this is implied in the text, but not explicitly said. I think it would be helpful to clarify.

yiannisbot · 2020-09-10T08:00:09Z

fip-XXXX.md

+
+## Motivation
+<!--The motivation is critical for FIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the FIP solves. FIP submissions without sufficient motivation may be rejected outright.-->
+The motivation is critical for FIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the FIP solves. FIP submissions without sufficient motivation may be rejected outright.


Suggested change

The motivation is critical for FIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the FIP solves. FIP submissions without sufficient motivation may be rejected outright.

The motivation is critical for FIPs that want to change the Filecoin protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the FIP solves. FIP submissions without sufficient motivation may be rejected outright.

yiannisbot · 2020-09-10T08:04:08Z

fip-XXXX.md

+
+## Motivation
+<!--The motivation is critical for FIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the FIP solves. FIP submissions without sufficient motivation may be rejected outright.-->
+The motivation is critical for FIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the FIP solves. FIP submissions without sufficient motivation may be rejected outright.


I think it would be useful to add something on the "Impact" that the proposed FIP will have if deployed, e.g., "the proposed improvement can increase chain throughput by X%", although this should not be too hand-wavy and should ideally be supported by some sort of early evidence.

zixuanzh · 2020-09-10T18:50:50Z

FIPS/fip-0001.md

+  * :x: -- A Last Call which results in material changes or substantial unaddressed technical complaints will cause the FIP to revert to Draft.
+  * :arrow_right: Accepted (Core FIPs only) -- A successful Last Call without material changes or unaddressed technical complaints will become Accepted.
+  * :arrow_right: Final (Not core FIPs) -- A successful Last Call without material changes or unaddressed technical complaints will become Final.
+* **Accepted (Core FIPs only)** -- This FIP is in the hands of the Filecoin client developers.  Their process for deciding whether to encode it into their clients as part of a hard fork is not part of the FIP process.


The document is still lacking in how decisions are made and what makes an FIP "accepted". There are many constraints and entities in Filecoin. I would expect a checklist of constraints with reviews (e.g. security, implementation complexity, incentive, etc) and a checklist of different entities interests (e.g. storage clients, current miners large and small, future miners large and small, application developers, protocol researchers, ecosystem partners, token holders, etc)

androowoo · 2020-09-10T23:16:18Z

FIPS/fip-0001.md

+
+Many FIPs are written and maintained by developers with write access to the Filecoin codebase. The FIP editors monitor FIP changes, and correct any structure, grammar, spelling, or markup mistakes we see.
+
+The editors don't pass judgment on FIPs. We merely do the administrative & editorial part.


momack2 · 2020-09-11T03:09:24Z

FYI, andrew - you merged this PR without any of the suggestions included - including a lot of missed "Ethereums" and some useful suggestions. In the future, it'd be good to merge suggestions first so they aren't lost.

* feat: add unfinished draft for SuperSnaps * Add some required updates * Add aggregate verification gas costs (#1) * Additional edits * Add gas plots and min/max aggregation sizes (#2) * Add supersnap gas plots * Add min/max values for the numbers of aggregatable proofs * Center justify gas cost table * Spelling, grammer, re-wording, etc. fixes (#3) * Apply review feedback * Apply review feedback and rebase onto FIP-0076 (#4) * Updates for FIP-0082 assignment * Update FIPS/fip-0082.md Co-authored-by: Jorge Soares <[email protected]> * Apply review feedback --------- Co-authored-by: DrPeterVanNostrand <[email protected]> Co-authored-by: Jorge Soares <[email protected]>

…nd Market Actors (#872) * fip for built-in Actor events * finish draft * fix formatting * changes as per review #1 * link FIPs * Apply suggestions from code review Applying editorial changes. Co-authored-by: Jorge Soares <[email protected]> * update Market Actor events * add FIP number * Apply suggestions from code review Co-authored-by: Jiaying Wang <[email protected]> --------- Co-authored-by: Jorge Soares <[email protected]> Co-authored-by: Jiaying Wang <[email protected]>

… Sector Activation events as per FIP discussion (#897) * fip for built-in Actor events * finish draft * fix formatting * changes as per review #1 * link FIPs * Apply suggestions from code review Applying editorial changes. Co-authored-by: Jorge Soares <[email protected]> * update Market Actor events * add FIP number * update fip-0083 to incorporate changes to market actor and sector activation events * Apply suggestions from code review Co-authored-by: Alex North <[email protected]> * change language --------- Co-authored-by: Jorge Soares <[email protected]> Co-authored-by: Alex North <[email protected]>

Add fip-0001 and initialize the repo

0556cca

whyrusleeping requested review from dignifiedquire, jbenet, pooja, nicola, anorth, porcuquine, protocolin and ianjdarrow April 3, 2019 02:15

dignifiedquire reviewed Apr 3, 2019

View reviewed changes

clean up some links, add todo about website

a445b20

anorth reviewed Apr 4, 2019

View reviewed changes

momack2 reviewed Aug 15, 2020

View reviewed changes

mishmosh reviewed Sep 4, 2020

View reviewed changes

momack2 reviewed Sep 7, 2020

View reviewed changes

androowoo reviewed Sep 8, 2020

View reviewed changes

daviddias and others added 2 commits September 9, 2020 07:21

Update FIPS/fip-0001.md

4480f1e

Co-authored-by: MollyM <[email protected]>

Update FIPS/fip-0001.md

52e37e4

Co-authored-by: MollyM <[email protected]>

daviddias reviewed Sep 9, 2020

View reviewed changes

FIPS/fip-0001.md Show resolved Hide resolved

daviddias requested review from hugomrdias and yiannisbot September 9, 2020 15:30

jsoares reviewed Sep 9, 2020

View reviewed changes

yiannisbot reviewed Sep 10, 2020

View reviewed changes

zixuanzh reviewed Sep 10, 2020

View reviewed changes

androowoo approved these changes Sep 10, 2020

View reviewed changes

androowoo merged commit 98cf6ec into master Sep 10, 2020

momack2 mentioned this pull request Sep 11, 2020

Security consideration #4

Merged

jsoares mentioned this pull request Sep 11, 2020

Proofreading fixes #5

Merged

aarshkshah1992 added a commit that referenced this pull request Dec 12, 2023

changes as per review #1

edba91f

jsoares mentioned this pull request Aug 7, 2024

FIP-0093: Set the Mining Reserve to Zero #1039

Open


		Parties involved in the process are you, the champion or FIP author, the [FIP editors](#fip-editors), and the Filecoin Core Developers.

		:warning: Before you begin, vet your idea, this will save you time. Ask the Filecoin community first if an idea is original to avoid wasting time on something that will be be rejected based on prior research (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Filecoin is used. Examples of appropriate public forums to gauge interest around your FIP include [the Issues section of this repository], [the Filecoin Discourse Forum], and [the Filecoin community chat]. In particular, [the Issues section of this repository] is an excellent place to discuss your proposal with the community and start creating more formalized language around your FIP.

	If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the FIP.
	If you can't explain it simply, you don't understand it well enough." Provide a simplified and layperson-accessible explanation of the FIP.

	- For a Standards Track FIP of type Core, ask to have your issue added to [the agenda of an upcoming All Core Devs meeting](https://github.com/filecoin-project/pm/issues), where it can be discussed for inclusion in a future hard fork. If implementers agree to include it, the FIP editors will update the state of your FIP to 'Accepted'.
	- For a Standards Track FIP of type Core, ask to have your issue added to [the agenda of an upcoming All Core Devs meeting](https://github.com/filecoin-project/tpm/issues), where it can be discussed for inclusion in a future hard fork. If implementers agree to include it, the FIP editors will update the state of your FIP to 'Accepted'.


		When you believe your FIP is mature and ready to progress past the draft phase, you should do one of two things:

		TODO: core devs meeting? Where should these things be discussed?

	- Core - improvements requiring a consensus fork, as well as changes that are not necessarily consensus critical but may be relevant to [“core dev” discussions](https://github.com/filecoin-project/pm). (TODO(why): need to think through this one a bit)
	- Core - improvements requiring a consensus upgrade, as well as changes that are not necessarily consensus critical but may be relevant to future consensus upgrades.

	* Last Call -- This FIP will listed prominently on the Filecoin website (TODO(why): need to get this set up at some point)
	* Last Call -- This FIP will listed prominently on the Filecoin website.


		This document was derived heavily from [Ethereum's EIP 1] written by Martin Becze and Hudson Jameson, which was derived from [Bitcoin's BIP-0001] written by Amir Taaki which in turn was derived from [Python's PEP-0001]. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Filecoin Improvement Process, and should not be bothered with technical questions specific to Filecoin or the FIP. Please direct all comments to the FIP editors.

		April 2, 2019: FIP 1 created from EIP 1

	April 2, 2019: FIP 1 created from EIP 1
	Sep 8, 2020: FIP 1 created from EIP 1

	- Implementations - The implementations must be completed before any FIP is given status “Final”, but it need not be completed before the FIP is merged as draft. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of “rough consensus and running code” is still useful when it comes to resolving many discussions of API details.
	- Security Considerations - All FIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. FIP submissions missing the "Security Considerations" section will be rejected. A FIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.
	- Implementations - The implementations must be completed before any FIP is given status “Final”, but it need not be completed before the FIP is merged as draft. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of “rough consensus and running code” is still useful when it comes to resolving many discussions of API details.

+## Security Considerations
+<!--All FIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. FIP submissions missing the "Security Considerations" section will be rejected. A FIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.-->
+All FIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. FIP submissions missing the "Security Considerations" section will be rejected. A FIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.


		If your FIP requires images, the image files should be included in a subdirectory of the `assets` folder for that FIP as follow: `assets/fip-X` (for fip X). When linking to an image in the FIP, use relative links such as `../assets/fip-X/image.png`.

		Once your first PR is merged, we have a bot that helps out by automatically merging PRs to draft FIPs. For this to work, it has to be able to tell that you own the draft being edited. Make sure that the 'author' line of your FIP contains either your Github username or your email address inside <triangular brackets>. If you use your email address, that address must be the one publicly shown on [your GitHub profile](https://github.com/settings/profile).


		Each status change is requested by the FIP author and reviewed by the FIP editors. Use a pull request to update the status. Please include a link to where people should continue discussing your FIP. The FIP editors will process these requests as per the conditions below.

		* Active -- Some Informational and Process FIPs may also have a status of “Active” if they are never meant to be completed. E.g. FIP 1 (this FIP).

	April 2, 2019: FIP 1 created from EIP 1
	April 2, 2019: FIP-1 created from EIP-1


		Once the FIP is ready for the repository, the FIP editor will:

		- Assign an FIP number (generally the PR number or, if preferred by the author, the Issue # if there was discussion in the Issues section of this repository about this FIP)

	- Assign an FIP number (generally the PR number or, if preferred by the author, the Issue # if there was discussion in the Issues section of this repository about this FIP)
	- Assign a FIP number (generally the PR number or, if preferred by the author, the Issue # if there was discussion in the Issues section of this repository about this FIP)


		Many FIPs are written and maintained by developers with write access to the Filecoin codebase. The FIP editors monitor FIP changes, and correct any structure, grammar, spelling, or markup mistakes we see.

		The editors don't pass judgment on FIPs. We merely do the administrative & editorial part.


		## History

		This document was derived heavily from [Ethereum's EIP 1] written by Martin Becze and Hudson Jameson, which was derived from [Bitcoin's BIP-0001] written by Amir Taaki which in turn was derived from [Python's PEP-0001]. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Filecoin Improvement Process, and should not be bothered with technical questions specific to Filecoin or the FIP. Please direct all comments to the FIP editors.

	- An Informational FIP describes a Filecoin design issue, or provides general guidelines or information to the Filecoin community, but does not propose a new feature. Informational FIPs do not necessarily represent Filecoin community consensus or a recommendation, so users and implementers are free to ignore Informational FIPs or follow their advice.
	- An Informational FIP describes a Filecoin design issue, or provides general guidelines or information to the Filecoin community, but does not propose a new feature. Informational FIPs do not necessarily represent Filecoin community consensus or a recommendation, so users and implementers are free to follow or ignore Informational FIPs.


		:warning: Before you begin, vet your idea, this will save you time. Ask the Filecoin community first if an idea is original to avoid wasting time on something that will be be rejected based on prior research (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Filecoin is used. Examples of appropriate public forums to gauge interest around your FIP include [the Issues section of this repository], [the Filecoin Discourse Forum], and [the Filecoin community chat]. In particular, [the Issues section of this repository] is an excellent place to discuss your proposal with the community and start creating more formalized language around your FIP.

		Your role as the champion is to write the FIP using the style and format described below, shepherd the discussions in the appropriate forums, and build community consensus around the idea. Following is the process that a successful FIP will move along:

	The motivation is critical for FIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the FIP solves. FIP submissions without sufficient motivation may be rejected outright.
	The motivation is critical for FIPs that want to change the Filecoin protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the FIP solves. FIP submissions without sufficient motivation may be rejected outright.

Add fip-0001 and initialize the repo #1

Add fip-0001 and initialize the repo #1

Conversation

whyrusleeping commented Apr 3, 2019 • edited Loading

whyrusleeping commented Apr 3, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

whyrusleeping commented Apr 3, 2019

dignifiedquire commented Apr 3, 2019

anorth left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

androowoo Sep 8, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jsoares left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

yiannisbot left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

momack2 commented Sep 11, 2020

whyrusleeping commented Apr 3, 2019 •

edited

Loading

androowoo Sep 8, 2020 •

edited

Loading