Before you make a merge request: Checklist for common mistakes

Updated . Posted . Visible to the public. Repeats.

Merge requests are often rejected for similar reasons.

To avoid this, before you send a merge request, please confirm that your code ...

  • has been reviewed by yourself beforehand
  • fulfills every requirement defined as an acceptance criterion
  • does not have any log or debugging statements like console.log(...), byebug etc.
  • has green tests
  • has tests for new features
  • has been manually tested in the browser
  • has no missing translations in the UI
  • has no ugly UI changes (long content breaking out of boxes, elements without margins, etc.)
  • works with lots of records without triggering a million queries or loading the world into memory¹
  • sorts all lists (indexes, select dropdowns, ...) by either sorting in the database or using natural_sort in Ruby
  • paginates long index lists
  • has all necessary database indexes to speed up foreign key look ups and commonly used queries
  • if it adds any migrations, takes care of existing records
  • if it creates any new tables, adds created_at and updated_at timestamps (t.timestamps)
  • if it makes major changes, has updated the README as appropriate

Please also add screenshots or videos of any changed UI.

¹ This should be verified in a private browsing window as you might not notice any issues on cached screens (E-Tags etc.)

Tobias Kraze
Last edit
Henning Koch
Keywords
checklist, code, review, pull, request, master
License
Source code in this card is licensed under the MIT License.
Posted by Tobias Kraze to makandra dev (2013-06-07 13:03)