From 4c5df480f4496d2f9250fa09aa83a049b26be39b Mon Sep 17 00:00:00 2001 From: lehnberg Date: Sat, 29 Jun 2019 13:34:50 +0100 Subject: [PATCH 01/13] add RFC state diagram --- assets/0001-state-diagram.puml | 43 +++++++++++++++++++++++ assets/0001-state-diagram.svg | 64 ++++++++++++++++++++++++++++++++++ 2 files changed, 107 insertions(+) create mode 100644 assets/0001-state-diagram.puml create mode 100644 assets/0001-state-diagram.svg diff --git a/assets/0001-state-diagram.puml b/assets/0001-state-diagram.puml new file mode 100644 index 0000000..592f2a2 --- /dev/null +++ b/assets/0001-state-diagram.puml @@ -0,0 +1,43 @@ +@startuml +hide empty description +skinparam shadowing false + +[*] -down-> long1 : [author]\nSubmit a PR to /grin-rfcs + +state "PR is Open" as long1 { +draft : * tag sub-team +draft : * assign shepherd +draft : * feedback from community +draft : * iterate on proposal +draft -right-> FCP : [shepherd]\nMotion to enter\nFinal Comment Period +FCP: * include disposition to merge/close/postpone +FCP: * final feedback from community +FCP: * final touches on proposal +} + +state close_join <> +draft --> close_join +FCP --> close_join + +state post_join <> +draft --> post_join +FCP --> post_join + +state "PR is Closed" as long2 { +close_join -down-> closed : Close RFC +post_join -down-> postponed : Postpone RFC +} + +state "PR is Merged" as long3 { +FCP -right-> active : [shepherd]\nMerge RFC +active --> active : Minor changes\nthrough new PR +active: * assign RFC number +active: * create tracking issue in relevant repo +active: * make note if superseded by a new RFC +} + +postponed --> draft : Re-open PR +postponed --> [*] +closed --> [*] +active --> [*] +@enduml \ No newline at end of file diff --git a/assets/0001-state-diagram.svg b/assets/0001-state-diagram.svg new file mode 100644 index 0000000..c6cde1a --- /dev/null +++ b/assets/0001-state-diagram.svg @@ -0,0 +1,64 @@ +PR is OpenPR is ClosedPR is Mergeddrafttag sub-teamassign shepherdfeedback from communityiterate on proposalFCPinclude disposition to merge/close/postponefinal feedback from communityfinal touches on proposalclosedpostponedactiveassign RFC numbercreate tracking issue in relevant repomake note if superseded by a new RFC[author]Submit a PR to /grin-rfcs[shepherd]Motion to enterFinal Comment PeriodClose RFCPostpone RFC[shepherd]Merge RFCMinor changesthrough new PRRe-open PR \ No newline at end of file From 45e909ae231d54bde086a1de2eacdbf63964b060 Mon Sep 17 00:00:00 2001 From: lehnberg Date: Sat, 29 Jun 2019 13:38:39 +0100 Subject: [PATCH 02/13] rework header section --- text/0001-rfc-process.md | 23 ++++++++++------------- 1 file changed, 10 insertions(+), 13 deletions(-) diff --git a/text/0001-rfc-process.md b/text/0001-rfc-process.md index 833fd8d..50cf02f 100644 --- a/text/0001-rfc-process.md +++ b/text/0001-rfc-process.md @@ -1,13 +1,12 @@ -# GRIN-RFC-0001 Grin RFC Process +# 0001-rfc-process -``` -- Number: GRIN-RFC-0001 -- Title: Grin RFC Process -- Status: Draft -- Authors: joltz (joltz@protonmail.com) - yeastplume (yeastplume@protonmail.com) -- Created : June 21st, 2019 -``` +# THIS RFC IS STILL IN DRAFT MODE + +- Title: rfc-process +- Authors: [joltz](mailto:joltz@protonmail.com), [yeastplume](mailto:yeastplume@protonmail.com), [lehnberg](mailto:daniel.lehnberg@protonmail.com) +- Start date: June 21st, 2019 + +--- # Summary [summary]: #summary @@ -17,9 +16,7 @@ The "RFC" (request for comments) process is intended to provide a consistent and # Motivation [motivation]: #motivation -The previous "ad-hoc" method of adding new features to Grin was suitable for early development, but as Grin and its ecosystem matures it needs a more controlled process to keep development focused, -help provide the community with a reasonable overview of Grin's future plans, and provide a platform for focused discussion of new features. This is a proposal for a structured RFC process, with -the intent being that it will be closely followed as part of Grin's development. +The previous "ad-hoc" method of adding new features to Grin was suitable for early development, but as Grin and its ecosystem matures it needs a more controlled process to keep development focused, help provide the community with a reasonable overview of Grin's future plans, and provide a platform for focused discussion of new features. This is a proposal for a structured RFC process, with the intent being that it will be closely followed as part of Grin's development. # Guide-level explanation [guide-level-explanation]: #guide-level-explanation @@ -56,7 +53,7 @@ submit an RFC first. [reference-level-explanation]: #reference-level-explanation 1. Fork the RFC repo https://github.com/mimblewimble/grin-rfcs -1. Copy `0000-template.md` to `text/0000-my-feature.md` (where +2. Copy `0000-template.md` to `text/0000-my-feature.md` (where 'my-feature' is descriptive. don't assign an RFC number yet). 1. Write the RFC according to the template instructions. 1. Submit a pull request. From b2767698c840e613edb87653ed9d81d457316d7b Mon Sep 17 00:00:00 2001 From: lehnberg Date: Sat, 29 Jun 2019 13:56:41 +0100 Subject: [PATCH 03/13] rework summary section --- text/0001-rfc-process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0001-rfc-process.md b/text/0001-rfc-process.md index 50cf02f..90a045f 100644 --- a/text/0001-rfc-process.md +++ b/text/0001-rfc-process.md @@ -11,7 +11,7 @@ # Summary [summary]: #summary -The "RFC" (request for comments) process is intended to provide a consistent and controlled path for new features to enter the Grin codebase and governance structure. +The "RFC" (request for comments) process is intended to provide a consistent and controlled path for improvements to be made to Grin. # Motivation [motivation]: #motivation From 06f478f756e991fcb7b20a0491e41a1437a1e41b Mon Sep 17 00:00:00 2001 From: lehnberg Date: Sat, 29 Jun 2019 13:58:07 +0100 Subject: [PATCH 04/13] rework motivation section --- text/0001-rfc-process.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/text/0001-rfc-process.md b/text/0001-rfc-process.md index 90a045f..86cebda 100644 --- a/text/0001-rfc-process.md +++ b/text/0001-rfc-process.md @@ -16,7 +16,9 @@ The "RFC" (request for comments) process is intended to provide a consistent and # Motivation [motivation]: #motivation -The previous "ad-hoc" method of adding new features to Grin was suitable for early development, but as Grin and its ecosystem matures it needs a more controlled process to keep development focused, help provide the community with a reasonable overview of Grin's future plans, and provide a platform for focused discussion of new features. This is a proposal for a structured RFC process, with the intent being that it will be closely followed as part of Grin's development. +Many changes, including bug fixes and documentation improvements can be implemented and reviewed via the normal GitHub pull request workflow. + +Some changes though are "substantial", and could benefit from being put through a bit of a design process in order to produce a consensus among Grin community participants and stakeholders. # Guide-level explanation [guide-level-explanation]: #guide-level-explanation From a6a001fd3f0088efc3e6300f3942264ca4e7a4b5 Mon Sep 17 00:00:00 2001 From: lehnberg Date: Sat, 29 Jun 2019 14:06:33 +0100 Subject: [PATCH 05/13] update header hierarchy --- text/0001-rfc-process.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/text/0001-rfc-process.md b/text/0001-rfc-process.md index 86cebda..c50c5ca 100644 --- a/text/0001-rfc-process.md +++ b/text/0001-rfc-process.md @@ -8,25 +8,25 @@ --- -# Summary +## Summary [summary]: #summary The "RFC" (request for comments) process is intended to provide a consistent and controlled path for improvements to be made to Grin. -# Motivation +## Motivation [motivation]: #motivation Many changes, including bug fixes and documentation improvements can be implemented and reviewed via the normal GitHub pull request workflow. Some changes though are "substantial", and could benefit from being put through a bit of a design process in order to produce a consensus among Grin community participants and stakeholders. -# Guide-level explanation +## Guide-level explanation [guide-level-explanation]: #guide-level-explanation To add a major feature to Grin or make a change to Grin's governance structure, one must first get the RFC merged into the RFC repo as a markdown file. At that point the RFC is 'active' and may be implemented with the goal of eventual inclusion into the Grin codebase or Governance procedures. -## When you need to follow this process +### When you need to follow this process You need to follow this process if you intend to make "substantial" changes to the Grin codebase or governance process. What constitutes a "substantial" @@ -51,7 +51,7 @@ through the RFC process, it may be closed with a polite request to submit an RFC first. -# Reference-level explanation +## Reference-level explanation [reference-level-explanation]: #reference-level-explanation 1. Fork the RFC repo https://github.com/mimblewimble/grin-rfcs @@ -83,7 +83,7 @@ be merged; it does mean that in principle all the major stakeholders have agreed Modifications to Accepted RFC's can be done in followup PR's. An RFC that makes it through the entire process to implementation is considered 'Active'; an RFC that fails after becoming active is 'Inactive' and is relabelled as such. -# Drawbacks +## Drawbacks [drawbacks]: #drawbacks * May not be formal enough @@ -91,7 +91,7 @@ Modifications to Accepted RFC's can be done in followup PR's. An RFC that makes * May slow down needed features * May allow some features to be included too quickly -# Rationale and alternatives +## Rationale and alternatives [rationale-and-alternatives]: #rationale-and-alternatives Alternatively retain the current informal RFC process. The proposed RFC process is designed to improve over the informal process in the following ways: @@ -105,14 +105,14 @@ understand why new features are being merged As an alternative, we could adopt an even stricter RFC process than the one proposed here. If desired, we should likely look to Bitcoin's BIP or Python's PEP process for inspiration. -# Prior art +## Prior art [prior-art]: #prior-art Most decentralized cryptocurrency projects have adopted an RFC-like process to manage adding new features. Bitcoin uses BIPs which are an adaptation of Python's PEPs. These processes are similar to the Rust RFC process which has had success in the Rust community as well as in other cryptocurrency projects like Peercoin. -# Unresolved questions +## Unresolved questions [unresolved-questions]: #unresolved-questions 1. Does this RFC strike a favorable balance between formality and agility? @@ -120,7 +120,7 @@ Bitcoin uses BIPs which are an adaptation of Python's PEPs. These processes are 3. Should we retain rejected RFCs in the archive? (YP: I think yes, so it's apparent to new submitters if their idea has already been considered and rejected) 4. Should RFC issues be opened in their respective repos (wallet RFC in wallet repo etc.) or should they all be opened in grin-pm repo? (YP: I think 1 repository dedicated to Grin RFCs is fine) -# Future possibilities +## Future possibilities [future-possibilities]: #future-possibilities This proposal was initially based on an RFC process for codebase development. @@ -132,7 +132,7 @@ Just as it is important to hone the language to support the development process and life-cycle it is also important to sharpen the language to support governance processes and life-cycles for the Grin ecosystem. -# References +## References [references]: #references https://github.com/rust-lang/rfcs From a1574daa4748eae8d8eaa4f80dac9c7b36228111 Mon Sep 17 00:00:00 2001 From: lehnberg Date: Sat, 29 Jun 2019 14:15:56 +0100 Subject: [PATCH 06/13] break out process meta rules --- text/0001-rfc-process.md | 37 ++++++++++++++++--------------------- 1 file changed, 16 insertions(+), 21 deletions(-) diff --git a/text/0001-rfc-process.md b/text/0001-rfc-process.md index c50c5ca..f7658a8 100644 --- a/text/0001-rfc-process.md +++ b/text/0001-rfc-process.md @@ -20,40 +20,35 @@ Many changes, including bug fixes and documentation improvements can be implemen Some changes though are "substantial", and could benefit from being put through a bit of a design process in order to produce a consensus among Grin community participants and stakeholders. -## Guide-level explanation -[guide-level-explanation]: #guide-level-explanation +## When this process should be followed +[when-this-process-should-be-followed]: #when-this-process-should-be-followed -To add a major feature to Grin or make a change to Grin's governance structure, one must first get the RFC merged into the RFC repo as a markdown file. -At that point the RFC is 'active' and may be implemented with the goal of eventual inclusion into the Grin codebase or Governance procedures. - -### When you need to follow this process - -You need to follow this process if you intend to make "substantial" -changes to the Grin codebase or governance process. What constitutes a "substantial" -change may evolve based on community norms, but may include the following. +You need to follow this process if you intend to make "substantial" changes to the Grin codebase or governance process. What constitutes a "substantial" change may evolve based on community norms and individual definitions of sub-teams, but may include the following. - Any semantic or syntactic change to the wallet, node, miner or underlying crypto libraries that is not a bugfix. - - Major changes in ecosystem content such as the docs, site or explorer + - Major changes in ecosystem content such as the docs, site or explorer. - Removing Grin features, including those that are feature-gated. Some changes do not require an RFC: - - Rephrasing, reorganizing, refactoring, or changes that are not - visible to Grin's users. - - Additions that strictly improve objective, numerical quality -criteria (warning removal, speedup, better platform coverage, more -parallelism, trap more errors, etc.) - - Additions only likely to be _noticed by_ other developers-of-grin, -invisible to users-of-grin. + - Rephrasing, reorganizing, refactoring, or changes that are not visible to Grin's users. + - Additions that strictly improve objective, numerical quality criteria (warning removal, speedup, better platform coverage, more parallelism, trap more errors, etc.) + - Additions only likely to be _noticed by_ other developers-of-grin, invisible to users-of-grin. + +If you submit a pull request to implement a new feature without going through the RFC process, it may be closed with a polite request to submit an RFC first. -If you submit a pull request to implement a new feature without going -through the RFC process, it may be closed with a polite request to -submit an RFC first. +### Sub-team specific guidelines + +_To be added here once available._ ## Reference-level explanation [reference-level-explanation]: #reference-level-explanation +To add a major feature to Grin or make a change to Grin's governance structure, one must first get the RFC merged into the RFC repo as a markdown file. +At that point the RFC is 'active' and may be implemented with the goal of eventual inclusion into the Grin codebase or Governance procedures. + + 1. Fork the RFC repo https://github.com/mimblewimble/grin-rfcs 2. Copy `0000-template.md` to `text/0000-my-feature.md` (where 'my-feature' is descriptive. don't assign an RFC number yet). From 8c3e443331e1714daba10123e8c496f99d9f9aec Mon Sep 17 00:00:00 2001 From: lehnberg Date: Sat, 29 Jun 2019 14:22:25 +0100 Subject: [PATCH 07/13] add before RFC section --- text/0001-rfc-process.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/text/0001-rfc-process.md b/text/0001-rfc-process.md index f7658a8..b4ab73f 100644 --- a/text/0001-rfc-process.md +++ b/text/0001-rfc-process.md @@ -41,6 +41,18 @@ If you submit a pull request to implement a new feature without going through th _To be added here once available._ +## Before creating an RFC +[Before creating an RFC]: #before-creating-an-rfc + +A hastily-proposed RFC can hurt its chances of acceptance. Low quality proposals, proposals for previously-rejected features, or those that don't fit into the near-term roadmap, may be quickly rejected, which can be demotivating for the unprepared contributor. Laying some groundwork ahead of the RFC can make the process smoother. + +Although there is no single way to prepare for submitting an RFC, it is generally a good idea to pursue feedback from other project contributors +beforehand, to ascertain that the RFC may be desirable; having a consistent impact on the project requires concerted effort toward consensus-building. + +Ways to prepare and pave the way for writing and submitting an RFC include discussing the topic or posting "pre-RFCs" to our [forum](https://grin-forum.org) for feedback. + +As a rule of thumb, receiving encouraging feedback from long-standing project +contributors, and particularly members of the relevant sub-team (if applicable) is a good indication that the RFC is worth pursuing. ## Reference-level explanation [reference-level-explanation]: #reference-level-explanation From e7ea4d7904df55b9a213675ebe75590a90b206eb Mon Sep 17 00:00:00 2001 From: lehnberg Date: Sat, 29 Jun 2019 15:15:07 +0100 Subject: [PATCH 08/13] rework process section and remaining parts of document --- text/0001-rfc-process.md | 87 ++++++++++++++++++++++++---------------- 1 file changed, 52 insertions(+), 35 deletions(-) diff --git a/text/0001-rfc-process.md b/text/0001-rfc-process.md index b4ab73f..0725e60 100644 --- a/text/0001-rfc-process.md +++ b/text/0001-rfc-process.md @@ -54,41 +54,62 @@ Ways to prepare and pave the way for writing and submitting an RFC include discu As a rule of thumb, receiving encouraging feedback from long-standing project contributors, and particularly members of the relevant sub-team (if applicable) is a good indication that the RFC is worth pursuing. -## Reference-level explanation -[reference-level-explanation]: #reference-level-explanation +## Process description +[process-description]: #process-description -To add a major feature to Grin or make a change to Grin's governance structure, one must first get the RFC merged into the RFC repo as a markdown file. -At that point the RFC is 'active' and may be implemented with the goal of eventual inclusion into the Grin codebase or Governance procedures. +In order to make a "substantial" change to Grin, one must first get an RFC merged into the RFC repo as a markdown file. At that point the RFC is 'active' and may be implemented with the goal of eventual inclusion into Grin. +![process state diagram](assets/../../assets/0001-state-diagram.svg) -1. Fork the RFC repo https://github.com/mimblewimble/grin-rfcs -2. Copy `0000-template.md` to `text/0000-my-feature.md` (where +### Stages in detail + +#### Submission +* Fork the RFC repo https://github.com/mimblewimble/grin-rfcs +* Copy `0000-template.md` to `text/0000-my-feature.md` (where 'my-feature' is descriptive. don't assign an RFC number yet). -1. Write the RFC according to the template instructions. -1. Submit a pull request. -1. The relevant team (sub-team or core) will perform an initial review of the PR, and decide whether the RFC should be merged into the repository as a Draft PR. +* If you include any assets, do so as `/assets/0000-asset-description.xxx` +* Write the RFC according to the template instructions. +* Submit a pull request. As a pull request the RFC will receive design feedback from the larger community, and the author should be prepared to revise it in response. + +#### Draft + +* Each pull request will be labeled with the most relevant sub-team, which will lead to it being triaged by that team and is assigned a shepherd from this team. The shepherd ensures the RFC progresses through the process and that a decision is reached, but they themselves do not make this decision. +* As the author, you build consensus and integrate feedback. RFCs that have broad support are much more likely to make progress than those that don't receive any comments. They are encouraged to reach out to the RFC shepherd in particular to get help identifying stakeholders and obstacles. +* The relevant sub-team discuss the RFC pull request, as much as possible in the comment thread of the pull request itself. Offline discussion will be summarized on the pull request comment thread. +* RFCs rarely go through this process unchanged, especially as alternatives and drawbacks are shown. As an author uou can make edits, big and small, to the RFC to clarify or change the design,but make changes as new commits to the pull request, and leave a comment on the pull request explaining your changes. Specifically, do not squash or rebase commits after they are visible on the pull request. -Once the PR is accepted into the repository, it will be given 'Draft' status. This does not mean the RFC has been accepted, only that is has been -selected by the community for further discussion, feedback and refinement. +#### Final Comment Period (FCP) -At this point, whoever merges the PR should: -* Assign an id, using the PR number of the RFC pull request. (If the RFC has multiple pull requests associated with it, choose one PR number, - preferably the minimal one.) -* Rename the file to `grin-rfc-xxxx.md` and merge into `/text`. (where -xxxx is the RFC ID) -* Fill in the remaining metadata in the RFC header. -* Add an entry in the RFC List in `README.md`, with a status of Draft. +* At some point, a member of the sub-team will propose a "motion for final comment period" (FCP), along with a *disposition* for the RFC (merge, close, or postpone). +* This step is taken when enough of the tradeoffs have been discussed that the sub-team is in a position to make a decision. That does not require consensus amongst all participants in the RFC thread (which is usually impossible). However, the argument supporting the disposition on the RFC needs to have already been clearly articulated, and there should not be a strong consensus *against* that position outside of the sub-team. Sub-team members use their best judgment in taking this step, and the FCP itself ensures there is ample time and notification for stakeholders to push back if it is made prematurely. +* For RFCs with lengthy discussion, the motion to FCP is usually preceded by a *summary comment* trying to lay out the current state of the discussion and major tradeoffs/points of disagreement. +* The FCP lasts ten calendar days, so that it is open for at least 5 business days. It is also advertised widely (i.e. in [Grin News](https://grinnews.substack.com)). This way all stakeholders have a chance to lodge any final objections before a decision is reached. +* In most cases, the FCP period is quiet, and the RFC is either merged or closed. However, sometimes substantial new arguments or ideas are raised, the FCP is canceled, and the RFC goes back into draft mode. -When the RFC is in 'Draft' stage, it is important to refine details, build consensus among the community for the RFC and integrate useful -feedback. RFCs that have broad support are much more likely to make progress than those that don't receive any comments. +#### Active -Eventually, the relevant community organization will either accept the RFC by changing its status to 'Accepted' or reject it by setting it to 'Rejected'. +* As FCP concludes and there are no objections to accepting the RFC, it gets merged into `/grin-rfcs` and becomes "active". +* Before merging, the shepherd: + * updates the RFC to give it an RFC number (which is the same as the number of the initial Pull Request) + * Renames the markdown file accordingly + * If a tracking issue on the repo affected by the RFC has created, it is linked to in the header. +* Once active, the authors may then implement it and submit the feature as a pull request to the relevant repo. +* Being "active" is not a rubber stamp, and in particular still does not mean the feature will ultimately be merged; it does mean that in principle all the major stakeholders have agreed to the feature and are amenable to merging it. +* Furthermore, the fact that a given RFC has been accepted and is "active" implies nothing about what priority is assigned to its implementation, nor does it imply anything about whether a developer has been assigned the task of implementing the feature. +* While it is not necessary that the author of the RFC also write the implementation, it is by far the most effective way to see an RFC through to completion: authors should not expect that other project contributors will take on responsibility for implementing their accepted feature. +* Modifications to "active" RFCs can be done in follow-up pull requests. We strive to write each RFC in a manner that it will reflect the final design of the feature; but the nature of the process means that we cannot expect every merged RFC to actually reflect what the end result will be at the time of implementation. +* In general, once accepted, RFCs should not be substantially changed. Only very minor changes should be submitted as amendments. More substantial changes should be new RFCs, with a note added to the original RFC. Exactly what counts as a "very minor change" is up to the sub-team to decide; check sub-team specific guidelines for more details. -Once an RFC becomes active then authors may implement it and submit the feature as a pull request to the relevant Grin repo. An 'Accepted' status is not a rubber stamp, and in particular still does not mean the feature will ultimately -be merged; it does mean that in principle all the major stakeholders have agreed to the feature and are amenable to merging it. +#### Postponed -Modifications to Accepted RFC's can be done in followup PR's. An RFC that makes it through the entire process to implementation is considered -'Active'; an RFC that fails after becoming active is 'Inactive' and is relabelled as such. +* Some RFC pull requests are tagged with the "postponed" label when they are closed (as part of the rejection process). +* An RFC closed with "postponed" is marked as such because we want neither to think about evaluating the proposal nor about implementing the described feature until some time in the future, and we believe that we can afford to wait until then to do so. +* Postponed pull requests may be re-opened when the time is right. We don't have any formal process for that, you should ask members of the relevant sub-team. +* Usually an RFC pull request marked as "postponed" has already passed an informal first round of evaluation, namely the round of "do we think we would ever possibly consider making this change, as outlined in the RFC pull request, or some semi-obvious variation of it." (When the answer to the latter question is "no", then the appropriate response is to close the RFC, not postpone it.) + +#### Closed + +* At any time before merging, the RFC can be closed if there is no support in the community for the proposal. ## Drawbacks [drawbacks]: #drawbacks @@ -110,11 +131,13 @@ Alternatively retain the current informal RFC process. The proposed RFC process understand why new features are being merged * Assist the Grin community with feature and release planning. -As an alternative, we could adopt an even stricter RFC process than the one proposed here. If desired, we should likely look to Bitcoin's BIP or Python's PEP process for inspiration. +As an alternative, we could adopt an even stricter RFC process than the one proposed here. We could for example look to Bitcoin's BIP or Python's PEP process for inspiration. ## Prior art [prior-art]: #prior-art +This process draws inspiration _extensively_ from Rust's RFC process, where much credit for the process is due. + Most decentralized cryptocurrency projects have adopted an RFC-like process to manage adding new features. Bitcoin uses BIPs which are an adaptation of Python's PEPs. These processes are similar to the Rust RFC process which has had success in the Rust community as well as in other cryptocurrency projects like Peercoin. @@ -123,21 +146,15 @@ Bitcoin uses BIPs which are an adaptation of Python's PEPs. These processes are [unresolved-questions]: #unresolved-questions 1. Does this RFC strike a favorable balance between formality and agility? -2. Does this RFC successfully address the aforementioned issues with the current informal process? -3. Should we retain rejected RFCs in the archive? (YP: I think yes, so it's apparent to new submitters if their idea has already been considered and rejected) -4. Should RFC issues be opened in their respective repos (wallet RFC in wallet repo etc.) or should they all be opened in grin-pm repo? (YP: I think 1 repository dedicated to Grin RFCs is fine) +2. Does this RFC address the issues with the current informal process adequately? ## Future possibilities [future-possibilities]: #future-possibilities -This proposal was initially based on an RFC process for codebase development. -As the process evolves it will have a larger impact in the governance of Grin. -This is a relatively new area of exploration as governance processes can have +This proposal was initially based on an RFC process for codebase development. As the process evolves it will have a larger impact in the governance of Grin. This is a relatively new area of exploration as governance processes can have wide ranging impacts on the ecosystem as a whole. -Just as it is important to hone the language to support the development process -and life-cycle it is also important to sharpen the language to support governance -processes and life-cycles for the Grin ecosystem. +Just as it is important to hone the language to support the development process and life-cycle it is also important to sharpen the language to support governance processes and life-cycles for the Grin ecosystem. ## References [references]: #references From f55b36cabee69e0fb413c2634abc89e1541aa2df Mon Sep 17 00:00:00 2001 From: lehnberg Date: Sat, 29 Jun 2019 15:17:36 +0100 Subject: [PATCH 09/13] tweak UML --- assets/0001-state-diagram.puml | 3 ++- assets/0001-state-diagram.svg | 5 +++-- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/assets/0001-state-diagram.puml b/assets/0001-state-diagram.puml index 592f2a2..17c8bc1 100644 --- a/assets/0001-state-diagram.puml +++ b/assets/0001-state-diagram.puml @@ -9,10 +9,11 @@ draft : * tag sub-team draft : * assign shepherd draft : * feedback from community draft : * iterate on proposal -draft -right-> FCP : [shepherd]\nMotion to enter\nFinal Comment Period +draft -right-> FCP : [shepherd]\nEnter Final Comment Period FCP: * include disposition to merge/close/postpone FCP: * final feedback from community FCP: * final touches on proposal +FCP -left-> draft : [shepherd]\nCancel FCP } state close_join <> diff --git a/assets/0001-state-diagram.svg b/assets/0001-state-diagram.svg index c6cde1a..7649a13 100644 --- a/assets/0001-state-diagram.svg +++ b/assets/0001-state-diagram.svg @@ -1,4 +1,4 @@ -PR is OpenPR is ClosedPR is Mergeddrafttag sub-teamassign shepherdfeedback from communityiterate on proposalFCPinclude disposition to merge/close/postponefinal feedback from communityfinal touches on proposalclosedpostponedactiveassign RFC numbercreate tracking issue in relevant repomake note if superseded by a new RFC[author]Submit a PR to /grin-rfcs[shepherd]Motion to enterFinal Comment PeriodClose RFCPostpone RFC[shepherd]Merge RFCMinor changesthrough new PRRe-open PRPR is OpenPR is ClosedPR is Mergeddrafttag sub-teamassign shepherdfeedback from communityiterate on proposalFCPinclude disposition to merge/close/postponefinal feedback from communityfinal touches on proposalclosedpostponedactiveassign RFC numbercreate tracking issue in relevant repomake note if superseded by a new RFC[author]Submit a PR to /grin-rfcs[shepherd]Enter Final Comment Period[shepherd]Cancel FCPClose RFCPostpone RFC[shepherd]Merge RFCMinor changesthrough new PRRe-open PR