Merge requests are often rejected for similar reasons.

Growing Rails Applications in Practice

Check out our e-book. Learn to structure large Ruby on Rails codebases with the tools you already know and love.

• Introduce design conventions for controllers and user-facing models
• Create a system for growth
• Build applications to last

Read more Show archive.org snapshot

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 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.)