RChain Improvement Process (RCHIP Process) - Draft

[SteveHenley]

This document seeks to propose a process by which updates to the RChain blockchain are defined, approved, prioritized and released. Link

Tooling: The RChain feature backlog is captured in Jira at: http://rchain.atlassian.net at: https://rchain.atlassian.net/secure/RapidBoard.jspa?projectKey=RIP&rapidView=19&view=planning.nodetail The RChain Improvement Proposals are captured in Confluence at: RChain Improvement Proposals

[dckc]

@9rb, @SteveHenley writes in https://github.com/rchain/rchip-proposals/issues/11#issuecomment-632101969

There is currently no editorial committee nor approval committee. Due to the limited manpower the tech governance working group decided to go with lighter version of the RChip. Rao can better explain what this lighter version is. @dckc

So please do explain.

[dckc]

Oh... and again... as to "decided", please cite the decision record. When was the decision made? Who was present? What gave them mandate to decide on my behalf?

[9rb]

@9rb, @SteveHenley writes in #11 (comment)

There is currently no editorial committee nor approval committee. Due to the limited manpower the tech governance working group decided to go with lighter version of the RChip. Rao can better explain what this lighter version is. @dckc

So please do explain.

The lighter version currently is (a) for simple changes, to create a Jira ticket and capture all discussions and designs in there by all parties including proposers and developers vs. separate committees and an elongated approval process. (b) for larger changes or those with a more significant impact, create RCHIP proposals and outline concerns and methods of resolving those (c) Both (a) and (b) are open to 24x7 review and comment by the community and discussed in the weekly TechGovernance meetings which are published to the community.

The intention is to achieve maximum transparency and deliberation while enabling quick resolution such that the proposed improvements can be implemented quickly.

[dckc]

OK, this high-trust process sounds reasonable for the current situation with a small-ish community.

Here's hoping we get more checks and balances in place before we have a difficult decision to make. Because this lightweight process is more or less indistinguishable from: the coop president (and his delegates) decide, and he / they may choose to take advice from the community.

For reference:

• Log: Tech Governance - Google Docs

[9rb]

@dckc Agreed. Note that what's described above is only the 'RChip lite' process. The full process is continuously evolving, we need more expertise and resources on that. It would be great if you can participate in the Thursday sessions. If that's inconvenient, I would much appreciate it if you can add any recommended processes and/or links to best practices either to the draft process or the log. Currently we're trying to model after the EIP (Ethereum) and SIP (Scala) communities but perhaps there're others to look at, at least for specific issues / considerations? I would definitely like to look at more blockchain best practices that are applicable to us.

[dckc]

The main recommendation I have is that the President and/or Board formally delegate the responsibility to a fair process. But maybe not any time soon... perhaps the membership is content to let technical direction rest at the sole discretion of the President.

[dckc]

I actually haven't studied the EIP process... let's see... EIP 1 ...

non-core:

[ WIP ] -> [ DRAFT ] -> [ LAST CALL ] -> [ FINAL ]

core:

[ IDEA ] -> [ DRAFT ] -> [ LAST CALL ] -> [ ACCEPTED ] -> [ FINAL ]

And "Draft – If agreeable, EIP editor will assign the EIP a number" and "Last Call – If agreeable, the EIP editor will assign Last Call status". So the EIP editor alone has those capabilities. EIP-1 enumerates the current editors but doesn't specify a process for adding nor removing them.

The core devs alone have the capability to take a core EIP to final. Who are they? How does one become a core dev?

Who Can Attend: Low-level protocol developers, client developers, and core Ethereum researchers are invited to attend the meetings.

The meetings are independent of any organization. However, Hudson Jameson is a contractor for the Ethereum Foundation

It doesn't look like (other) core devs are required to state / disclose affiliations. W3C ran into a problem there (I can tell you the story) and now requires affiliations be disclosed to avoid conflict of interest.

I see various requirements that proposals come with code. So the EIP process seems to come down to "those who write the code make the rules." That's more fair when we elaborate to "those who write the code for popular software make the rules"; i.e. non-devs are represented indirectly by their choice of which software they use. But it's still questionable to let techs make all the rules.

[dckc]

Now let's look at the capabilities in the Scala SIP process...

The SIP committee meets monthly to discuss, and eventually vote upon, proposals.

Within two weeks after your submission of the pre-SIP to the mailing list, the Process Lead will intervene and advise you whether your idea can be submitted as a SIP or needs more work.

The Process Lead is the responsible of the smooth running of SIPs and SLIPs. He or she appoints the committee members

For a SIP to be accepted, the following ... requirements must be met: ... Martin Odersky does not veto it.

The current Process Lead is: Darja Jovanovic (@darjutak), Scala Center

In both EIP and SIP, persons are identified by their github username. So github (i.e. Microsoft) has a very trusted role as well.

[dckc]

... But it's still questionable to let techs make all the rules.

At W3C, some of the most important work was in Web Accessibility and Technology and Society, e.g. patent policy. We definitely wouldn't have achieved that if we left everything up to those who wrote code.

[dckc]

... perhaps there're others to look at

Apache Corporate Governance and especially The Apache Way is the main other one I would look at.

[dckc]

https://github.com/rchain/rchip-proposals/issues/11 is called RCHIP 1. That seems confusing.

If you want to have a number series that doesn't match the issue numbers, I recommend using files in a directory, where the numeric part of the filename is chosen by the RCHIP editor when they merge a PR to take the RCHIP to "stage 1".

But simpler is to just use github issue numbers.

There's a risk that people will act like "RCHIP 8738" is a standard when it's just a hair-brained idea they threw into the issues list. That's when it's time to switch to the heavier files-in-a-directory approach.

[SteveHenley]

11 is called RCHIP 1. That seems confusing.

If you want to have a number series that doesn't match the issue numbers, I recommend using files in a directory, where the numeric part of the filename is chosen by the RCHIP editor when they merge a PR to take the RCHIP to "stage 1".

But simpler is to just use github issue numbers.

There's a risk that people will act like "RCHIP 8738" is a standard when it's just a hair-brained idea they threw into the issues list. That's when it's time to switch to the heavier files-in-a-directory approach.

The goal of the RCHIP numbering system is to have consecutive numbers. By using the github issue numbers there will be gaps in the numbering system. These number gap will raise concerns that some RCHIPS are missing.

I would like to get a better understanding of the files in a directory approach. Other than github issues can this still be done in github? How can I get a better understanding of this?

[dckc]

...

The goal of the RCHIP numbering system is to have consecutive numbers. By using the github issue numbers there will be gaps in the numbering system.

Really? I'm pretty sure github numbers issues consecutively.

[SteveHenley]

Yes, github issues are numbered consecutively. However, not all RCHIP issues opened will become RCHIPs. For example, if nine RCHIP issues are open creating issues 155 -163, but only issues 155, 160 and 163 become RCHIPS. Then the question is asked, " What happened to RCHIPS 156, 157, 158, 159, 161, 162". The answer is that although these issues were opened they did not, for what ever reason, get approved as official RCHIPS.

If we have a RCHIP numbering process that is separate from the github issue number that is auto-generated then we will have consecutive numbers (number with no gaps). As a result, we will not have to address concerns regarding non-consecutive numbers, gaps or in other word - missing RCHIPs.

[dckc]

Yes, github issues are numbered consecutively. However, not all RCHIP issues opened will become RCHIPs.

That's one possibility; as I say, it's not the easiest one.

It's easier if we just say: all issues in this repo are RCHIPs, but not all RCHIPs get past stage 0.

[tgrospic]

@dckc numbers are shared between issues and PRs. My initial idea was also to make every issue as RCHIP so it can be more easily referenced. But after discussion I'm now more for consecutive numbers and structure similar to Scala SIPs. https://github.com/scala/docs.scala-lang/tree/master/_sips

[dckc]

So we're already past the most lightweight option? That seems like more work than it's worth, at this point. But I guess I'm not the one doing the work, so whatever. Yes, there's plenty of precedent for the files-in-a-directory approach.

[tgrospic]

@dckc can you please clarify on what work you mean. I'm probably missing something.

My intention is to add files with final versions of RCHIPs I'm working on. It can also serve as an example for future proposals. Any suggestions are welcome how to make it better.

I noticed on block merge proposal, I mixed together changes specific to RNode Scala implementation. I'll try to keep this things separate with links to tickets or PRs on rchain/rchain repository.

[dckc]

The work is managing files in a directory: training people to submit PRs, cleaning them up, assigning numbers, etc.

The alternative is to just use issues (and labels) for the whole RCHIP process, at least for a while. Let the 1st comment be the body of the proposal.

[SteveHenley]

The tech governance work group attendees discussed the governance of the group at length at our recent Thursday meeting. The main take away from the discussion is that tech governance is a working group and not a committee. The objective of a working group is to get work done. The standards of governance for this group will revolve around its status as a working group and not that of a committee. To this end, the group will simplify governance so that it does not get bogged down with procedure. With respect to RCHIPS approvals the group will do the following.

**1. All RCHIP issues are deemed approved unless there is a conflict/ breaking change or a financial requirement for the issue to move forward. Assuming that the RCHIP issue meets all editorial compliance.

2. Consensus is needed before merging breaking / conflicting code changes to master branch. Ideally the process of raising issues, concerns and objections should precede such consensus.**

It is envisioned that as the RChain platform grows there will be a point at which the original RCHIPS governance model will be resurrected and implemented. For instance, the original plan dictated the creation of an Editorial Committee and Approval Committee. RChain Improvement Process (RCHIP Process) - Draft

[dckc]

I'm not aware of any relevant differences between committees and working groups. The obligation to do governance is right there in the name regardless. If you consider having clear decision records "getting bogged down in procedure" then I don't know what service you're providing to the community.