Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ECIP-1001: ECIP Code of Conduct Discussions #238

Closed
YazzyYaz opened this issue Dec 3, 2019 · 21 comments
Closed

ECIP-1001: ECIP Code of Conduct Discussions #238

YazzyYaz opened this issue Dec 3, 2019 · 21 comments
Labels
type: meta ECIPs of type "Meta" - bundling proposals for upgrades.

Comments

@YazzyYaz
Copy link
Contributor

YazzyYaz commented Dec 3, 2019

This is the issue ticket for the ECIP-1001: ECIP Code of Conduct proposal.

One thing needed is a general community email for key stakeholders to be notified if someone feels harassed or a victim to be able to send an email to.

Perhaps a community@ethereumclassic.org email with representatives of the community and ECIP process on it to be notified of any violations of ECIP-1001.

Furthermore, we need to schedule a call to agree to this proposal, or we can all sign a statement to approve it on the issue ticket here.

@YazzyYaz
Copy link
Contributor Author

YazzyYaz commented Dec 3, 2019

If approved, I will then propose adding a commit to move this to Active status.

@YazzyYaz
Copy link
Contributor Author

YazzyYaz commented Dec 3, 2019

From @bmann:

Hey @yaz -- a contributor code of conduct seems like a fine idea
I'm reading up and think a couple of things

  1. non threaded discussion like Github Issuies or Discord chat is going to always be hard
  2. Figure out what you're trying to solve.
    Do you want to clearly identify where to go for help? Great.
    Even there, where that email goes and "who decides" is still going to be the issue
    If this is being done in regards to current discussions -- then you should just figure out a resolution there -- rather than retroactively applying a code of conduct
    Don't know enough about the current situation to say much more
    For (1) might just be some tips
    e.g. If you are not replying to the post immediately preceding yours, try quote-replying and/or mention the name of the person you're replying to

@sorpaas
Copy link
Contributor

sorpaas commented Dec 4, 2019

Furthermore, we need to schedule a call to agree to this proposal, or we can all sign a statement to approve it on the issue ticket here.

All ECIP discussions and decisions should be resolved and made in written form. Calls are exclusively resolved for hard forks. That's at least the spirit of ECIP-1000.

@YazzyYaz
Copy link
Contributor Author

YazzyYaz commented Dec 4, 2019

@sorpaas sure, but to point out, we had a Mining Call which wasn't in regards to a hard fork yet but to ECIPs. I understand you don't want to participate in many calls, but honestly, most ways to achieve consensus is via calls. That way we can hear people's opinions and have a recording to reference. Since this is mostly a Meta, I don't think this needs a call per se, but I won't discount it if others feel it does need a call.

@sorpaas
Copy link
Contributor

sorpaas commented Dec 4, 2019

@YazzyYaz If you remembered the content, mining call was about the sha3 and ProgPow hard fork. I don't think you can justify why they don't belong to hard fork category.

Sure, people can have calls, but for anything other than hard fork, those calls are only for reference, and is not the main discussion and decision, nor the resolution.

@YazzyYaz
Copy link
Contributor Author

YazzyYaz commented Dec 4, 2019

@sorpaas SHA3 and ProgPoW weren't added to any Hardfork Meta, even if discussing them would mean having a Hardfork in the future if accepted. The discussion was purely about the ECIPs themselves.

I disagree that non-hardfork calls are only for reference. Having said that, I understand this is just a Meta ECIP and doesn't necessarily warrant a call per se, but again reserve the right to follow the wishes of the community.

@sorpaas
Copy link
Contributor

sorpaas commented Dec 4, 2019

@YazzyYaz Any hard fork meta is technically "purely ECIPs". What matters is the type and format of the discussions. As you said, sha3 and ProgPoW was discussed in the bases that they want to get applied on Ethereum Classic mainnet in the future, and thus it was a hard fork discussion.

I understand that you reserve the right to hold calls, but I hope you also understand that ECIP-1000 reserves the right to follow the wishes of the community based on written-form discussions, which may and can overwrite "decisions" reached in calls.

@YazzyYaz
Copy link
Contributor Author

YazzyYaz commented Dec 4, 2019

I understand that you reserve the right to hold calls, but I hope you also understand that ECIP-1000 reserves the right to follow the wishes of the community based on written-form discussions, which may and can overwrite "decisions" reached in calls.

If community wants a written-form discussion as the final decision, then of course this is what will be used.

Can you help me find the exact reference in the ECIP-1000 regarding only written form being the canon and not calls? It'll help me understand your PoV more.

So far, all I can find is that calls are considered canon:

An Accepted ECIP may progress to Final only when specific criteria reflecting real-world adoption has occurred. This is different for each ECIP depending on the nature of its proposed changes, which will be expanded on below. Evaluation of this status change should be objectively verifiable, and/or be discussed on the development calls, Discord channel, other groups or the mailing list.

A process ECIP may change status from Draft to Final when it achieves rough consensus on the discussion process. Such a proposal is said to have rough consensus if it has been open to discussion on the development calls, Discord channel, other groups or the mailing list for at least one month, and no person maintains any unaddressed substantiated objections to it.

In both examples shown, it says development calls is considered part of the rough consensus process and not just for reference.

@sorpaas
Copy link
Contributor

sorpaas commented Dec 4, 2019

@YazzyYaz To me that means it's "just for reference". You can, of course, put the arguments made in the call into written-form texts, and make it part of the discussion. You cannot, however, just say you "reached a decision" on the call and use that as the argument to move forward ECIPs. The call does not have that privilege.

@YazzyYaz
Copy link
Contributor Author

YazzyYaz commented Dec 4, 2019

@sorpaas since it's not explicitly stated in the ECIP-1000, you can't say that community can't reach a decision in a call since no violation of the ECIP-1000 occurs.

You cannot, however, just say you "reached a decision" on the call and use that as the argument to move forward ECIPs. The call does not have that privilege.

That's provably false based on the ECIP-1000 mentioning that development calls have that privilege.

Your other point is:

To me that means it's "just for reference".

which contradicts the ECIP-1000:

Such a proposal is said to have rough consensus if it has been open to discussion on the development calls, Discord channel, other groups or the mailing list

Rough consensus means a development call can be used to make a decision about an ECIP that's non-hardfork related according to ECIP-1000.

@sorpaas
Copy link
Contributor

sorpaas commented Dec 4, 2019

@YazzyYaz I wrote that part as it is in ECIP-1000 because the process consists of multiple discussion channels. If you say calls somehow have privilege to reach decisions regardless of what happens anywhere else, then what if it contradicts to the decision we made on Discord channels, what if it contradicts to the decisions we made on mailing lists?

That's the reason why the actual consensus process in ECIP-1000 can overwrite decisions you reached in calls, and why calls are "just for reference".

@sorpaas
Copy link
Contributor

sorpaas commented Dec 4, 2019

@YazzyYaz This is technically also true for hard fork ECIPs -- meeting calls cannot overwrite ECIP process.

@YazzyYaz
Copy link
Contributor Author

YazzyYaz commented Dec 4, 2019

According to ECIP-1000, calls are considered canon, regardless of the nature of the ECIP itself. You can try continuing to argue your own interpretations based on concisely written rules in the process, but so far, your own interpretations hold no water as the ECIP-1000 clearly says calls can be used for rough consensus.

Simple solution to your argument is for you to join the call. If you're too busy, maybe make a PR to rectify the ECIP-1000 to suit your schedule.

@sorpaas
Copy link
Contributor

sorpaas commented Dec 4, 2019

@YazzyYaz I mean, that's clearly an attempt to subvert the ECIP-1000 process. I wrote ECIP-1000, so I understand perfectly that nothing in it mentions that calls are the "canon" consensus process. That's not "my own interpretations".

Feel free to arrange calls, but please also understand that you can't ignore other discussions channels. Otherwise, as mentioned, ECIP-1000 process is multi-channel, so what happens in other channels may and can overwrite "decisions" you reached in calls.

@YazzyYaz
Copy link
Contributor Author

YazzyYaz commented Dec 4, 2019

I'll let others decide what ECIP-1000 actually means in reference to calls. Calls are part of the canon per the ECIP-1000 rules so whether you wrote it or not, you clearly don't seem to follow what is written in it and you are claiming its being subverted just because you don't have time to join a call.

If a decision was made on a community call to achieve rough consensus and no one objects to it on other communication mediums, it's considered canon.

If you don't mind, can you move this discussion to a new issue to fully explore your own interpretations of the concisely written ECIP-1000 as they're considered off topic to this current ticket? We don't need to spam this ticket with your tangential rhetoric.

@sorpaas
Copy link
Contributor

sorpaas commented Dec 4, 2019

We don't need to spam this ticket with your tangential rhetoric.

Can you stop personal attacks when this discussion is about Code of Conduct?

If a decision was made on a community call to achieve rough consensus and no one objects to it on other communication mediums, it's considered canon.

That's partially true, but it has a time aspect in it, as mentioned in ECIP-1000. The better one is as follows:

If a decision was made on a community call to achieve rough consensus and no one objects to it on other communication mediums for a certain amount of time after the call (one month, for example), then it's considered canon.

Note that the above almost only happens if no discussions happen in other channels, which is seldom the case.

Calls are part of the canon per the ECIP-1000 rules so whether you wrote it or not

Well, that's entirely different than what you previously said "calls is the canon consensus process", which is false. Calls can participate in the consensus process, or if you insist on your words, calls can be part of the process. However, it certainly does not have any privilege in the process, and other discussion channels can overwrite decisions of the call if it reached a different one, or if the call does not represent community consensus.

@YazzyYaz
Copy link
Contributor Author

YazzyYaz commented Dec 4, 2019

Can you stop personal attacks when this discussion is about Code of Conduct?

It's not a personal attack. I encourage you to look up the definition. You are spamming this ticket with off-topic discussion, which doesn't necessarily means its malicious but is still spam nevertheless.

has a time aspect in it, as mentioned in ECIP-1000

Agreed, its part of the ECIP-1000 specs.

Note that the above almost only happens if no discussions happen in other channels, which is seldom the case.

It violates the ECIP-1000 as ECIP-1000 clearly states "or" as an option for communications as in the following quotes:

open to discussion on the development calls, Discord channel, other groups or the mailing list

"Or" is the key here. If a call is scheduled and rough consensus is achieved there, it's considered canon as per the ECIP process.

what you previously said "calls is the canon consensus process", which is false.

I never said that, please I encourage you to read what I said more closely:

"In both examples shown, it says development calls is considered part of the rough consensus process and not just for reference."

This clearly shows that I'm not saying calls are the canon consensus process but they're a part of it.

I attached a screenshot of what you wrote in case you edit your false accusations.
Screen Shot 2019-12-04 at 11 59 05 AM

Please, again, stop spamming this channel with this tangent. Let's isolate the issues. I won't continue this discussion until you respect that your points are off-topic for this issue and warrant a separate issue. Best wishes.

@sorpaas
Copy link
Contributor

sorpaas commented Dec 4, 2019

It's not a personal attack.

Are you setting up a precedent that the violator of the CoC is the ultimate judge of the violation? I'm fine with it, and I actually just don't mind if we don't have CoC at all, but that precedent will just make the CoC you wrote nearly useless.

I don't make accusations without reasons. But "calls is the canon consensus process" is indeed what you said:

According to ECIP-1000, calls are considered canon, regardless of the nature of the ECIP itself.


"Or" is the key here. If a call is scheduled and rough consensus is achieved there, it's considered canon as per the ECIP process.

Yes, as you mentioned, "or" is the key here. If a decision was already reached in Discord channels or mailing list, it is also considered "canon" as per the ECIP process. If you later say, "I also want to have a call", should the call be considered invalid because a decision has already reached in other channel? If you want a healthy ECIP process, you certainly shouldn't be ignoring arguments.

That's also why calls don't have special privilege, and that's why other channels may and can overwrite decisions you reached in calls. ECIP process is multi-channel. Calls participate as a channel, but that will just be it -- it's a "reference".

@sorpaas
Copy link
Contributor

sorpaas commented Dec 4, 2019

I don't want to accuse you, but let's stop those attempts of trying to ignore arguments we don't like. I never said I'll ignore the call, but what you're saying seems to be let's use calls and ignore any other communication channels. That certainly will be a bad idea, because we'll have ECIPs feeling rushed and under-reviewed due to it, and we'll probably have an example of this really soon.

@sorpaas
Copy link
Contributor

sorpaas commented Dec 4, 2019

Since you have decided to disengage the discussion, I think my main points still stands:

You can, of course, put the arguments made in the call into written-form texts, and make it part of the discussion. You cannot, however, just say you "reached a decision" on the call and use that as the argument to move forward ECIPs. The call does not have that privilege.

Calls can be part of the process, but ECIP process is multi-channel, and calls do not have special privileges.

@bobsummerwill
Copy link
Member

Superceded by #276?

@q9f q9f closed this as completed Aug 17, 2020
@q9f q9f added the type: meta ECIPs of type "Meta" - bundling proposals for upgrades. label Aug 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: meta ECIPs of type "Meta" - bundling proposals for upgrades.
Projects
None yet
Development

No branches or pull requests

4 participants