]> git.openstreetmap.org Git - rails.git/blob - CONTRIBUTING.md
Localisation updates from https://translatewiki.net.
[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 Rails port 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 hacking, 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 rake test
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 with the
42 results shown on [Travis CI](https://travis-ci.org/openstreetmap/openstreetmap-website).
43
44 ## Comments
45
46 Sometimes it's not apparent from the code itself what it does, or,
47 more importantly, **why** it does that. Good comments help your fellow
48 developers to read the code and satisfy themselves that it's doing the
49 right thing.
50
51 When hacking, you should:
52
53 * Comment your code - don't go overboard, but explain the bits which
54 might be difficult to understand what the code does, why it does it
55 and why it should be the way it is.
56 * Check existing comments to ensure that they are not misleading.
57
58 ## i18n
59
60 If you make a change that involve the locale files (in `config/locales`) then please
61 only submit changes to the `en.yml` file. The other files are updated via
62 [Translatewiki](https://translatewiki.net/wiki/Translating:OpenStreetMap) and should
63 not be included in your pull request.
64
65 ### Nominatim prefixes
66
67 I18n keys under the `geocoder.search_osm_nominatim` keyspace are managed by the
68 Nominatim maintainers. From time to time they run stats over the Nominatim
69 database, and update the list of available keys manually.
70
71 Adding or removing keys to this list is therefore discouraged, but contributions
72 to the descriptive texts are welcome.
73
74 ## Code Documentation
75
76 To generate the HTML documentation of the API/rails code, run the command
77
78 ```
79 rake doc:app
80 ```
81
82 ## Committing
83
84 When you submit patches, the project maintainer has to read them and
85 understand them. This is difficult enough at the best of times, and
86 misunderstanding patches can lead to them being more difficult to
87 merge. To help with this, when submitting you should:
88
89 * Split up large patches into smaller units of functionality.
90 * Keep your commit messages relevant to the changes in each individual
91 unit.
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 ## Sending the patches
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 Otherwise you should either push your changes to a publicly visible git repository
109 and send the details to the [rails-dev](https://lists.openstreetmap.org/listinfo/rails-dev)
110 list or generate patches with `git format-patch` and send them to the
111 [rails-dev](https://lists.openstreetmap.org/listinfo/rails-dev) list.