Contributing to Redmine

How to report bugs, request features, and submit patches to the Redmine project.

Redmine is an open-source project managed through its own instance at redmine.org. The canonical source repository is hosted on Subversion (SVN) at svn.redmine.org, not on GitHub. The GitHub mirror is read-only — pull requests opened there are not monitored by core developers.

Do not open pull requests on GitHub. They will not be reviewed. Use the official issue tracker at redmine.org instead.

Ways to contribute

Report a bug

Open a defect issue on the official tracker so the team can reproduce and fix it.

Request a feature

Submit a feature request describing the problem you want solved and your proposed solution.

Submit a patch

Attach a .patch file to an existing issue or open a new one dedicated to your change.

Improve documentation

Edit the wiki pages on redmine.org or help translate the interface strings.

Issue tracker workflow

All contributions flow through the Redmine issue tracker at redmine.org/projects/redmine.

1. Search for existing issues

   Before opening anything new, search the tracker. Your bug or idea may already be reported, and adding a comment or vote is more useful than a duplicate.

2. Open an issue

   Choose the correct tracker type:

   • Bug — something that does not work as documented
   • Feature — a new capability you would like added
   • Patch — a code change ready for review

   Fill in the subject, description, and any relevant version or environment details.

3. Attach your patch (if applicable)

   Generate a patch from your local SVN or Git checkout and attach the file directly to the issue. See Submitting a patch below.

4. Follow up

   Watch the issue for feedback from core developers. Be prepared to revise your patch if requested.

Reporting bugs

A good bug report lets a developer reproduce the problem without guessing. Include:

• Redmine version (e.g., 6.0.2)
• Ruby and Rails versions
• Database adapter (MySQL, PostgreSQL, SQLite)
• Steps to reproduce
• Expected behaviour vs. actual behaviour
• Any relevant log output from log/production.log

Run bundle exec rake redmine:info to print environment details you can paste directly into the issue.

Requesting features

When requesting a feature, explain the problem first, then your proposed solution. Core developers may have a different implementation in mind, and framing the need separately helps the discussion stay productive.

For the full contribution guidelines and wiki, see redmine.org/projects/redmine/wiki/Contribute.

Submitting a patch

Get the source

The canonical repository is on Subversion:

svn co https://svn.redmine.org/redmine/trunk redmine

You can also work from the GitHub mirror for convenience, then produce a unified diff:

git clone https://github.com/redmine/redmine.git

Generate a patch

SVN

# From inside your working copy
svn diff > my_fix.patch

Attach my_fix.patch to the relevant issue on redmine.org.

Patch checklist

Before attaching a patch, verify:

• All existing tests pass: bundle exec rake test
• New behaviour is covered by tests
• RuboCop reports no new offences: bundle exec rubocop [changed files]
• Commit message (or patch description) clearly explains why the change is needed
• The patch applies cleanly against the current trunk

Coding style

Redmine follows the Ruby Style Guide. Compliance is enforced by RuboCop with project-specific configuration in .rubocop.yml.

RuboCop configuration

The project targets Ruby 3.2 and Rails 8.0. The active plugins are:

Plugin	Purpose
rubocop-performance	Performance-related cops
rubocop-rails	Rails-specific cops

The following paths are excluded from RuboCop checks:

• vendor/, tmp/, bin/
• plugins/, extra/
• db/schema.rb
• Generator templates and lib tasks

Running RuboCop

# Check all files
bundle exec rubocop

# Check specific files
bundle exec rubocop app/models/issue.rb app/controllers/issues_controller.rb

Run RuboCop against only the files you changed to keep the output focused. Fixing pre-existing offences in unrelated files makes patches harder to review.

CSS linting with Stylelint

If your patch touches CSS files, run Stylelint as well. You need Node.js and Yarn installed.

# Install dependencies (first time only)
yarn install

# Lint all CSS
npx stylelint "app/assets/stylesheets/**/*.css"

Commit message guidelines

Write commit messages (and patch descriptions) in the imperative mood:

Fix issue list not refreshing after bulk status update

When multiple issues were updated via the bulk-edit form, the list view
was not re-querying the database before rendering, causing stale data
to appear. Force a fresh query after the bulk update completes.

• Subject line: 50 characters or fewer, imperative mood, no trailing period
• Body (optional): wrap at 72 characters, explain what and why, not how
• Reference the issue number where applicable: Fixes #12345

Further reading

Contribute wiki

Full contribution guidelines on the official Redmine wiki.

Running tests

Set up the test database and run the full test suite before submitting a patch.