C++ Good First Issues

Leonid Bugaev
|
(Updated August 31, 2026)
|
8 min read
c++ beginners good-first-issue contributing

The C++ evening that fails is not the missing #include. It is cmake -S . -B build writing a cache into a directory you did not mean, or make dying because the README still lists -DENABLE_FOO=ON and the option is now -DFOO=ON. Get the documented configure command green on the default branch before you open the .cpp the issue named.

Generic hunting: how to find good first issues. Multi-language picking: best open source projects for beginners. Merge checks: how to pick an issue that will get merged. This URL is the C++ filter. C is a different language.

Open the C++ hub

C++ hub

Labeled good-first and help-wanted issues on active GitHub repos whose language is C++. The slug is /language/cpp, not /language/c++. On 2026-08-31: about 1,575 labeled issues at 10+ stars. Snapshot. It moves.

Writing C, not C++? That is a different hub: C hub. Separate feed. Do not mix them. A C ticket will not fix a CMake C++ example, and a C++ clang-tidy hunk does not belong on a C makefile.

Not writing C++? The homepage is the language switch.

Read the body. Skip stale, claimed, and repos that have not merged lately. I am not listing famous projects. A leftover label on a well-known name is still leftover. The feed is the hub, ticket by ticket.

CMake and Make: first-run pain is the first sitting

In C++ the real first sitting is often getting CMake or Make to configure at all. Out-of-source vs in-tree. A generator the README never names. A -D flag that moved. FetchContent that needs a network CI has and your laptop does not.

If the issue is docs or an example that still documents the flags the tree actually accepts — cmake -S . -B build -DFOO=ON, mkdir build && cmake .., cmake --build build, ninja -C build — that is a real first PR.

Shapes that merge:

Done is: a newcomer can follow that page and get a configure+build that matches what the project ships. Done is not a CMake 3-to-4 bump, a new preset schema, or rewriting the build to Meson because you like it.

Do not bump the compiler. Do not bump CMAKE_CXX_STANDARD, GCC, Clang, or MSVC as a souvenir. Version bumps review as policy and stall the example fix.

CONTRIBUTING will name the command. Run it on the default branch first. If you cannot configure on your machine, pick another ticket. Debugging their toolchain is two projects.

A green configure on main is the gate. The code change comes after.

Fix the example: that is the typical first merge

The first C++ PR that actually lands is usually a sample that does not compile.

examples/ still ships old_api.cpp. The README still has a fenced g++ -std=c++17 main.cpp -lfoo that lost a required -I. A tutorial .cpp includes a header that moved. The issue already named the file.

Shapes that merge:

Done is: that sample builds with the project’s documented flags. Run the example target CONTRIBUTING names — cmake --build build --target example_foo, make example, whatever they wrote. Done is not a new tutorial series, a rewrite of Getting Started, or restyling every sample while you are there.

Match their build. If examples are wired through CMake, use CMake. Do not add a one-off g++ line that ignores the rest of the tree. Do not “simplify” the sample by deleting setup the tutorial still needs.

A broken-example merge counts. An unasked rewrite of the examples tree does not.

clang-tidy / clang-format: the hunk, not the tree

clang-format will always have opinions. That is not an invitation.

A first-time clang-format -i on src/ rewrites headers nobody asked you to touch. Maintainers read it as a style crusade. They close it, or they make you revert 90% of the diff, which is the same delay.

Same trap with clang-tidy: clang-tidy -fix across the module turns a one-line example fix into a merge conflict against every open PR.

Rules:

Tool config is policy. Policy is not issue one unless the ticket is the tool.

A formatted example is hygiene. A tree-wide reformat is a closed PR.

Not compiler internals

Skip LLVM, GCC, and clang frontend work on purpose. Codegen, IR, the optimizer, libstdc++ / libc++ internals, ABI edges, a std:: facility the rest of the tree trusts — those review like architecture. A good first issue badge on them is a request for help, not a size.

Your first merge should be a leaf: the example, the README snippet, a docs line that names the real -D flags, a small public function the ticket named.

The compiler is not a difficulty badge. It is a contract. Do not take it to look more serious while a broken examples/hello.cpp is sitting open.

After you have a merge in that repo and have watched how they review internals, issue two can move inward. Not before.

I am not listing famous compiler or STL repos. Filter the C++ hub and judge the file, not the brand.

Ship one ticket

  1. Filter on the C++ hub. That slug is /language/cpp. C is the C hub — different language. Drop stale and claimed threads. Confirm recent merged PRs.
  2. Read CONTRIBUTING.md for CMake/Make/Ninja and format. Get the default branch to configure before you edit.
  3. Comment on one issue. Do not reserve five.
  4. Keep the diff on the ticket. Fix the example or the configure docs. clang-format / clang-tidy only what you touched. No compiler-version bump. Link Fixes #123. Say how you configured and built the sample. Stay for review.

Git mechanics: first pull request guide. Week-1 map: how to contribute to open source.

FAQ

The README configure flags are wrong. Is a CMake/Make docs fix a real first PR?

Yes. First-run pain is the actual first evening. A docs or example that names the real -D flags, the out-of-source cmake -S . -B build, or the generator they actually use is a real merge. Bumping GCC, Clang, or CMAKE_CXX_STANDARD as a souvenir is not.

Is a broken examples/ sample or README compile snippet a real first C++ PR?

Yes. One file under examples/ that fails to compile, or a README fence the ticket quoted as broken, is a typical first merge. A volunteer rewrite of Getting Started is not. Do the ticket.

Should I run clang-format or clang-tidy on the whole tree?

No. Format and tidy the hunk you touched. A whole-tree clang-format -i or clang-tidy -fix is a style PR. Reviewers close it or make you revert. Leave .clang-format and .clang-tidy alone unless that file is the ticket. If CI formats the tree, let CI.

Can my first issue be in LLVM, GCC, clang frontend, or the standard library?

No. Leave compiler internals — frontend, codegen, optimizer — and libstdc++ / libc++ guts until issue two. Those files have implicit contracts. Issue one is a leaf: an example, a README snippet, configure docs.

Where do I find live C++ good first issues?

On the C++ hub. The slug is /language/cpp, not /language/c++. C is a different language: the C hub. Filter, skip stale and claimed threads. Read CONTRIBUTING for CMake/Make and format. Other languages: the homepage.

Start here

Open the C++ hub. Pick one unclaimed ticket that is a CMake/Make docs fix, a broken examples/ sample, or a README compile snippet — not compiler internals, not a whole-tree clang-format. Comment once, clang-format only what you touched, keep the diff on that job, and stay for review. Writing C, not C++? The C hub is a different language. Not writing C++ tonight? The homepage is the language switch.

Back to all articles Find projects that need your help