[rfc] Remove good first issues label and template #35399

The good first issue label has been attracting a number of slop PRs. We've been removing the label from issues recently and not adding the label to new issues. This seems to have reduced the amount of slop. Given that the label no longer is working as intended, I think it should be removed.

Similarly, there is the good first issue template which automatically applies the label. This template is supposed to only be used by regular contributors, but of the 6 non-spam good first issues opened since the beginning of 2025, only 2 were created by regular contributors. I think that given this misuse, it should be removed.

Basically restating my question from IRC (https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2026-05-27#1779919187-1779922647;): Won't the slop horde open PR's for other issues? I'm not sure what evidence there is that avoiding the use of the label has reduced slop in general in the repo, but I don't have as much context as you and others do. But I'm pretty sure that all of the LLM's that opened issues and labeled them good first issue would have opened issues anyways just without the good first issue label, for example.

If it's feasible, maybe another solution is to disallow the use of the label by new contributors.

I'm not sure what evidence there is that avoiding the use of the label has reduced slop in general in the repo

There was a mass unlabeling of good first issues in February, and since then, the good first issues which were having many separate slop PRs opened for them stopped getting new PRs. But maybe that's just a coincidence.

But if we're going to unlabel all of those new issues and not label new ones, the label should be deleted.

If it's feasible, maybe another solution is to disallow the use of the label by new contributors.

Labeling is a permission that is granted to only members with at least the Triage permission. The problem is the issue template which anyone can use, and always applies the good first issue label (unless you have the permissions to apply a different label). I looked through the issues that used this template and the ones opened by new contributors all should have either been bug report or feature.

Ideally Github would let us restrict usage of the template to org members only, but AFAICT, that feature doesn't exist. Possible alternatives could be to to remove the automatic label (kind of defeats the purpose of the issue template IMO), remove the template, or have drahtbot autoclose them (noisy).

I think that the good first issue label is no longer useful, and therefore we should delete the label. If we're going to delete the label, then the issue template is also not useful and we should delete that too.

ACK

FWIW, my standard reply to newcomers who ask what to work on, is to review others' work and in the process of doing that and participating in the project -- improving their understanding of codebase+process and accumulating context -- over time they will see an abundance of things to do.

I agree it doesn't make sense to keep the label and the template if the last time it has been actively used was in 2023.

FWIW, my standard reply to newcomers who ask what to work on, is to review others' work and in the process of doing that and participating in the project -- improving their understanding of codebase+process and accumulating context -- over time they will see an abundance of things to do.

I agree here as well. Review and testing is the bottleneck of the project, not writing new code. And naturally review will provide a flow of possible good first issues to work on, so I think adding a sentence to the docs while removing the label/template makes sense.

Done both in https://github.com/bitcoin/bitcoin/pull/35400

NACK.

Why I oppose this

This would prevent newcomers from knowing what to work on without interacting with someone first, which is not scalable. Labeling issues allows for distributing this effort.

A non-solution

Moreover, and this is much more important, this doesn’t solve the underlying problem. The real problem here is spam, with AI used as the delivery and generation mechanism.

Fundamentally, this means that we want to find a solution that has high cost for spam (AI) and low cost for humans. This could be a computational challenge, or a challenge where the user has to interact with physical environment in some way, or something else of that nature.

However, this just reduces to a cat and mouse game between AI labs and the Bitcoin Core project. If the adopted challenge is successful, then AI labs would be incentivized to break it to improve their models. If the adopted challenge is not successful, then it’s just useless and spam would continue. I’m sure everyone here is familiar with CAPTCHAs, they don’t work very well.

A solution that I’m proposing

So a different solution for the cost that’s usually presented in these conversations is economical. Besides it just working conceptually, which you can show by reasoning through the problem in terms of incentives, this particular project should adopt it for ideological reasons, to demonstrate that Bitcoin fixes real world problems.

Make it costly (as in money) for spam generators to post new content.

What we could do is ask the first time contributor to send 1 sat (or a higher amount if that’s not expensive enough to defer spam) to an address and attach their pull request id to the transaction. After that, a bot should unblock them and add them to the allow-list, where no further transactions would be necessary. Otherwise, the PR should be closed automatically with a process documenting how to verify yourself, as explained above.

How is it different from a computational challenge? For spam generators, the cost would be too high eventually to make it practical, and they would stop doing it. For the project, the cost can simply defer spam or even fund development work and infrastructure costs. So the incentives are aligned with the project here, as opposed to AI labs in the first example.

Where should contributors transfer the funds?

• Option 1: To an address controlled by a group of core contributors or an aligned foundation. I think this is better, because it can actually fund project’s work, as mentioned above.
• Option 2: To a burn address, which is statistically unlikely to be owned by anyone. This is okay because of the limited supply, since everyone owning Bitcoin would benefit. However, this doesn’t support the project directly, it’s less efficient, so I like this option less, but it does solve the problem of having to control the account and distributing profits. That said, I don’t think it’s a hard problem to solve because foundations are already involved in funding some work on Core.

NACK.

Why I oppose this

This would prevent newcomers from knowing what to work on without interacting with someone first, which is not scalable. Labeling issues allows for distributing this effort.

A non-solution

Moreover, and this is much more important, this doesn’t solve the underlying problem.

I think you are missing the point. The goal here is not to "fix spam", and I think it is obvious to everyone that simply removing a label and template isn't going to "fix spam". The point here is that the label and template haven't been actively used for years, so simply keeping them is pointless.

Moreover, this doesn't hold anyone back from filing issues, or considering if they want to fix existing filed issues. This is only about the distinction that something is a "special" good first issue. Finally, anyone is free (and in fact encouraged, since review is the bottleneck), to review existing pull requests and naturally find stuff to work on, as they go.

ACK

What we used to think of as an actually good first issue can probably be easily solved by an LLM. It would still be fine to have them if actual people would solve them (maybe with LLM help) and learn something in the process. But it seems inevitable that agents will just immediately grab and solve them without any human looking at the code, likely with the only goal of making a throwaway GitHub account eligible for some airdrop in the future. At the same time these AI contributions are more work to review than the solutions humans used to suggest because they tend to be very verbose and require more feedback rounds. It is clearly more efficient if experienced contributors resolve these issues when they see them (with or without LLM help).

The goal of the label had been to get people started, and it was primarily a learning opportunity for the new contributor. It doesn't feel like there is much of a learning opportunity if an LLM can one-shot the solution. People can still learn from it but with LLM guidance they can also learn from reviewing more complex PRs nowadays IMO. We could improve our guidance there, but it's a lot of effort to do this consistently, similar to what pr review club has been facing. We did add a "good first review" label some time ago but it hasn't been used much. But this aligns better with what the project really needs, and it takes away the economic incentives (airdrops). There are also tons of learning opportunities for people outside of this repository these days which should be good enough to guide people so they can solve a problem that goes beyond a trivial issue.

Maybe removing the label won't change anything with how much slop we see but I also don't see any good reason for keeping it.

We did add a "good first review" label some time ago but it hasn't been used much.

wen "rfc: Remove good first review label"?

Actually, I think, it can removed right now without an RFC. It hasn't really been used, and what is a good first review, likely mostly depends on the personal preferences, interests and background of the reviewer.

There seems limited benefit in keeping a Good First Review label, when it is unused, and when there is no clear guidance on when to use it and when not to use it.

Makes sense to me.

strong ACK

And naturally review will provide a flow of possible good first issues to work on,

review others' work

myself being a new contributor, this has always worked out alright for me. i've also found reviews to be uniquely valuable compared to opening PRs. you get to know/learn many different parts of the codebase, design decisions, reviewer thought processes in a relatively short amount of time and also get the big picture of things (which matters a lot because much effort in the wrong direction is equivalent to getting lost faster).

Looks like this was closed, but the labels would have to be deleted by a maintainer:

https://github.com/bitcoin/bitcoin/labels?q=good

The labels were removed.