Become a Mautic Developer (Part 1)
Are you ready to take your code skills to the next level? Or are you a brand new developer to Mautic and ready to start digging in deeper? Regardless of your skills or where you currently are in your developer life there is a place for you in Mautic. Ready to learn more about Mautic development and how you can become a genuine Mautician? Keep reading.
There are many different types of Mauticians (those amazing people who contribute to Mautic) and you can become one of them. We promise it’s not hard. Before we get into some of the specifics of Mautic developers we should very quickly offer a disclaimer:
Mauticians are all those volunteers and contributors to our community. Developers and Testers are only a single of those types of people; and we as a community recognize there are many invaluable roles. This particular article will focus on how you can become engaged in the Mautic community as a Testing Mautician. This role is invaluable as you are the driving force to ensure Mautic improves, and becomes even more amazing in the future. Your time, dedication to excellence, and focus on our mission is critical to our success. You ensure Mautic is the highest quality.
Everything begins with the code when you’re working in a developer role. With Mautic, we believe code is beautiful. In fact, we believe the code (that most will never see) is the most important part of our product. Beauty from the inside out. This means your first step is to become familiar with GitHub and learn what all it offers and does. If you haven’t done this before take the time now to learn about code repositories and online hosted solutions (like GitHub, Bitbucket and others). You’ll want to understand forking, branches, commits, merges, and all those other fun words. If you know them already then skip right on ahead to the next step. (And if you want more in-depth stuff you can research cherry-picking, rebasing, hashes, soft vs. hard resets, and more.)
Issues & Pull Requests
Once you understand the bare minimum basics of code repositories (GitHub since that’s what Mautic uses) then the next step is to look at the issues and pull requests associated with the code. This is where you have a choice. If you’re feeling especially code-focused you can read through issues find one that needs a solution and start writing code. If you would rather learn by reviewing other’s code then turn to the pull requests. In the pull request section you’ll find issues that other developers have already attempted to solve by writing code. Here you get to start helping immediately. This article doesn’t focus on the details required for getting your account setup and the necessary steps you will need to take for actually testing these pull requests and fixes. We will save that for a future post, however, this will give you a great overview of the different labels used in the system and provide a good high-level view of beginning this very exciting journey.
You’re moving so quickly towards becoming a Mautic Tester! You must take the basics of code repositories, issues, and pull requests and put them to use. When you look at the list of pull requests waiting to be tested you will find most of them have a number of labels attached to them. These labels allow you to quickly see what status each pull request holds and what is required next. Here are the important labels you will want to look for:
One of the biggest challenges when working with a codebase like Mautic is the correct terminology and labeling system to use. Obviously an experienced developer may be highly skilled but new to Mautic-related code and thus is not a “new developer” but “new to Mautic developer”. We attempt to solve this with the following level system.
This first label we are going to look for is the L1, or Level 1, label. This label defines those pull requests which can take a relatively short time to test and does not require significant developer experience. In this way both experienced developers with limited time, and new developers alike can find and test these types of issues.
This is the second label to recognize. This label L2, or Level 2, identifies those pull requests which require slightly more time and become slightly more in-depth from a code-knowledge and testing perspective. These pull requests may require additional items to be created for testing (e.g. campaigns, emails, landing pages).
The third label we examine is the L3 or Level 3. This label identifies pull requests which require either a longer time period for testing or advanced developer skills. Typically this may involve things related to command-line interfaces, code modifications for testing, and third-party service configurations to test.
- Bug: This solves a problem in the code which keeps Mautic from working properly.
- Code Review: This is submitted code which may not yet meet Mautic code standards or generally needs community review before being committed.
- Duplicate: Another pull request already addresses this same issue.
- Feature Request: This does not fix a problem in the code but instead improves Mautic’s functionality.
- FR – Integration: This is a feature request related to a specific integration.
- Pending Feedback: This label is used when an issue requires additional details from the submitter based on comments raised.
- Pending Test Confirmation: All pull requests require two successful tests before being merged. These issues require a second test.
- Ready to Commit: This issue has been successfully tested and is ready to be committed.
- Ready to Test: This is a submitted pull-request ready to be tested by the community.
- Translations: This is for all issues related to language translations.
- User Interface: This is for issues specifically related to the user interface or design aspects of Mautic.
Go Forth and Code!
This is all the knowledge you need to start on your journey to becoming a Mautic Developer and a part of the Mautic community. We are excited that you have chosen to spend your time contributing here with us and we welcome you as a fellow Mautician!