]> git.openstreetmap.org Git - rails.git/blob - CONTRIBUTING.md
Merge remote-tracking branch 'upstream/pull/3804'
[rails.git] / CONTRIBUTING.md
1 * https://www.ruby-lang.org/ - The homepage of Ruby which has more links and some great tutorials.
2 * http://rubyonrails.org/ - The homepage of Rails, also has links and tutorials
3
4 ## Coding style
5
6 We use [Rubocop](https://github.com/rubocop-hq/rubocop) (for ruby files)
7 and [ERB Lint](https://github.com/Shopify/erb-lint) (for erb templates)
8 to help maintain consistency in our code. You can run these utilities during
9 development to check that your code matches our guidelines:
10
11 ```
12 bundle exec rubocop
13 bundle exec rake eslint
14 bundle exec erblint .
15 ```
16
17 ## Testing
18
19 Having a good suite of tests is very important to the stability and
20 maintainability of any code base. The tests in the `openstreetmap-website` code are
21 by no means complete, but they are extensive, and must continue to be
22 so with any new functionality which is written. Tests are also useful
23 in giving others confidence in the code you've written, and can
24 greatly speed up the process of merging in new code.
25
26 When contributing, you should:
27
28 * Write new tests to cover the new functionality you've added.
29 * Where appropriate, modify existing tests to reflect new or changed
30 functionality.
31 * Never comment out or remove a test just because it doesn't pass.
32
33 You can run the existing test suite with:
34
35 ```
36 bundle exec rails test:all
37 ```
38
39 You can view test coverage statistics by browsing the `coverage` directory.
40
41 The tests are automatically run on Pull Requests and other commits via github
42 actions. The results shown are within the PR display on github.
43
44 ## Static Analysis
45
46 We also perform static analysis of our code. You can run the analysis yourself with:
47
48 ```
49 bundle exec brakeman -q
50 ```
51
52 ## Comments
53
54 Sometimes it's not apparent from the code itself what it does, or,
55 more importantly, **why** it does that. Good comments help your fellow
56 developers to read the code and satisfy themselves that it's doing the
57 right thing.
58
59 When contributing, you should:
60
61 * Comment your code where necessary - explain the bits which
62 might be difficult to understand what the code does, why it does it
63 and why it should be the way it is.
64 * Check existing comments to ensure that they are not misleading.
65
66 ## i18n
67
68 If you make a change that involve the locale files (in `config/locales`) then please
69 only submit changes to the `en.yml` file. The other files are updated via
70 [Translatewiki](https://translatewiki.net/wiki/Translating:OpenStreetMap) and should
71 not be included in your pull request.
72
73 ### Nominatim prefixes
74
75 I18n keys under the `geocoder.search_osm_nominatim` keyspace are managed by the
76 Nominatim maintainers. From time to time they run stats over the Nominatim
77 database, and update the list of available keys manually.
78
79 Adding or removing keys to this list is therefore discouraged, but contributions
80 to the descriptive texts are welcome.
81
82 ## Committing
83
84 When you submit your changes, the project maintainers have to read them and
85 understand them. This is difficult enough at the best of times, and
86 misunderstanding commits can lead to them being more difficult to
87 merge. To help with this, when committing you should:
88
89 * Split up large commits into smaller units of functionality.
90 * Keep your commit messages relevant to the changes in each individual
91 commit.
92
93 When writing commit messages please try and stick to the same style as
94 other commits, namely:
95
96 * A one line summary, starting with a capital and with no full stop.
97 * A blank line.
98 * Full description, as proper sentences with capitals and full stops.
99
100 For simple commits the one line summary is often enough and the body
101 of the commit message can be left out.
102
103 ## Pull Requests
104
105 If you have forked on GitHub then the best way to submit your patches is to
106 push your changes back to GitHub and then send a "pull request" on GitHub.
107
108 If your pull request is small, for example one or two commits each containing
109 only a few lines of code, then it is easy for the maintainers to review.
110
111 If you are creating a larger pull request, then please help the maintainers
112 with making the reviews as straightforward as possible:
113
114 * The smaller the PR, the easier it is to review. In particular if a PR is too
115   large to review in one sitting, or if changes are requested, then the
116   maintainer needs to repeatedly re-read code that has already been considered.
117 * The commit history is important. This is a large codebase, developed over many
118   years by many developers. We frequently need to read the commit history (e.g.
119   using `git blame`) to figure out what is going on. So small, understandable,
120   and relevant commits are important for other developers looking back at your
121   work in future.
122
123 If you are creating a large pull request then please:
124
125 * Consider splitting your pull request into multiple PRs. If part of your work
126   can be considered standalone, or is a foundation for the rest of your work,
127   please submit it separately first.
128 * Avoid including "fixup" commits. If you have added a fixup commit (for example
129   to fix a rubocop warning, or because you changed your own new code) please
130   combine the fixup commit into the commit that introduced the problem.
131   `git rebase -i` is very useful for this.
132 * Avoid including "merge" commits. If your PR can no longer be merged cleanly
133   (for example, an unrelated change to Gemfile.lock on master now conflicts with
134   your PR) then please rebase your PR onto the latest master. This allows you to
135   fix the conflicts, while keeping the PR a straightforward list of commits. If
136   there are no conflicts, then there is no need to rebase anything.