CHIP Guidelines

With regards to “Where should chips be hosted so people can go to one place and read them”, I see no reason why the specification websites (which are more or less clones of each other) couldnt also host CHIP information including a link to where the chip discussion is taking place. More often than not i would assume the actual discussion for any given chip would take place on the authors github/gitlab for ease of editing and commenting on the document.

2 Likes

I see no reason why the specification websites (which are more or less clones of each other) couldnt also host CHIP information including a link to where the chip discussion is taking place.

Moreover, every CHIP should probably include a link to the main discussion location of itself.

1 Like

I added this as a section to the template i made based off of IMU’s proposal here: Trim the existing proposal into an easy to digest template (!1) · Merge Requests · imaginaryusername / Cash Improvement Proposals · GitLab

1 Like

Discourse allows wiki posts. Here you can find a good description of how it works and the associated properties.

At the time of this forum creation, we ran some tests and it seemed to work as expected, but we preferred to leave it for when the forum grew in users and participation.
So at the moment, wiki post functionality is not 100% activated for all trust levels, but it can be with a couple of clicks.

Perhaps the time to activate it has come.

By combining wiki posts (with their revision history) and Discourse tagging system we could offer something practical while robust for CHIPs and related discussions.

Looking forward your comments.

1 Like

This is a link to gitlab where i have put the chip guidelines and template which should at time of writing be inclusive of feedback from everyone so far. it includes a number of additional required fields put forth by IMU, specifically outlines the CHIP types, and adds a version field to the header as suggested by FT. I have also added field where the author can link to the place where relevant discussion about the CHIP is taking place.

So I’m going to assume “best practices” would be to maintain CHIPs in a relevant git repo and link to discussion threads here on bcr. That seem like the way to go? Right now I’m trying to make the time to put the multiple OP_RETURN proposal that I have here into a well formatted CHIP. Unless there’s an objection then this is how I’ll proceed.

2 Likes

That is what most people are doing and it seems to be working fine for now. Please remember to put a link to your discussion in the CHIP, and link to the CHIP in the discussion so people can find each other.

2 Likes

That certainly has my support!

We have a general consensus on the principle already, which makes it easier. Now people that are interested in the exact details of the change should be able to refer to a CHIP.
The aim is that you can link people on reddit, on telegram and naturally in private emails to your CHIP. They can find out what the exact thing is about and follow the link from your CHIP to bcr if they want to know more or simply want to comment.

The ultimate goal is to get a lot of people to support the change, as encoded in the CHIP, and we can find a time point where it will become activated.

Please reach out if you want any help writing the CHIP. I wrote some, as did others.

2 Likes

I have received some feedback from @Leandrodimarco on the CHIP Guidelines document I created.

He has requested the addition of an Informational CHIP type which serves the same purpose as an Informational BIP. the MR for this change can be found here:

There was also a second request to implement BIP 123 Layers into CHIPs. The Layers field would be required for Technical CHIPs. The MR for this change can be found here:

I would like for people to share their opinions on these requested changes.

What is the mechanism by which a CHIP moves from DRAFT to APPROVED status?

What is the mechanism by which a CHIP moves from DRAFT to APPROVED status?

It’s a good question.

I consider the ‘Status’ fields in this proposal comment by Leandro which do not include an ‘Approved’ status, but rather a ‘Final/Active’ status which is more descriptive. It seems to me they could all be applied by the CHIP owner(s) after consultation with the stakeholders.

I would understand the ‘Active’ to mean ‘Deployed’.

image

2 Likes

This is exactly one of the reasons for my recommendation, which in fact is not mine but is BIP 0002 proposal.

I would say that the term/concept of Proposed has a greater appeal for Bitcoin Cash than Approved.

If the question is how a CHIP goes from Draft to Proposed, I will go with what is specified in the same BIP 0002:

A BIP may only change status from Draft (or Rejected) to Proposed, when the author deems it is complete, has a working implementation (where applicable), and has community plans to progress it to the Final status.

As a side note, it’s worth mentioning that BIP 0001 (replaced by BIP 0002) used the Approved concept. My personal opinion is that it creates some confusion along the way.

Certainly, @Griffith can provide his perspective about CHIPs’ status and how he thinks it would be the best way to have a CHIP evolving from Draft to Approved (as his proposal describes). I just wanted to provide my perspective.

2 Likes

@Leandrodimarco @proteusguy
The original proposal when i created this thread had the status as you currently see it in the template. You make a good point that this no longer fits. Unlike the original, the current draft of the template is meant to accompany the milestones listed here:

and we should change the options for status to better align with the milestones.

It is now my thought that the following should be how the statuses are assigned:

  • “Draft” would be anything before being submitted for the early june cutoff at which point it would turn into “Proposed”.

  • “Final” and “Active” should probably be split into two instead of being in the same box. the change from “Proposed” to “Final” would happen with the early october cutoff.

  • “Active” implies that the change is live on the network. the change from final to active would be on the features activation date (in may).

and two other statuses should be added:

  • “Withdrawn” would be assigned whenever an author of a proposal still in the draft stage chooses.
  • “Deactivated” would be assigned if a feature that was implemented by CHIP is removed by some future fork. the status would change to “Deactivated” upon the fork day in which the feature is disabled.

Undecided if we need “Replaced”. CHIPs have a version number and we can simply adjust the spec under a new version and indicate an update in version rather than create a whole new CHIP to replace it.

I dont think we need “Deffered” or “Rejected”, something would simply exist as a draft until it doesnt.

Thoughts on this?

1 Like

I wrote a bit more on this here:

Generally speaking the terminology “final” and similar are taken from mostly centralised processes. I would aim more towards action based naming. For instance we can use “Ready for implementation” when the ecosystem is invited to implement it with a promise that the spec won’t change anymore until it gets activated.

Names like this also help a lot when someone comes in and sees the proposal they won’t waste time on trying to argue for changes because the cost of others to follow his or her suggestions is obvious: its already being implemented by many, so change suggestions will likely not be useful.

1 Like

Instead of “final” or “active”, I think it would be nice if we call the final status of an accepted and implemented CHIP “recommendation”. The W3C also uses “recommendation”, and I think this word is a good fit for the decentralised nature of BCH. If a CHIP is marked “recommendation”, the stakeholders mentioned inside the CHIP will make clear who recommend it (ideally everybody).

https://www.w3.org/2020/Process-20200915/#maturity-levels

@BigBlockIfTrue
I dont think we should replace “Active”, it is needed to distinguish between what is an active policy and what might have at one time been an active policy but has since been removed / obsoleted.

I agree with you and @tom that we need a better term than “Final”; however, i disagree that “recommendation” is a suitable replacement because consensus rules are requirements, not recommendations.

Currently, a proposal is set to “Final” after early October when its specification has been finalised, it has been thoroughly evaluated, has received sufficient support, and will be set to “Active” on next activation day. I suggest “Awaiting activation” or something similar as a replacement for “Final”.

If a CHIP is obsoleted, it’s no longer a “recommendation”, obviously.

If the CHIP contains a technical activation mechanism that needs to be triggered, we could distinguish between “recommendation awaiting activation” and “active recommendation”.

You’re missing the point. Consensus rules are not requirements. Nobody forces anyone to implement them. You can choose to not implement them, and accept the risk of forking off. We don’t use force, we use persuasion. We don’t require implementation, we recommend implementation. Without dismissing the severity of the consequences if the recommendation is not followed.

I would like to recommend, kindly ask, to use simple-single words for the status category.
Multiple words will make things hard in terms of classification, organization, visualization, etc. Same for long words.
Simple, direct, straightforward words are the best way to go for me.

2 Likes

Aren’t they though? This is equivalent to giving away something for “free” but requiring a donation to get that “free” item.
Sure, no one is forced to implement them in the same way no one is forced to use BCH.

Do you agree that implementing the consensus rules as the specs are written are a necessity if the node is to avoid forking from the rest of the network.

1 Like

Huh?
And laws can be ignored too, just suffer the consequences…

Sorry, but can we please keep the rethoric and politicians-talk to a minimum here and keep this an honest place of discussion? That is much appreciated.

1 Like