CONTRIBUTING.md

   1 Guidelines
   2 ==========
   3
   4 When contributing to the Mono project, please follow the [Mono Coding
   5 Guidelines][1].  We have been using a coding style for many years,
   6 please make your patches conform to these guidelines.
   7
   8 [1]: http://www.mono-project.com/community/contributing/coding-guidelines/
   9
  10 Etiquette
  11 =========
  12
  13 In general, we do not accept patches that merely shuffle code around,
  14 split classes in multiple files, reindent the code or are the result
  15 of running a refactoring tool on the source code.  This is done for
  16 three reasons: (a) we have our own coding guidelines; (b) Some modules
  17 are imported from upstream sources and we want to respect their coding
  18 guidelines and (c) it destroys valuable history that is often used to
  19 investigate bugs, regressions and problems.
  20
  21 License
  22 =======
  23
  24 The Mono project uses the MIT X11, GNU LGPL version 2 and the Apache
  25 License 2.0.  We also imported some Microsoft code licensed under the
  26 open source Microsoft Public License.
  27
  28 Different parts of Mono use different licenses.  The actual details of
  29 which licenses are used for which parts are detailed on the LICENSE
  30 file in this directory.
  31
  32 When contributing code, make sure that your contribution falls under
  33 the appropriate license.  For example, contributions to code licensed
  34 under MIT/X11 code, should be MIT/X11 code.
  35
  36 The runtime (`mono/...`) is a special case.  The code is dual-licensed
  37 by Xamarin under both the GNU LGPL v2 license and is also available
  38 under commercial terms.  For the runtime, you should either sign an
  39 agreement that grants Xamarin the rights to relicense your code under
  40 other licenses other than the LGPL v2 or your contribution must be
  41 made as an MIT/X11 license which grants us the same rights, but
  42 involves no paperwork.  For the latter case, please specify on your
  43 commit(s) that you are licensing the changes under MIT/X11.
  44
  45 For other parts of the project that are dual-licensed, please state
  46 on your commit(s) what license you are contributing the changes under.
  47
  48 Testing
  49 =======
  50
  51 Pull requests go through testing on our [Jenkins server][2]. We will
  52 usually only merge a pull request if it causes no regressions in a
  53 test run there.
  54
  55 When you submit a pull request, one of two things happens:
  56
  57 * If you are a new contributor, Jenkins will ask for permissions (on
  58   the pull request) to test it. A maintainer will reply to approve
  59   the test run if they find the patch appropriate. After you have
  60   submitted a few patches, a maintainer will whitelist you so that
  61   all of your future pull requests are tested automatically.
  62 * If you are a well-known, whitelisted contributor, Jenkins will go
  63   ahead and test your pull request as soon as a test machine is
  64   available.
  65
  66 When your pull request has been built, Jenkins will update the build
  67 status of your pull request. If it succeeded and we like the changes,
  68 a maintainer will likely merge it. Otherwise, you can amend your pull
  69 request to fix build breakage and Jenkins will test it again.
  70
  71 [2]: http://jenkins.mono-project.com/
  72
  73 # Inactivity
  74
  75 Occasionally, a pull request sits for several months without any
  76 response from the author. This isn't necessarily an issue, but we may
  77 sometimes decide to close pull requests that have not seen any
  78 progress for a long time. This is in interest of keeping the pull
  79 request list clean so that other pull requests don't get lost in the
  80 clutter.
  81
  82 If we do close your pull request due to inactivity, you're more than
  83 welcome to submit it anew after you address any comments or issues that
  84 were brought up on the original pull request.