2016-03-25 14:06:30 +03:00
|
|
|
# Nominatim contribution guidelines
|
|
|
|
|
2017-05-27 18:47:39 +03:00
|
|
|
## Reporting Bugs
|
2016-03-25 14:06:30 +03:00
|
|
|
|
2017-05-27 18:47:39 +03:00
|
|
|
Bugs can be reported at https://github.com/openstreetmap/Nominatim/issues.
|
|
|
|
Please always open a separate issue for each problem. In particular, do
|
|
|
|
not add your bugs to closed issues. They may looks similar to you but
|
|
|
|
often are completely different from the maintainer's point of view.
|
|
|
|
|
|
|
|
## Workflow for Pull Requests
|
|
|
|
|
2018-03-03 10:36:47 +03:00
|
|
|
We love to get pull requests from you. We operate the "Fork & Pull" model
|
2017-05-27 18:47:39 +03:00
|
|
|
explained at
|
2016-03-25 14:06:30 +03:00
|
|
|
|
|
|
|
https://help.github.com/articles/using-pull-requests
|
|
|
|
|
|
|
|
You should fork the project into your own repo, create a topic branch
|
|
|
|
there and then make one or more pull requests back to the openstreetmap repository.
|
2017-05-27 18:47:39 +03:00
|
|
|
Your pull requests will then be reviewed and discussed. Please be aware
|
|
|
|
that you are responsible for your pull requests. You should be prepared
|
|
|
|
to get change requests because as the maintainers we have to make sure
|
|
|
|
that your contribution fits well with the rest of the code. Please make
|
|
|
|
sure that you have time to react to these comments and amend the code or
|
|
|
|
engage in a conversion. Do not expect that others will pick up your code,
|
|
|
|
it will almost never happen.
|
|
|
|
|
|
|
|
Please open a separate pull request for each issue you want to address.
|
|
|
|
Don't mix multiple changes. In particular, don't mix style cleanups with
|
|
|
|
feature pull requests. If you plan to make larger changes, please open
|
|
|
|
an issue first or comment on the appropriate issue already existing so
|
|
|
|
that duplicate work can be avoided.
|
2016-03-25 14:06:30 +03:00
|
|
|
|
|
|
|
## Coding style
|
|
|
|
|
|
|
|
Nominatim historically hasn't followed a particular coding style but we
|
2018-03-03 10:36:47 +03:00
|
|
|
are in process of consolidating the style. The following rules apply:
|
2016-03-25 14:06:30 +03:00
|
|
|
|
|
|
|
* Python code uses the official Python style
|
2022-07-20 17:05:25 +03:00
|
|
|
* indentation
|
2016-03-25 14:06:30 +03:00
|
|
|
* SQL use 2 spaces
|
2016-09-05 23:13:08 +03:00
|
|
|
* all other file types use 4 spaces
|
2016-03-25 14:06:30 +03:00
|
|
|
* [BSD style](https://en.wikipedia.org/wiki/Indent_style#Allman_style) for braces
|
|
|
|
* spaces
|
|
|
|
* spaces before and after equal signs and operators
|
|
|
|
* no trailing spaces
|
|
|
|
* no spaces after opening and before closing bracket
|
|
|
|
* leave out space between a function name and bracket
|
|
|
|
but add one between control statement(if, while, etc.) and bracket
|
2018-07-21 09:47:37 +03:00
|
|
|
* for PHP variables use CamelCase with a prefixing letter indicating the type
|
|
|
|
(i - integer, f - float, a - array, s - string, o - object)
|
2016-03-25 14:06:30 +03:00
|
|
|
|
2021-01-15 11:04:04 +03:00
|
|
|
The coding style is enforced with PHPCS and pylint. It can be tested with:
|
2016-10-10 00:08:20 +03:00
|
|
|
|
|
|
|
```
|
2021-01-15 11:04:04 +03:00
|
|
|
phpcs --report-width=120 --colors .
|
2021-01-30 17:52:49 +03:00
|
|
|
pylint3 --extension-pkg-whitelist=osmium nominatim
|
2016-10-10 00:08:20 +03:00
|
|
|
```
|
2016-03-25 14:06:30 +03:00
|
|
|
|
|
|
|
## Testing
|
|
|
|
|
2021-01-09 19:57:30 +03:00
|
|
|
Before submitting a pull request make sure that the tests pass:
|
2016-03-25 14:06:30 +03:00
|
|
|
|
|
|
|
```
|
2021-01-09 19:57:30 +03:00
|
|
|
cd build
|
|
|
|
make test
|
2016-03-25 14:06:30 +03:00
|
|
|
```
|