ECIP-1000: Irregular Process Transitions #220
Conversation
sorpaas
changed the title
This comment has been minimized.
This comment has been minimized.
|
maybe change this to propose only having one meta ecip per hard fork? |
|
it actually is similar to the dao fork, but the other way around, why wouldn’t we change the original 1061, you are creating lots of tension and confusion in the community by creating 1072 and pushing it forward over 1061. why? Atlantis followed this same process of updating the original meta ECIP. What exactly is the problem? |
|
rel #221 |
|
@shanejonas We're talking about violations of the ECIP process in this PR. I don't think whether preferring one meta ECIP or multiple meta ECIP matters here at all, as long as you follow the process to discuss it. In fact, I do think we have many community members who would prefer having only one meta ECIP from now on, but there's indeed also an alternative proposal #219 Currently, both having one meta ECIP, and having multiple meta ECIPs align with the ECIP process. The intention of this PR is rather to provide justification for all of our past ECIP process actions. So in contrary to @YazzyYaz's claim, this is certainly not a joke. |
|
I believe creating 1072 was a violation of the process. |
|
@shanejonas I'm happy to listen to you which point of creating ECIP-1072 violated the process. I'm also happy to know if I'm wrong, as long as you don't do void accusations but provide evidence and explanations. |
single ECIP |
|
@shanejonas That refers to constraints of a single ECIP. Multiple ECIPs, technically, can refer to different ways of implementing the same idea. A particular example of this is account versioning, we have at least three proposals all only about one single idea:
Of course, we can update that text so that in the future we will only have one single meta ECIP for each hard fork. I actually don't object that, as long as we agree we don't merge things without community consensus. Also, just curious, what's the actual point you're trying to make here? Now Aztlan exactly only has one single meta ECIP, as ECIP-1072 is withdrawn. |
|
Put this here again as I have also said it on Discord -- this PR is actually a protection to Aztlan hard fork, because now no one can accuse ECIP-1061 does not follow the process and use that point to create contentious hard forks. |
|
I believe 1061 follows the correct process as its getting updated to reflect changes, 1072 violated ECIP-1000 by creating more than a single ECIP for a given key proposal |
|
@shanejonas As said above, having multiple specifications about the same "key proposal" is not a violation of the ECIP process. The primary example is account versioning. There are also many other examples such as miner signaling proposals. We don't have a special category currently for "hard fork ECIPs", so this currently applies to it. However, as I said above, I'm happy to explore ways with you, to restrict future "hard fork ECIPs" to "single one only". I don't have any problem with that. |
Yes! ECIP-1061 followed the correct process when we merge this PR. It provides a special cause to declare that the action to merge it to "Last Call" was valid:
|
|
I disagree. Everyone agreed to not include 1884 for Aztlán. To me that means updating the existing 1061 single ECIP for a given key proposal. Just like the last 2 hard forks. The call was about 1061 not 1072: and you keep referencing the same chat but keep leaving out the last line about 1061: |
|
@shanejonas I don't believe the last sentence was a correct representation of the actual meeting recording. Multiple community members have pointed out this. But anyway, yes, it's true now that everyone agreed moving forward with ECIP-1061! It's just the agreement was not on the call. Still, I must emphasis, ECIP-1072 is technically not a violation of ECIP process, but I respect whatever the community has decided. That's why ECIP-1072 is moved to withdrawn status! |
|
@shanejonas Further explanation on the meeting notes point. #177 (comment) As said there, I'm pretty sure on that meeting what we have decided is ECIP-1072, otherwise:
|
|
@soc1c Please don’t close PRs simply because you object it. That will be a clear violation of the ECIP process. |
I'm the author of ECIP-1000 -- the currently accepted ECIP process. I failed to find any substance of what you're saying in that "the author of the process does not understand the process". The two other approvals you got even had an agreement with the objection #199 (comment). One of the approvals was also not from an ECIP editor. If you're suggesting you can get 3 people to form a dictatorship of Ethereum Classic and bypass any governance process, I'm happy to say you're wrong. :) |
|
Cry me a river. Remove my name and we can speak. |
|
As I have stated previously: If ECIP-1000 is the holy document, then I believe by just by creating 1072 you are violating the ECIP-1000 process of single ECIP for a given key proposal. I don't believe 1061 violated anything in ECIP-1000. I'd also like to point out the content of this PR, and attacking @soc1c for following the process we've done the last 2 hard forks (having 1 canonical ECIP, that we make PRs to) is not something I expected out of our community and it is really disappointing. |
|
@shanejonas If your argument is that creating new ECIP is wrong, then I think you have seriously misunderstood ECIP-1000 and the spirit of ECIP process. Reading ECIP-1000 carefully, you can find this text:
You haven't been able to provide a single argument for the logic inconsistency of the meeting notes provided by Afri, and you haven't been able to provide a single argument why dismissing another editor's reasonable objection is not a violation of the ECIP process, which makes ECIP-1061 invalid. As a result, I don't see any clear argument from you why you're against those solid arguments and facts. I can only conclude, for now, that there's something unjustified in ECIP-1061 that you want to hide. Fortunately, all ECIP editing actions are public and editors are accountable for what they have done. Hence irregular process transition. |
|
I created an ECIP: 1001 PR for Code of Conduct around the ECIP Process to address such actions #239 |
What exactly are you trying to say here? The call was about 1061 NOT 1072. You creating 10721 instead of making a PR is a violation of ECIP-1000. Directly from ECIP-100: https://github.com/ethereumclassic/ECIPs/blob/master/_specs/ecip-1000.md
I don't know how you can interpret that any other way. We also have the last 2 hard forks where we've made PRs to those instead of creating separate identical ones. I dont see any precedent for making |
|
@shanejonas Have you read the whole ECIP-1000? As I said previously, it contains this in its text:
That provides enough justification for the creation of ECIP-1072, in the context of ECIP-1000. Now to answer why the sentence you provided is irrelevant:
This states the property of "a single ECIP". To put it in another word, a single ECIP should not contain multiple key proposals or ideas (in that case they should be split up). |
|
the single key proposal here was Aztlan |
|
@shanejonas I'm not sure if you can't follow logic or anything. Yes -- for ECIP-1061, the single key idea is Aztlan, and for ECIP-1072, the single key idea is Aztlan. That's totally fine. We have explicit text in ECIP-1000 that allows this, as I have said repeatedly:
|
@sorpaas we didn't get the opportunity to initially build consensus around 1061 while it was in Draft stage because you immediately submitted three competing ECIPs that are similar to 1061 with some properties mixed and matched. You still submitted different editions of Aztlan which does violate You have then chosen to withdraw them and follow the ECIP-1000 process, which I'm glad you did. However, to create this PR to call what happened an irregular process transition on the call is just untrue. If it was an irregular process transition, then we need to amend this PR to include your actions of also irregularly modifying the ECIP 1000 process by submitting competing changes to ECIP-1061 before the consensus and discussions on 1061 even began. We can chose to add your actions to the PR or remove it entirely and call your actions simply a misunderstanding of the ECIP-1000 process. Once again, I'm glad you chose to follow the ECIP-1000 process and withdraw your three competing submissions to Aztlan. |
|
@YazzyYaz Again, mixing the water doesn't help your situation. As I have repeatedly said, none of the actions of creating competing ECIPs ever close violated the ECIP process. We clearly could not build consensus on ECIP-1061 when Afri tried to merge EIPs in without community consensus #176 (review). Even if there're violations (and I want to make it clear, there're not in ECIP-1072), all affecting ECIPs have been moved to withdrawn status, which means their courses have already been corrected (if there're things to correct, but I want to note there are not). If you're fine to move ECIP-1061 to withdrawn status, I'll definitely agree with you that this PR is not needed. Otherwise, ECIP-1061 itself constitutes an irregular process transition. |
|
@YazzyYaz As far as I know, merging ECIP-1061 to "Last Call" status is the currently only known irregular process transition that has not been corrected. I'm definitely open if you have other actions that you think should be added to the list. |
This is where we disagree, @sorpaas @soc1c didn't violate the ECIP-1000 Process. According to the ECIP-1000 process:
ECIP-1061 was still in Draft stage which means it can be updated later as he said it would be following a call the community would have. You blocked it to propose 3 competing ECIPs for the same idea while the initial idea was still in Draft stage and not violating the ECIP-1000. So, you violated the ECIP-1000 process. @soc1c hasn't. You withdrew your competing ECIPs because you realized you violated it, which gives me a lot of respect for you. Now, for this portion that claims @soc1c pushed for an irregular transition, that is where I disagree with you. If @soc1c added a new EIP to ECIP-1061 after it went to Last Call after we had a call, then I would agree with you. But he didn't. It was simply in Draft stage. |
|
@YazzyYaz Sure, but in ECIP-1000, I also wrote that:
Afri can update his draft PR, of course, but Afri merged something controversial at that moment, which means building consensus around ECIP-1061 was not possible at that moment. That's what's given justification to create competing ECIPs. The action of Afri violating the ECIP process was not when he merged controversial EIPs. That's totally fine. I'm also totally fine too to create competing ECIPs that are different. The actual action where Afri violated the ECIP process was when he dismissed review of clear and reasonable objection, and force merged his own ECIP into last call status. That's the irregular state transition mentioned in this PR. Also just curious, since you are so supportive of ECIP-1061/ECIP-1072 as a spec (since they're essentially the same), can you confirm your certainty about the safety properties on the hard fork you're proposing? |
That never happened though, you blocked it and then you merged it after you added your own competing ECIPs without allowing for discussions to happen first about the original ECIP 1061 by soc1c that has been created first. As mentioned in the meeting notes:
Consensus was agreed on 1061 that adopts the 1072 flavor, which I and others approved allowing soc1c to merge. To call it a forceful merge is inaccurate as it was approved by us as in the PR. You're following extreme robotic logic of saying "if 1072 was mentioned, therefore 1072 is the one to be accepted" which was not how the call happened. The call was about 1061 and going over the flavors you mentioned, even though those flavors you proposed were against the ECIP-1000 process. You can ask me about the safety properties of the hardfork, but you're just changing the subject to show off how much you know about the technical details of the hardfork in question to take away from the fact that you are the one who violated the ECIP-1000 process to begin with. Stick to the subject matter. One way we can perhaps resolve this issue is that we can propose 1072 as an edition, so it can be referred to as 1061-A/B/C and use that as a reference to the original 1061. Even if it was rejected before in your PR, we can revisit it since I feel it wasn't properly discussed with the wider community. That way, everyone goes home happy. |
|
@YazzyYaz I don't think you can get away with the logic contradiction if we indeed agreed on ECIP-1061. Based on my notes and many others who attended the meeting, the decision was ECIP-1072, which I even clearly asked whether it is the case in the end. #177 (comment) Anyway, if you want to say otherwise, you need to dispute the logic inconsistency. Otherwise it really have no substance. I don't know what you want to accomplish here by arguing a thing that's not even related to this PR -- we're talking about violation of ECIP-1061, and it's not even related to the discussion of ECIP-1061 vs ECIP-1072. I can only take this as you're so confident in the ECIP you're proposing that you think there's absolutely no issue in the specification or whatsoever. |
|
@sorpaas your notes are your own fabrication. You presented them 5 days after the call and they contain things I don't remember from the call. You conveniently only have the notes of the call for the issue you're raising in question. I also dispute the content of your meeting notes. Your initial question about Last Call was whether it should be 2 weeks. soc1c said three weeks is better.
Also, my comment:
Now you have issues with the discussions of 1061 vs. 1072 since it's not related to this PR. I disagree, it does. You have a personal vendetta against soc1c so your are adding this section here to the ECIP process as to have revenge against 1061 being the one accepted to Last Call. If you'd like to close this PR and open a new one where 1072 is an edition of 1061 that 1061 can reference 1072 as an edition, everyone is happy and can move on. |
|
@YazzyYaz So your only reason for the actual dispute is that I published my notes late? Do you know Kevin also have notes on the meeting but it's still unpublished until today? I agree my note won't be entirely accurate, but your logic seems to be Afri's note is entirely accurate (which you used to reached your conclusion on ECIP-1061). That's just double standard, or is this a personal attack against me that violates the Code of Conduct? The logic inconsistency I listed about ECIP-1061 is based on the common facts of both me and Afri's notes. By arguing my note was not "entirely" accurate, you did nothing to dispute it. I don't think what we do about 1072 matters any more, even if it becomes an "edition" of 1061 (which originally it wasn't), this PR still stands, and it still won't hide the fact that 1061 is an irregular state transition.
Please stop this. This is clearly personal attack and violation of Code of Conduct, which should get you issued an warning. |
How is it a personal attack? Afri published the entire meeting notes right after the call. It wasn't disputed till he made a PR for ECIP-1061 Last Call.
How is defining your actions of slandering Afri as a vendetta considered a personal attack? I don't think I follow your logic. If it's not something personal against Afri, then I apologize and look forward to you removing his name from the PR as you claim it's not a vendetta. Also, the Code of Conduct is still in Draft stage, which I hope you can recall means its subject to change as defined in the ECIP-1000 document. If it's in Active stage, that's different. |
Right, but I'm pointing out you're violating the document you just wrote. Your action is a personal attack. Can you point it out to me which sentence in this PR did I try to "slander" Afri? All what I said is Afri's action is justified. And as I also said and pointed out by others (like @phyro), Afri, as an editor, is known by the community. If it can be clarified that Afri only want to be referred to by its anonymous handle in ECIP-1000, then I will definitely be fine replacing Afri with @soc1c after #236 is merged. |
I can only violate it if it's in Active stage, otherwise it's just a Draft subject to change as I'm sure you're well aware. If not, I'm happy to refer you to the correct section in the ECIP-1000 that talks about this. |
|
@YazzyYaz I'm not accuse you. I was, however, using what I said to make a point that "you're violating / not following the document you wrote yourself". As I have said previously, my common strategy is just to ignore any personal attack parts if that exists in a comment, and that's fine by me. |
|
This ECIP is really not at all helpful. There were misunderstandings. We are all fallible humans. We worked them out and we have moved on. There are other ECIPs now being written with suggestions on how we can tighten things up to minimize the risk of such misunderstandings again. There was no "maliciousness" from the participants. We are all on the same side. We all wanted (and still want) exactly the same scope for Aztlan. Do you really feel it is worthwhile for all to be spending such vast amounts of our precious time on this? Even if there WAS a "breach of process" (and that is subjective) then we held a Core Developers call to AFFIRM that we had did have consensus around 1061 as written. |
|
@bobsummerwill Thanks for confirming that there's indeed a breach of the process. You're asking the wrong side -- it's only because people trying to deny that there was a breach of the process that we're still wasting the time here. Otherwise, we will accept this irregular process transition and move on. |
|
I did not confirm there was a breach of the process. I support any proposal made to remove you as an ECIP editor. You are making enemies and are destroying all the goodwill and good reputation which you have within the ETC ecosystem by repeatedly NOT LISTENING to what other people are saying. We are all on the same side. And in this specific instance we all wanted and still want the exact same scope. You are bikeshedding to infinity. |
|
@bobsummerwill I do not know why anything else you said matters here. A breach of the process is a breach of the process, no matter how many times you want to waste people's time to reframe it. This is the same as If you were being rational, you should have been putting arguments out the first day when the process breach happened, not posting random angry comments several weeks after the breach. Now it pretty apparent who is wasting everyone's time. |
|
You are still not listening, @sorpaas. Many people (including me) do not believe there was a breach of process at all. And that EVERYTHING which has happened since comes from your view of events, not any objective breach of process. And that you are digging your own grave here by arguing for “fixes” for something which was never broken in the first place. |
|
@bobsummerwill We have lengthy discussions about why things written in this PR is objective (#220 (comment)) and why framing this as "someone's subjective" opinion doesn't work. What happened is what happened. For the past two weeks, I've only seen desperate attempts from you and Afri to hide wrongdoings of past actions, by repeatedly trying to close this PR, or by claiming that Afri should be pesedo-anonymous while making no attempts in merging #236. |
As a decentralized community, it is important that for all governance actions, especially in ECIP, the established process is followed. In this section, we document irregular process transitions, and give special permissions to them, to state that they followed the process. Note that this is essentially similar to theDAO hard fork in Ethereum, and should only be added in extreme cases.
One irregular process transition is included in this PR: