Skip to content

Add maintainer pledge blog post#1677

Closed
IstoraMandiri wants to merge 1 commit intoethereumclassic:masterfrom
IstoraMandiri:blog/maintainer-pledge
Closed

Add maintainer pledge blog post#1677
IstoraMandiri wants to merge 1 commit intoethereumclassic:masterfrom
IstoraMandiri:blog/maintainer-pledge

Conversation

@IstoraMandiri
Copy link
Copy Markdown
Collaborator

A starting point, with reference to https://github.com/orgs/ethereumclassic/discussions/558

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@netlify
Copy link
Copy Markdown

netlify bot commented Mar 20, 2026

Deploy Preview for ethereumclassic ready!

Name Link
🔨 Latest commit 85cc230
🔍 Latest deploy log https://app.netlify.com/projects/ethereumclassic/deploys/69bc9f5f6e50c30008d27047
😎 Deploy Preview https://deploy-preview-1677--ethereumclassic.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

@IstoraMandiri
Copy link
Copy Markdown
Collaborator Author

@diega @realcodywburns @chris-mercer

Is this unreasonable?

@chris-mercer
Copy link
Copy Markdown
Member

chris-mercer commented Mar 20, 2026

For context on why process clarity matters here.

This pledge references Discussion #558, which I opened to request formal governance standards. The questions there were not hypothetical — they were prompted by direct experience.

In September 2025, I received an unsolicited private message from the author of this PR:

IstoraMandiri — 9/4/2025 9:30 AM
Sup
I'll be direct - I don't support the Olympia hard fork proposal and I will actively oppose it if it's pursued.

From what I can tell there's also quite a bit of push-back from other members, several of which have reached out to personally with their concerns.

I'm appreciate that you have agreed that you won't force the proposal there's a risk of a chain split. Unfortunately, I believe a chain split is inevitable if the Olympia proposal is not abandoned, and as such I urge you to withdraw the proposal.

At this stage, I don't want to create any drama in public - hence the DM. I want to give you the opportunity to handle a withdrawal gracefully in your own way, while saving face and maintaining reputation. Our communications will remain completely private from my side.

But I am willing to escalate to prevent the implementation of the proposal if needed. That would involve the organizing of a multi-faceted campaign, including a nolympia information site, a public petition of prominent community members, of which I know there are many, and the setting up of a signalling system for miners to determine pre-activation consensus.

There is no doubt in my mind that I am able to garrison significant support from important participants, developers, and miners to the extent that the risk of a chain split is too great to implement Olympia safely or in a way that you'd hope for.

Such a campaign would take a lot of time and energy, the former of which I am short of. But I see it as a kind of sacred duty to protect ETC, and I am willing to sacrifice if needs must. I would be extremely grateful if you decide to save us all the hassle.

I appreciate your ongoing engagement and contributions to Ethereum Classic, and I hope you will consider my sincere request seriously.

Cheers.

My response:

freebird — 9/4/2025 10:08 AM
Hey Istora, thanks for reaching out. I'll keep this simple.

You say there's push-back from "several" members. Who, specifically, is opposed and what are their substantive reasons? So far, most of the noise has come from a handful of Discord accounts without any real engagement with the ECIPs themselves.

Second, what is your alternative solution? We all recognize ETC's long-standing funding gap — if Olympia is off the table, what concrete proposal would you put forward to sustain client development, infrastructure, and security as block rewards continue to decline under ECIP-1017?

It's worth noting this isn't "my" idea. Cody first suggested adapting EIP-1559 to Ethereum Classic back in 2021. Olympia is simply the evolution of that work — updated, modularized, and made opt-in so it can be implemented cleanly within the ECIP process. I've co-authored the current set, but the origin and intent go back years.

Withdrawing without exploring alternatives doesn't solve the problem — it just guarantees ETC development will go unfunded. That's not a feasible path forward. For nearly a decade, people in this network have been asking for a decentralized funding solution, and Olympia finally delivers one. It's entirely opt-in, with Type-0 and Type-1 transactions still supported, which makes a contentious hard fork extremely unlikely.

I recognize your intent to launch an opposition campaign, but everything in my research signals Olympia has strong support and is well-positioned for wide acceptance. The alternative today is a deprecated Core-Geth and an unfunded ETC network — or a centralized takeover of development by an unknown team. Olympia exists to prevent those outcomes, and nothing else on the table addresses this.

Simply put, the productive path is drafting a legitimate alternative ECIP, not launching websites and petitions. That won't be effective, so save your time.

Thanks again for raising this directly, and I look forward to hearing specifics.

No reply was received.

I raise this because this pledge contains commitments that directly contradict the author's own conduct — both in the message above and in ongoing efforts to oppose Olympia through community channels rather than the ECIP process:

  • "No Agenda-Pushing" — "I will not use community channels to advance personal, political, or financial agendas. This includes subtle forms of influence such as selectively featuring content, timing publications to manipulate sentiment"
  • "Openness" — "Decisions about community resources should be made through rough consensus, not unilateral declarations"
  • "Censorship Resistance" — "I will not use my maintainer privileges to silence dissent"

Private pressure to withdraw a proposal before any public technical review is the opposite of open, neutral stewardship. Organizing a campaign to block an ECIP outside the ECIP process is agenda-pushing by definition.

If we are going to formalize maintainer standards — and I support doing so — the document should emerge from the collaborative process described in Discussion #558, not be drafted unilaterally with signatories added without their consent. I did not agree to be listed as a signatory on this PR.

I would welcome a version of this pledge developed through the process it claims to protect.

image

@IstoraMandiri
Copy link
Copy Markdown
Collaborator Author

Chris, I don't think that you publishing this private message is the gotcha you think it is.

I was reaching out to you privately and sincerely to giving you the opportunity to pull back before things escalated, which they have done and will continue to as you continue to push this proposal. Nothing in my message to you was incorrect and I stand by those words. Things have been playing out exactly as I explained to you, and will continue to beyond the point of a Chain Split event if that's how far you are willing to take it.

As for how this is or is not relevant to the pledge, I have been public about my position on Olympia and will continue to oppose it. There's nothing in this pledge, not should there be, about restricting what we do on a personal level outside our role as maintainers - it's about how we act as maintainers of these community assets and how we can separate our personal beliefs from how we engage with these assets.

That you don't understand this distinction is quite illustrative, and is why this pledge exists. "Organizing a campaign to block an ECIP outside the ECIP process" is perfectly legitimate, as long as this doesn't leak into how I use my ECIP maintainer privileges - unlike yourself, who is censoring criticism in the Olympia ECIP discussion thread.

This PR is a starting point, as I explained. If you want to make edits, please suggest them.

@chris-mercer
Copy link
Copy Markdown
Member

chris-mercer commented Mar 20, 2026

@IstoraMandiri, you frame this as a distinction between personal activity and maintainer conduct. Let's examine that distinction using your own actions as a maintainer.

Direct Merge Over Open PR (November 2025)
I opened PR #31 for Call #43 with an agreed agenda. You committed directly to main hours later, overwriting it. When I raised this with timestamps showing my PR came first, you acknowledged the overlap but asserted control:

"I would still like to retain control over the titles and the agenda of the calls I'm hosting"

"I'm intentionally not setting a fixed agenda or framing at 'we're implementing Olympia'"

That is maintainer authority being used to suppress a proposal's framing — exactly the conduct this pledge claims to prevent.

image

Gatekeeping Call Hosting
When I attempted to host a call covering ECIPs I co-authored, you responded:

"If you want to host the call, let's perhaps discuss this first before you unilaterally decide to do that, since I've been handling it for the last like, 30 calls."

Hosting community calls for 30 iterations does not confer ownership. The pledge's own "Openness" section states: "I will not gatekeep participation or act as a bottleneck to contribution."

Discord Automod and the "Banning" Narrative
On March 7, 2026, you repeatedly triggered the Discord automod, received automatic timeouts, then publicly posted screenshots in a separate Discord server framing this as being "banned" — generating outrage from users who weren't present for the context. You then demanded I "unban" you and "give me the ability to say 'shit' just like you."

The automod is automated and applies equally. Framing automatic moderation as targeted censorship, then publicizing it elsewhere to build opposition — that is exactly the kind of manufactured sentiment this pledge should address.
image
image

Discussion #530 Flooding
In Discussion #530, you flooded the Olympia discussion thread with comments that had already been addressed, then characterized the standard GitHub collapse of resolved/outdated/spam-marked comments as "censorship" and "hiding comments from the public." Other moderators' actions marking comments as resolved, outdated, or in some cases spam were overridden by your own interpretations on the thread you were flooding.

"Moderator Note 2 (from istora): This comment was originally hidden from public by @chris-mercer, but as of 2026-03-17, as a maintainer, I have reverted this decision and made it visible, other maintainer agrees."

A maintainer overriding another maintainer's moderation on a thread they are actively flooding is not neutral stewardship.

Forcing ECIP-1120 Through Without ECIP-1000 Compliance
ECIP-1120 was submitted with multiple unspecified parameters (Elasticity Multiplier, Max Gas Limit, distribution window N — all marked TBD), incomplete research (linking to ecip1120.dev for work not yet done), and a Motivation section that exists primarily to editorialize against the Olympia ECIPs rather than present independent technical justification.
ethereumclassic/ECIPs@558160e

I flagged these as ECIP-1000 compliance issues — the same standards that apply to every ECIP. The response was to add Diego López León — ECIP-1120's co-author — as an ECIP editor, providing the approval needed to claim a 3/4 ECIP maintainer majority on your centrally controlled call. One existing maintainer approved with a stated "disagree and commit." This is not following established standards and processes — it is maneuvering around standards and norms to achieve a predetermined outcome while violating the governing ECIP-1000. It was later discovered this was just for drama and content on your call series, as your ECIP has made no progress.

Soft-Blocking Olympia Communication Since July 2025
The following PRs to the official ETC website have been left unmerged since mid-2025:

#1637
#1649
#1652
These PRs communicate development progress on Olympia — a proposal now implemented in three clients (Core-Geth, Besu, Fukuii) and in live testing on Mordor testnet. By leaving them in limbo without merging or formally rejecting them, you effectively prevent the Olympia team from communicating with the public through the project's official channels while using those same channels to promote a competing ECIP and organize opposition.

Using the Project TLD with Direct Merge
Community calls with 2-3 attendees are published at cc.ethereumclassic.org — a subdomain of the project's TLD — with summaries you author and agendas you set. This includes leaking demo v0.1 ECIP-1112-1113 contracts minutes after they were verified on Mordor — contracts clearly labeled as demo v0.1 in the public repo — then creating hysteria around them and adding the topic to your centrally controlled call agenda and transcripts.

image

The pledge states maintainers should not "selectively feature content, time publications to manipulate sentiment, or frame information in misleading ways." Publishing your personal framing under the project domain, with no review process, does exactly that.
ethereumclassic/community-calls#32 (comment)
image

You say "organizing a campaign to block an ECIP outside the ECIP process is perfectly legitimate." People can organize opposition — that's their right. But when the person organizing that campaign is simultaneously the ECIP maintainer, call host, and a website maintainer, the distinction between "personal activity" and "maintainer conduct" is a convenient fiction. Every action listed above was taken using maintainer privileges.

Beyond this pledge, you have been actively creating new processes that inject yourself into every facet of this project's decision-making — from reverting the client's primary repo to Diego's unmaintained fork, to proposing that upgrades must go through processes you control. This is centralization by accumulation of maintainer privileges, not decentralization.
etclabscore/core-geth#694

Olympia is implemented in three clients, tested on Mordor, and advancing through the ECIP process. The record speaks for itself.

Cheers.

@IstoraMandiri
Copy link
Copy Markdown
Collaborator Author

IstoraMandiri commented Mar 21, 2026

@chris-mercer, I note that your comment is entirely composed of personal attacks and does not engage with the content of the pledge itself. Nevertheless, I'll address your points briefly before asking you to return to the topic at hand.

1. PR #31 / Direct Merge
The community-calls repo has traditionally never used PRs — hosts commit directly to main for reduced friction, as has been the practice for 30+ calls. You opened PR #31 without prior discussion, departing from this convention. I didn't see the PR and continued with the established workflow by committing directly, as I always had. I confirmed this transparently in the PR thread — there was no intentional override. The full exchange is available there. After this disagreement, rather than continuing to discuss the issue, you pushed directly to main and vandalized the historical call records.

2. Call Hosting
You are free to host your own calls — no one is preventing that. My comment was in response to you unilaterally changing the format of an existing series I had been running for 30+ calls, without prior discussion. That is the context of the exchange you quote. See Issue #33 for the follow-up discussion about rules for the repo.

3. Discord Automod
The word I was timed out for was a direct quote of you — you used that same word without being flagged. So the automod was not, in fact, "applying equally." You also had admin privileges and chose not to resolve the timeout. This is a petty point and I'd rather not dwell on it.

4. Discussion #530 "Flooding"
Discussion #530 has 60 comments from multiple participants — 25 from you, 15 from me. You characterize my participation as "flooding," yet you are the largest contributor to that thread. You also hide comments that are critical of your position, then complain when those moderation actions are reversed. More importantly, you continue to claim these criticisms were "addressed," but as discussed in Call 48 (March 20, 2026), specific technical questions about the Olympia specification still lack answers. The most recent substantive comment is from March 18 — barely a week ago — which confirms these matters are not resolved.

5. ECIP-1120 and ECIP-1000 Compliance
The ECIP maintainers reviewed ECIP-1120 (PR #547) and reached a decision. You disagree with that decision, but disagreement does not make the process illegitimate. Your objections reflect a misunderstanding of ECIP classification requirements and historical precedent — this has been discussed at length in the PR itself.

6. Website PRs
I am not "soft-blocking" anything. PRs #1637, #1649, and #1652 have a clear pathway to being merged: add the necessary context and disclaimers so readers can form their own informed view. This is exactly what the pledge advocates — neutral stewardship of official channels. You, meanwhile, are blocking content that already includes disclaimers, and are also blocking the very PR that would add disclaimer infrastructure to the site.

7. Project TLD and "Leaking"
The community calls website is an ethereumclassic org GitHub Pages site hosted from the community-calls repo — the same repo structure as all other ethereumclassic.org and ecip subdomains. There is nothing new or unusual about this. As for "leaking" your demo contracts — I didn't leak anything. They were deployed to a public blockchain. I searched "Olympia" on a block explorer and found them. That's how public blockchains work. If you are deploying contracts to a public chain as part of an open-source project, there is no expectation that they be hidden from the public — and discussing them openly is not a breach, it is the point.

8. Centralization
On the contrary — attempting to force through the Olympia suite without open discussion, slipping changes through without review, and dismissing discourse is centralization. The processes I am proposing exist precisely to prevent any single participant — including me or you — from unilaterally controlling outcomes. Resisting open discussion is the very problem this pledge exists to address.


None of the above engages with the substance of the pledge. Your comment is a list of personal grievances presented as governance critique. The pledge is about establishing shared standards for maintainer conduct going forward — standards that would apply equally to all maintainers, including me.

I have repeatedly attempted to engage with you on these topics — both in public forums and in private. Those attempts have been ignored or dismissed. It is not "open discussion" you want — it is the absence of scrutiny.

Will you sign the pledge, or should I remove your name from this PR?

Copy link
Copy Markdown

@diega diega left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy to co-sign this

@realcodywburns
Copy link
Copy Markdown
Member

This seems like a dup of https://github.com/ethereumclassic/volunteer repo. I do not have an objection, it feels overly performative. The ef is currently making pledges to their new mandate, our has been in place for years. https://x.com/VitalikButerin/status/2032469755614179700?s=20

@IstoraMandiri
Copy link
Copy Markdown
Collaborator Author

IstoraMandiri commented Mar 23, 2026

The volunteer repo seems to be largely about registration / onboarding, rather than clarifying how we should be behaving as maintainers, as requested by @chris-mercer in https://github.com/orgs/ethereumclassic/discussions/558.

I think this pledge is important going forward as it will help unblock the deadlock in recent PRs by making what I had assumed was an unwritten understanding into an explicit agreement. Agreeing to maintain neutrality shouldn't be controversial.

Since you don't have an objection, @realcodywburns, your approval to this PR would be appreciated.

@chris-mercer , I ask again - would you like to be included in this pledge, or not? Please respond in a reasonable timeframe.

@realcodywburns
Copy link
Copy Markdown
Member

realcodywburns commented Mar 26, 2026

nack, update the volunteer repo. This is meaningless as a blog post. if this is intended to cover the entire repo, that is the most appropriate place

@IstoraMandiri
Copy link
Copy Markdown
Collaborator Author

@realcodywburns I understand it doesn't necessarily need to be a blog post.

But publishing this is largely symbolic and meant for us maintainers more than anyone.

Can we have our maintainers at least agree to follow some basic fair play, like this pledge explains?

Are there any points which you disagree with?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants