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
CHIP is not BCH consensus.
It is a tool to helps partipants go from an idea to a point in time where that idea have been either accepted or rejected. If you want to, youâre welcome to try and make consensus changes following some other process, and if it that process is better we can document and learn from it, and use that as one more tool in our toolbag to achieve good outcomes.
3 Likes