Home Explore Blog CI



rustc

3rd chunk of `src/getting-started.md`
da9121c1f68c32066d59042fa3f9ff506ba53608c6daf9010000000100000ce0
The [Clippy] project has spent a long time making its contribution process as friendly to newcomers
as possible. Consider working on it first to get familiar with the process and the compiler
internals.

See [the Clippy contribution guide][clippy-contributing] for instructions on getting started.


### Diagnostic issues

Many diagnostic issues are self-contained and don't need detailed background knowledge of the
compiler. You can see a list of diagnostic issues [here][diagnostic-issues].


### Picking up abandoned pull requests

Sometimes, contributors send a pull request, but later find out that they don't have enough
time to work on it, or they simply are not interested in it anymore. Such PRs are often
eventually closed and they receive the `S-inactive` label. You could try to examine some of
these PRs and pick up the work. You can find the list of such PRs [here][abandoned-prs].

If the PR has been implemented in some other way in the meantime, the `S-inactive` label
should be removed from it. If not, and it seems that there is still interest in the change,
you can try to rebase the pull request on top of the latest `master` branch and send a new
pull request, continuing the work on the feature.


### Writing tests

Issues that have been resolved but do not have a regression test are marked with the `E-needs-test` label. Writing unit tests is a low-risk, lower-priority task that offers new contributors a great opportunity to familiarize themselves with the testing infrastructure and contribution workflow.

### Contributing to std (standard library)

See [std-dev-guide](https://std-dev-guide.rust-lang.org/).

### Contributing code to other Rust projects

There are a bunch of other projects that you can contribute to outside of the
`rust-lang/rust` repo, including `cargo`, `miri`, `rustup`, and many others.

These repos might have their own contributing guidelines and procedures. Many
of them are owned by working groups. For more info, see the documentation in those repos' READMEs.

### Other ways to contribute

There are a bunch of other ways you can contribute, especially if you don't
feel comfortable jumping straight into the large `rust-lang/rust` codebase.

The following tasks are doable without much background knowledge but are
incredibly helpful:

  regressions, etc. This is a way of helping that saves a ton of time for
  others to fix an error later.
  to read a part of the code and write doc comments for it. This will help you
  to learn some part of the compiler while also producing a useful artifact!
  of rust-related things.
- Answer questions in the _Get Help!_ channels on the [Rust Discord
  server][rust-discord], on [users.rust-lang.org][users], or on
  [StackOverflow][so].
- Participate in the [RFC process](https://github.com/rust-lang/rfcs).
- Find a [requested community library][community-library], build it, and publish
  it to [Crates.io](http://crates.io). Easier said than done, but very, very
  valuable!


## Cloning and Building

See ["How to build and run the compiler"](./building/how-to-build-and-run.md).

## Contributor Procedures

This section has moved to the ["Contribution Procedures"](./contributing.md) chapter.

## Other Resources

This section has moved to the ["About this guide"][more-links] chapter.


Title: Various Ways to Contribute to Rust
Summary
This section outlines several ways to contribute to the Rust project, beyond just coding for the main repository. It highlights contributing to Clippy, diagnostic issues, picking up abandoned pull requests, writing tests, contributing to the standard library, and contributing to other Rust projects. It also includes non-coding contributions like reporting bugs, adding documentation, triaging issues, answering questions on community platforms, participating in the RFC process, and building community libraries. Finally, it gives pointers to external guides on how to build the compiler.