Help us design Grin's RFC process!

Governance
1

What’s this about?

In today’s governance meeting, it was agreed that we’d proceed in the spirit and direction that was outlined in Proposal: Grin Governance Iteration.

As @condiosluzverde suggested, let’s see if we can first jointly document an RFC process and a template for the structure of RFCs, and then publish that as RFC-0.

Once that’s in place, we can submit an RFC-1 that would cover an initial proposal for sub-teams.

Who can participate?

Anyone who wants to! Get involved here in thread.

When should it be finished?

Draft ready for wider community review: Tue Jun 25 2019
Discussion and hopefully adoption: Next Governance meeting Tue July 2nd 2019

How do we work?

However you feel like. One way to go could be to write Github gists in markdown and post here, and keep the forum posts for meta-discussion about the gist proposals to make it easy to digest. And then once there’s something that feels “stable”, we can submit an issue on /grin-pm and work on it there or something. Then this could then be PR’d into an RFC repo at some point.

What are some resources for inspiration?

Rust’s RFC process: https://github.com/rust-lang/rfcs
Bitcoin BIP process: https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki
(feel free to add more!)

4 Likes
2

  1. everything should be explicitly non-binding

  2. The comment period for changes should be early and often, but not long; expect for promises such as the pow design.

  3. input from randoms that only comes from randoms should be quietly ignored.

3

Instead of reinventing the wheel let’s see if it is possible to start with the work the Rust community has done. I’d like to propose the Rust RFC model for the Grin community with some minor changes to explore its viability.

Please review the documents and if possible make an argument for why the Rust process would not work well for the Grin community without major adjustments (or if the BIP/PEP process would work better with only minor adjustments).

If no one has major objections to the Rust RFC process, we can use the documents below as a starting point.

Example RFC Process Document

Objectives for this document:

  • Introduce the RFC process for Grin
  • Describe when to follow the RFC process
  • Describe the RFC process
  • Describe RFC life-cycle
  • Describe process for reviewing, implementing and postponing RFCs
  • Describe general philosophy and intention motivating the state of the RFC process

TODO:

  • Community review, feedback and iteration

Further considerations:

  • Are there good arguments for not using the Rust RFC model? Do they also apply to BIP/PEP?

Example RFC Template

Objectives for this document:

  • Provide a template to guide the structure of future RFCs
  • Offer a structure generic enough to apply to all substantial changes to Grin
  • Ensure the structure guides authors to providing enough specifics for the teams to fully understand and implement features suggested in RFCs
  • Ensure the RFC structure will allow Grin community members to clearly understand the contents proposed and their impact
  • Encourage engagement, deeper thought and further discussion about unforeseen impacts of the RFC in all aspects of the Grin ecosystem

TODO:

  • Community review, feedback and iteration

Example RFC-0000: RFC Process

Objectives for this document:

  • Formalize the RFC process in the RFC template structure
  • Clarify and make explicit the details in the RFC process document

TODO:

  • Community review, feedback and iteration

RFC-0001: Grin Governance

TBD

Generic objectives for this document (full details found here Proposal: Grin Governance Iteration):

  • Expand and make more explicit Grin’s governance structure
  • Improve transparency around Grin’s governance structure
  • Encourage more participation
  • Create subteams that focus on specific domains to assist core team
  • Describe processes for core team and subteams including formation, decision making, roles and responsibilities
  • Formalize these details in the RFC template structure

Unanswered Questions

  • 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?

Important Questions

Currently in Rust’s RFC process, in the “Reviewing RFCs” section, it gives final decision making power to merge or close an RFC pull request to subteams.

  • Should the core team get veto power over subteam decisions?
  • Should subteams have an ability to collectively veto core team decisions?
  • What language can we use to describe a process for agreement if most cases for dispute are best handled in a case by case basis?

The answers to these questions will have larger implications when we begin to explore the construction of the actual governance RFC.

3 Likes
4

@joltz Thanks for putting these together, and I think these are a really good start, to the point where I wouldn’t be against using them more or less as is to get it going.

@lehnberg I think it may be better to start using the repository for this as opposed to back and forth on the forums. To get started could we perhaps get our PR repo set up with the guidelines, the outline of RFC 0 and 1 and comment/apply further PRs to them there?

1 Like
5

@joltz nice job on getting us started, this is great.

FYI others that @yeastplume has created a grin-rfcs repo now: https://github.com/mimblewimble/grin-rfcs

Further iterations and discussions can also happen there through pull requests.

I also noticed that there was a proposal by Rust Core to iterate on their RFC process, blog post and discussion is interesting to read. While some things (like a separate repo for each RFC) might be an overkill for us, other things (like different stages in an RFC lifecycle) might make sense for us to think about now already.

6

Just posted a proposal to further refine the proposed process: https://github.com/mimblewimble/grin-rfcs/pull/9