CONTRIBUTING.md

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