CONTRIBUTING.md

   1 ## How to submit a bug report
   2
   3 If you're just reporting a bug, please see:
   4
   5 http://doc.rust-lang.org/complement-bugreport.html
   6
   7 ## Pull request procedure
   8
   9 Pull requests should be targeted at Rust's `master` branch.
  10 Before pushing to your Github repo and issuing the pull request,
  11 please do two things:
  12
  13 1. [Rebase](http://git-scm.com/book/en/Git-Branching-Rebasing) your
  14    local changes against the `master` branch. Resolve any conflicts
  15    that arise.
  16
  17 2. Run the full Rust test suite with the `make check` command.  You're
  18    not off the hook even if you just stick to documentation; code
  19    examples in the docs are tested as well! Although for simple
  20    wording or grammar fixes, this is probably unnecessary.
  21
  22 Pull requests will be treated as "review requests", and we will give
  23 feedback we expect to see corrected on
  24 [style](https://github.com/rust-lang/rust/wiki/Note-style-guide) and
  25 substance before pulling.  Changes contributed via pull request should
  26 focus on a single issue at a time, like any other.  We will not accept
  27 pull-requests that try to "sneak" unrelated changes in.
  28
  29 Normally, all pull requests must include regression tests (see
  30 [Note-testsuite](https://github.com/rust-lang/rust/wiki/Note-testsuite))
  31 that test your change.  Occasionally, a change will be very difficult
  32 to test for.  In those cases, please include a note in your commit
  33 message explaining why.
  34
  35 In the licensing header at the beginning of any files you change,
  36 please make sure the listed date range includes the current year.  For
  37 example, if it's 2014, and you change a Rust file that was created in
  38 2010, it should begin:
  39
  40 ```
  41 // Copyright 2010-2014 The Rust Project Developers.
  42 ```
  43
  44 For more details, please refer to
  45 [Note-development-policy](https://github.com/rust-lang/rust/wiki/Note-development-policy).