Community reviews

Community reviews


Mautic is an open-source project driven by a large community. If you don't feel ready to contribute code or patches, reviewing issues and pull requests (PRs) can be a great start to get involved and give back. In fact, people who "triage" issues are the backbone to Mautic's success!

Everyone can test submitted features and bug fixes. No programming skills are required. All you have to do is to follow the steps below.

Why Reviewing Is Important

Community reviews are essential for the development of Mautic, since there are many more pull requests and bug reports than there are members in the Mautic core team to review, fix and merge them.

On the Mautic issue tracker, you can find many items in a Ready To Test status:

  • Bug Reports: Bug reports need to be checked for completeness. Is any important information missing? Can the bug be reproduced?

  • Pull Requests: Pull requests contain code that fixes a bug or implements new functionality. Reviews of pull requests ensure that they are implemented properly, are covered by test cases, don't introduce new bugs and maintain backward compatibility.

Note that anyone who has some basic familiarity with Mautic and PHP can review bug reports and pull requests. You don't need to be an expert to help.

Be constructive

Before you begin, remember that you are looking at the result of someone else's hard work. A good review comment thanks the contributor for their work, identifies what was done well, identifies what should be improved and suggests a next step.

Create a GitHub account

Mautic uses GitHub to manage bug reports and pull requests. If you want to do reviews, you need to create a GitHub account and log in.

The Bug Report Review Process

The steps for the review are:

  1. Is the Report Complete?

Good bug reports contain a link to a project (the "reproduction project") created with the Symfony skeleton or the Symfony website skeleton that reproduces the bug. If it doesn't, the report should at least contain enough information and code samples to reproduce the bug.

  1. Reproduce the Bug

Download the reproduction project and test whether the bug can be reproduced on your system. If the reporter did not provide a reproduction project, create one based on one Symfony skeleton (or the Symfony website skeleton).

  1. Leave a comment

At last, add a comment to the bug report. Thank the reporter for reporting the bug. Here is a sample comment for a bug report that could be reproduced:

Thank you @mautibot for creating this bug report! This indeed looks like a bug. I reproduced the bug in the "kernel-bug" branch of https://github.com/webmozart/some-project.

The Pull Request Review process

Every change to Mautic core happens via PRs. Every PR must have 2 successful tests to be merged to the core and released in the next version. Testing a PR is a great way to move Mautic forward and personally improve its quality and stability.

  1. Select a PR to test.
  2. Read the description and steps to test. If it's a bug fix, follow the steps to ensure you can recreate the issue.
  3. Use the development environment (above) for testing.
  4. Apply the PR
  5. Clear cache for development environment (rm -rf app/cache/* or app/console cache:clear -e dev).
  6. Follow the steps from the PR description again to see if the result is as described.
  7. Write a comment about how the test went. If there is a problem, provide as much information as possible including error log messages.

We're planning to provide more thorough guidelines for reviewing bug reports and pull requests in the near future. If you want to contribute in the meantime, please click the "Edit this page on GitHub" link at the bottom of this page.

Found errors? Think you can improve this documentation? edit this page