Hmm… it might be more reliable to contact them by email than through the forum
:
From what I can tell, this looks less like a Hugging Face Forum/Hub account restriction and more like a GitHub organization-level block on huggingface.
In PR #47709, a Transformers maintainer explicitly said the account was being blocked and then closed the PR. GitHub’s own documentation says that organization owners and moderators can block users, and that owners/moderators can later unblock them.
So I don’t think people on this forum can directly lift this particular block. The final decision would need to come from someone with the relevant permissions on the Hugging Face GitHub organization.
Since an organization block also prevents the blocked user from opening PRs/issues and commenting in that organization’s repositories, contacting the relevant team outside GitHub seems reasonable.
The closest public contact I could find in the Transformers repository is feedback@huggingface.co, which is listed in the repository’s Code of Conduct as a contact for the community leaders responsible for enforcement.
I would add one caveat: I could not find a public document saying that this is specifically a GitHub organization-block appeal address. So I would treat it as a reasonable contact to try, rather than claiming it is an official dedicated unblock-appeal channel.
If you email them, I would probably keep the request quite short and separate it from the technical patch itself:
- your GitHub username;
- a link to PR #47709;
- a short request for reconsideration of the organization block;
- acknowledgement of the concern that was raised there;
- how you intend to follow the repository’s current contribution guidance going forward.
Then I would treat the new axis= → dim= change as a separate technical question. That separation may actually make both questions easier to evaluate.
One small technical point is worth checking before using that branch as evidence for the reconsideration request: I would not rely on the broad claim that axis= is simply an invalid PyTorch keyword and therefore necessarily causes a TypeError.
There are real axis/dim compatibility problems in some PyTorch execution paths, but they appear to be more specific than that. For example, PyTorch #171979 showed a case where:
eager -> succeeds
aot_eager -> succeeds
inductor -> fails
for torch.cat(..., axis=...).
That was an Inductor compiler-path inconsistency rather than axis being universally invalid. The corresponding upstream fix, PyTorch #183995, explicitly normalized NumPy-style keyword arguments before the relevant fusion pass and also made that pass handle axis defensively.
So the axis= → dim= patch may still be useful in a particular supported PyTorch version/backend/code path — but a very small reproducer would make the case much stronger than changing all of the occurrences first.
Why I think the forum block and the GitHub block should be treated separately
GitHub organization blocking has fairly specific semantics.
According to GitHub’s organization blocking documentation, a blocked user cannot, in that organization’s repositories:
- open issues;
- send pull requests;
- comment on issues, pull requests, or commits;
- fork/watch/star repositories, among other restrictions.
And GitHub’s unblocking documentation places the unblock action with organization owners/moderators.
That is different from, for example:
Hugging Face Forum moderation
|
| different system
v
Hugging Face Hub account/content moderation
|
| different system
v
GitHub's own platform-level moderation
|
| different system
v
huggingface GitHub organization moderation
The public evidence around #47709 points to the last case.
There is also a smaller distinction around the Code agent slop label.
The current Transformers anti-slop.yml explicitly configures its automated quality check to not close or lock the PR; it adds the label and tells genuine contributors that a maintainer can review a possible false positive.
So an automated Code agent slop label by itself is not the same thing as an organization block. In #47709, there was also an explicit human maintainer comment about blocking the account, which is why I would treat this as the organization-moderation case rather than merely trying to dispute an automated label.
About the axis= → dim= patch
I think there are two different claims that are easy to accidentally combine:
- “
dim= is the conventional/canonical spelling used throughout PyTorch code.”
- “
axis= is invalid and will necessarily produce a runtime error.”
The first can be a reasonable style/compatibility argument.
The second needs more qualification.
PyTorch has compatibility machinery for NumPy-style argument names, and the existence of PyTorch #171979 is itself a useful example: the reporter specifically found that torch.cat(..., axis=...) worked in eager and aot_eager, but an Inductor optimization failed because an internal function did not understand the still-un-normalized axis keyword.
The eventual upstream fix, #183995, describes the solution as:
- normalizing NumPy-style kwargs before early pre-grad fusion; and
- making
sink_cat_after_pointwise robust to axis as well.
That distinction matters because two patches can contain exactly the same surface edit:
- torch.cat(xs, axis=-1)
+ torch.cat(xs, dim=-1)
while solving very different problems:
A. invalid public API usage
B. compiler/backend compatibility bug
C. compatibility with an older supported PyTorch version
D. consistency/style cleanup
Those have different evidence requirements and different reasons for being merged.
The current Transformers CONTRIBUTING guide is also unusually explicit about this right now. It recommends:
- diagnosing the exact cause;
- reproducing the reported problem;
- keeping the diff minimal;
- comparing against analogous models;
- avoiding purely theoretical/busywork fixes that do not manifest in practice.
So if there is a real Transformers code path where axis= causes trouble, isolating that path first would fit the current project guidance very well.
A low-cost way to validate the patch
I would not start by testing every changed file.
One affected call site is enough to answer the most important question.
For example, record:
Transformers call site:
PyTorch version:
execution mode/backend:
axis= result:
dim= result:
traceback, if any:
Then the result naturally branches:
axis= fails in ordinary eager execution
-> investigate that exact PyTorch/API/version combination
eager succeeds, but torch.compile/Inductor fails
-> likely a compiler/backend compatibility issue;
compare with PyTorch #171979 and the affected PyTorch version
both axis= and dim= succeed
-> that call site is not evidence for a runtime bug,
although a consistency change could still be a separate proposal
only older supported PyTorch versions fail
-> frame it as a supported-version compatibility fix
current PyTorch still fails in a new pattern
-> minimal reproducer could potentially be useful to PyTorch upstream too
That one comparison gives much more information than mechanically replacing every occurrence, and it also tells you what the PR should actually claim.
If the reproducer shows a real failure, the patch becomes easier to justify:
Here is the exact Transformers path, here is the supported PyTorch version/backend, axis= fails here, dim= succeeds, and here is the regression test.
If it does not reproduce, that is useful too, because it avoids presenting a broad compatibility cleanup as a runtime bug fix.
So my default route would be:
- send the unblock/reconsideration request separately, probably trying the published enforcement contact because GitHub itself is unavailable to you;
- keep that request focused on the moderation/contribution-process question;
- independently reduce the
axis= patch to one concrete reproducer;
- if that reproducer confirms a real supported configuration is broken, use that evidence to shape the technical contribution later.
That preserves the useful part of your proposed fix without making the unblock request depend on whether that particular technical diagnosis turns out to be correct.