1Guidelines
2==========
3
4When contributing to the Mono project, please follow the [Mono Coding
5Guidelines][1].  We have been using a coding style for many years,
6please make your patches conform to these guidelines.
7
8[1]: http://www.mono-project.com/community/contributing/coding-guidelines/
9
10Etiquette
11=========
12
13In general, we do not accept patches that merely shuffle code around,
14split classes in multiple files, reindent the code or are the result
15of running a refactoring tool on the source code.  This is done for
16three reasons: (a) we have our own coding guidelines; (b) Some modules
17are imported from upstream sources and we want to respect their coding
18guidelines and (c) it destroys valuable history that is often used to
19investigate bugs, regressions and problems.
20
21License
22=======
23
24The Mono runtime, compilers, and tools and most of the class libraries
25are licensed under the MIT license. But include some bits of code
26licensed under different licenses. The exact list is [available here] (https://github.com/mono/mono/blob/master/LICENSE).
27
28Different parts of Mono use different licenses.  The actual details of
29which licenses are used for which parts are detailed on the LICENSE
30file in this directory.
31
32CLA
33=======
34
35Contributions are now taken under the [.NET Foundation CLA] (https://cla2.dotnetfoundation.org/).
36
37Testing
38=======
39
40Pull requests go through testing on our [Jenkins server][2]. We will
41usually only merge a pull request if it causes no regressions in a
42test run there.
43
44When you submit a pull request, one of two things happens:
45
46* If you are a new contributor, Jenkins will ask for permissions (on
47  the pull request) to test it. A maintainer will reply to approve
48  the test run if they find the patch appropriate. After you have
49  submitted a few patches, a maintainer will whitelist you so that
50  all of your future pull requests are tested automatically.
51* If you are a well-known, whitelisted contributor, Jenkins will go
52  ahead and test your pull request as soon as a test machine is
53  available.
54
55When your pull request has been built, Jenkins will update the build
56status of your pull request. If it succeeded and we like the changes,
57a maintainer will likely merge it. Otherwise, you can amend your pull
58request to fix build breakage and Jenkins will test it again.
59
60[2]: http://jenkins.mono-project.com/
61
62# Inactivity
63
64Occasionally, a pull request sits for several months without any
65response from the author. This isn't necessarily an issue, but we may
66sometimes decide to close pull requests that have not seen any
67progress for a long time. This is in interest of keeping the pull
68request list clean so that other pull requests don't get lost in the
69clutter.
70
71If we do close your pull request due to inactivity, you're more than
72welcome to submit it anew after you address any comments or issues that
73were brought up on the original pull request.
74