CONTRIBUTING.md

   1 ## Contributing to the C++ Core Guidelines
   2
   3 >"Within C++ is a smaller, simpler, safer language struggling to get out."
   4 >-- <cite>Bjarne Stroustrup</cite>
   5
   6 The C++ Core Guidelines are a collaborative effort led by Bjarne Stroustrup, much like the C++ language itself. They are the result of many
   7 person-years of discussion and design across a number of organizations. Their design encourages general applicability and broad adoption but
   8 they can be freely copied and modified to meet your organization's needs.
   9
  10 We encourage contributions to the C++ Core Guidelines in a number of ways:
  11 - **Individual feedback** Are you a developer who is passionate about your code? Join the discussion in
  12 [Issues](https://github.com/isocpp/CppCoreGuidelines/issues). We want to know which rules resonate with you and which don't. Were any rules
  13 inordinately difficult to apply? Does your compiler vendor's Guidelines Support Library (e.g.,
  14 [Microsoft's implementation of the GSL](https://github.com/microsoft/gsl)) suit your needs in adopting these guidelines?
  15 - **Organizational adoption** While the guidelines are designed to be broadly adoptable they are also intended to be modified to fit your
  16 organization's particular needs. We encourage your organization to fork this repo and create your own copy of these guidelines with changes
  17 that reflect your needs. We suggest that you make it clear in the title of your guidelines that these are your organization's fork of the
  18 guidelines and that you provide a link back to the original set of [guidelines](https://github.com/isocpp/CppCoreGuidelines). And if any of
  19 your local changes are appropriate to pull back into the original guidelines, please open an
  20 [Issue](https://github.com/isocpp/CppCoreGuidelines/issues) which can lead to a pull request.
  21 - **Maintain the Guidelines** The C++ Core Guidelines were created from a wealth of knowledge spread across a number of organizations
  22 worldwide. If you or your organization is passionate about helping to create the guidelines, consider becoming an editor or maintainer. If
  23 you're a C++ expert who is serious about participating, please
  24 [email coreguidelines@isocpp.org](mailto:coreguidelines@isocpp.org?subject=Maintain%20the%20C++%20Code%20Guidelines).
  25
  26 ## Contributor License Agreement
  27 By contributing content to the C++ Core Guidelines (i.e., submitting a pull request for inclusion in this repository) you agree with the
  28 [Standard C++ Foundation](https://isocpp.org/about) [Terms of Use](https://isocpp.org/home/terms-of-use), especially all of the terms specified
  29 regarding Copyright and Patents.
  30 - You warrant that your material is original, or you have the right to contribute it.
  31 - With respect to the material that you own, you grant a worldwide, non-exclusive, irrevocable, transferable, and royalty-free license to your contributed
  32 material to Standard C++ Foundation to display, reproduce, perform, distribute, and create derivative works of that material for commercial or
  33 non-commercial use. With respect to any other material you contribute, such material must be under a license sufficient to allow Standard C++ Foundation
  34 to display, reproduce, perform, distribute, and create derivative works of that material for commercial or non-commercial use.
  35 - You agree that, if your contributed material is subsequently reflected in the ISO/IEC C++ standard in any form, it will be subject to all ISO/IEC JTC
  36 1 policies including [copyrights](http://www.iso.org/iso/home/policies.htm),
  37 [patents](http://www.iso.org/iso/home/standards_development/governance_of_technical_work/patents.htm), and
  38 [procedures](http://www.itscj.ipsj.or.jp/sc29/29w7proc.htm); please direct any questions about these policies to the
  39 [ISO Central Secretariat](http://www.iso.org/iso/home/about.htm).
  40
  41
  42 ## Pull requests
  43
  44 We welcome pull requests for scoped changes to the guidelines--bug fixes in
  45 examples, clarifying ambiguous text, etc.  Significant changes should first be
  46 discussed in the [Issues](https://github.com/isocpp/CppCoreGuidelines/issues)
  47 and the Issue number must be included in the pull request.  For
  48 guideline-related changes, please specify the rule number in your Issue and/or
  49 Pull Request.
  50
  51 Changes should be made in a child commit of a recent commit in the master
  52 branch.  If you are making many small changes, please create separate PRs to
  53 minimize merge issues.
  54
  55 ### Document Style Guidelines
  56
  57 Documents in this repository are written in an unspecific flavor of Markdown,
  58 which leaves some ambiguity for formatting text.  We ask that pull requests
  59 maintain the following style guidelines, though we are aware that the document
  60 may not already be consistent.
  61
  62 #### Indentation
  63
  64 Code and nested text should use multiples of 4 spaces of indentation, and no
  65 tab characters, like so:
  66
  67     void func(const int x)
  68     {
  69         std::cout << x << '\n';
  70     }
  71
  72 #### Code Blocks
  73
  74 Please use 4-space indentation to trigger code parsing, rather than [fenced code blocks](https://help.github.com/articles/github-flavored-markdown/#fenced-code-blocks) or any other style, like so:
  75
  76     This is some document text, with an example below:
  77
  78         void func()
  79         {
  80             std::cout << "This is code.\n";
  81         }
  82
  83 #### Document style decisions
  84
  85 We've discussed and made decisions on a number of document style. Please do not open PRs that revisit these stylistic points:
  86
  87 - The CppCoreGuidelines.md file is a single GH-flavored Markdown file. It is not split into separate chapters.
  88 - We do not use syntax highlighting in the Core Guidelines. See PRs #33, #96, #328, and #779. If you want syntax highlighting you
  89 can either view the "pretty" version at http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines or do your own post-processing.
  90 - We're sticking with the ASCII character set. We do not use Unicode em-dashes, Unicode spaces, or pretty quotes. Lots of people edit this file with their various text editors. ASCII is simple and universally understood.
  91
  92 ### Update dictionary
  93
  94 Code samples in the guidelines are run through a spelling checker.  Be sure to add new class and variable names to [scripts/hunspell/isocpp.dic](https://github.com/isocpp/CppCoreGuidelines/blob/master/scripts/hunspell/isocpp.dic).
  95
  96 ### Miscellaneous
  97
  98 To avoid line-ending issues, please set `autocrlf = input` and `whitespace = cr-at-eol` in your git configuration.