docs: add ecosystem service credit RFC + RFC template

[clevinson]

ref #78

Proposed Changes

• Adds Ecosystem Service Credit RFC from google doc to .md file for archiving & visiblity
• Adds RFC folder
• Adds template for future RFCs

Feel free to submit a Draft Pull Request as soon as you start working on something. Before you mark your PR as Ready For Review, make sure you've checked off the following boxes or indicated N/A (not applicable):

• linked to a relevant issue or have written a clear description of the issue in the PR
• wrote or updated tests
• wrote or updated documentation
• added an appropriate entry in CHANGELOG.md following https://keepachangelog.com

Thanks!

[codecov]

Codecov Report

Merging #107 (7201fb3) into master (7287f51) will decrease coverage by 15.86%.
The diff coverage is n/a.

❗ Current head 7201fb3 differs from pull request most recent head c72cb69. Consider uploading reports for the commit c72cb69 to get more accurate results

@@             Coverage Diff             @@
##           master     #107       +/-   ##
===========================================
- Coverage   76.90%   61.03%   -15.87%     
===========================================
  Files         101       91       -10     
  Lines       12522     9021     -3501     
===========================================
- Hits         9630     5506     -4124     
- Misses       2288     3042      +754     
+ Partials      604      473      -131     

Flag	Coverage Δ
experimental-codecov	?
stable-codecov	61.03% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

[aaronc]

Could you add a README.md that indexes the RFC's? Maybe include a link in the README &/or template to the RFC process we're trying to follow.

[robert-zaremba]

Great overview and intro.
What's the reason of having this PR open? It's hard to read text docs in PR, and even harder to comment on the general structure).
Shall we merge this PR and iterate?

Also, is there any difference between this document and the RFC: Ecosystem Service Credit Module Google Doc? Would be good to keep things in one place, otherwise one will get outdated. So... maybe we should point from one document to another, and in the slave one remove the common content (maybe except the abstract) and point to the master document.

[robert-zaremba]

To be honest, I find it easier to read the spec docs in a more "Higher level" doc management system, like:

• dropbox paper
• google doc (has an advantage of "suggest mode")
• hackmd

All solutions above have a nice commenting system and also allow to trace edits with notifications / emails.

The advantage of each of that systems is that we observe a single working document rather than bunch of issues and pull-requests.

[aaronc]

Could you add a README @clevinson and then we'll merge as is and iterate if needed?

[robert-zaremba]

I think there were few updates in the Google Doc, could be good to port them and freeze the google doc.

[aaronc]

Ping @clevinson

[amaury1093]

Is this PR actually R4R? What should we do about it?

[clevinson]

Updated w/ @aaronc feedback adding a README & pushing this R4R again! I'd love to get this merged finally :)

Happy to iterate on this in the future, but my preference is that we start with this process (maybe initially with the ecocredit updates that we've already discussed implementing?), and then look to iterating once we have some momentum on creating these documents again.

[ryanchristo]

Looks great. A few minor suggestions but nothing blocking.

[ryanchristo]

Just noticed a typo in the filename: 001-ecosystem-serfice-credit-module.md

Stale

[technicallyty]

a few nits, pre-approving

[technicallyty]

Suggested change

Another design decision made in this proposal was to only implement two possible states for credits: “tradable” and “retired”. These are the two known states that we need to be able to manage for our first use case with the registry. While it is assumed that there may be more complex state machines that we will need to support at a later date, we chose to start with satisfying the current use case for the same reasons illustrated above (reducing complexity, and allowing future use cases to drive more complex functionality or generalizations).

Another design decision made in this proposal was to only implement two possible states for credits: “tradable” and “retired”. These are the two known states that we need to be able to manage for our first use case with the registry. While it is assumed there may be more complex states that we will need to support at a later date, we chose to start with satisfying the current use case for the same reasons illustrated above (reducing complexity, and allowing future use cases to drive more complex functionality or generalizations).

i think you meant only states here instead of state machines?

[clevinson]

No - meant state machines (Right now the state machine is tradable -> retired, as the only allowable state transition possible). It may be in the future that we have other state transitions possible (to newly defined states).

[clevinson]

Thanks @ryanchristo @technicallyty !