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’.
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.
2 Likes
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).
1 Like
@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”.
1 Like
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.
2 Likes
I liked the diagram, but felt there was some odd things with it (like two lines to deferred, and inability to withdraw after proposal), so I read the rest of this conversation than drew up a diagram I think makes sense.
Feel free to use if it’s helpful.
1 Like
I like this diagram better than the previous one personally.
Shouldn’t there also be a path from proposed to rejected?
I’m not sure. On one hand it feels like there’s no reason for anyone outside of the chip owners to give a clear rejection until it’s in a state where it’s considered final and we know all the details. On the other hand, the rejection is quite vague to begin with, since we don’t really know who is doing it, how or why.
Maybe it does make sense that some proposals are easy to reject, and as such could get rejected before reaching their complete state.
I wasn’t happy with deferred being a status a chip could have, and rejection didn’t feel like a tangible status a chip owner would set either, so I made an attempt at an updated draft. Also included one more outcome: contested - the only failure in the chip process:
Now I kinda want to read an article titled: “The CHIP process - understanding Bitcoin Cash consensus” xD