Remember from the movie way back in the eighties: “If there's something weird, and it don't look good, who you gonna call? Ghostbusters!”? In Joomla we have our own ghostbusters. They’re called the Bug Squad, our own special forces, fixing weird things that don’t look good and other stuff that is broken. But who are these people? What do they do? And could you be one of them? Read and know!
What is the team’s main goal?
Jacob Waisner: The team’s goal is to reduce the number of bugs in Joomla. There is more to that however. We also triage issues to determine if they are actually bugs and work with release leads to coordinate bug fixes based on priority.
Richard Fath: Our mission is to reduce the number of bugs in Joomla, as stated at the volunteers portal.
But everybody who has experience in huge software projects knows that this is a never ending job, a mission impossible, a Sisyphus task. Every bigger piece of non-trivial code will have bugs, and even bug fixes can introduce new bugs.
So our goal cannot be to have zero bugs, because that would mean we won’t touch the code for anything else than bug fixes. No enhancements, no new features, no new PHP versions supported, and then one day in a far away future you might have zero bugs of which you know but there still might be left the unknown ones.
The goal can only be to keep the number of bugs as small as we can. Therefore we want to manage bugs as well as possible so that they are quickly sorted out from other issues like e.g. enhancements and solved in a reasonable time.
What is your place in Joomla’s ecosphere?
Richard: We are part of the production department.
What roles do you have within the team?
Richard: Besides the "normal" team members, we have all release leads in our team so we have a quick communication channel with them.
Team members: introduce yourself please!
Jacob Waisner (team leader): I started contributing to Joomla back in 2015 and began just triaging issues reported. Real life kept me away for a while shortly after that point. I was able to rejoin the team back in 2020. Although I don't specialize in a coding language I work to test PRs as well as triage issues in the tracker.
Richard Fath (assistant team leader): After becoming a frequent contributor over the years, I was asked in May 2019 to join the team. Some months ago Jacob asked me to be the assistant team lead, and I agreed, so I help a bit with team meetings when he has no time. Apart from that I share my knowledge on database, update and installation related topics and on Git and GitHub.
Christiane Maier-Stadtherr: I joined the team after a series of tests and pull requests which I had made for Joomla 3 in 2019 if I remember correctly. I am doing the same as every other member: check new (and old) issues, sometimes write a solution, test PRs, mainly for the user interface.
Nicola Galgano: I've been a member of this team for quite some time, I've had the honor to lead this team for a couple of years, I'm mainly sharing my expertise on sql, web services and cli matters mostly.
Troy Hall: I’m known as “Bear” or N6REJ and have been a JBS member since 2010. I tend to forget things but luckily the team puts up with it. My main place is testing reported bugs or when I find one I try to track down it's root cause and fix it. I’m passionate about our iconography & multi-media handling.
Rick Spaan: Last year I got more involved in contributing code when there were some bugs in the Cassiopeia template. Because I was creating my own template framework based on Cassiopeia I needed some things to be fixed. In the process of fixing things, I also started to do a lot of patch testing as many of the annoyances were addressed in other Pull Requests. My activities didn’t go unnoticed and Richard asked me to join the team which I happily did. I've been a team member for 3 months now and it is nice to be a member of such a devoted team! My passion is frontend development and I hope my expertise is a nice addition to the team.
How often do you have meetings, and how do they take place?
Jacob: We hold our meetings every 2 weeks via Glip and they take place with a basic agenda open to all team members to add any topic they wish to discuss.
What tools do you use to work together?
Richard: We use our team channel on Glip for text chat in our biweekly meetings and whenever we need to talk with other team members, and public channels on Glip e.g. to ask the community for testing pull requests or making announcements. Issues and pull requests we manage on GitHub and in the issue tracker.
If you had three words to describe the atmosphere within the team, what would those words be?
Troy: Helpful, non-judgemental, friendly
Richard: Collaborative, helpful, friendly
Nicola: Per aspera ad astra (JCM: this roughly translates as “through hardships to the stars”)
Christiane: Helpful, professional, demanding
Jacob: Professional, collaborative, passionate
Rick: Dedicated, open, cooperative
How did the team develop over the last year(s)?
Troy: For several years the team was basically dead. With the membership it has currently, it is once again alive and contributes heavily to the growth of Joomla!
Richard: I did not watch the team activity much before I joined in April 2019, but I think Troy is right and the team was not very active for a while before that time. At that time Nicola had started as team lead and had invited new members like me and so brought it to its current activity level. Thanks Nicola for that.
Jacob: As mentioned by other team members, activity was waning. With the focus now on bringing in new members with a wide set of skills, ranging from programming to being able to test PRs we have seen an uptick in activity. Additional coordination with the Release leads has also helped us stay in line and provide the needed support for each release in a more efficient manner.
What do you consider your biggest challenge? What would be needed to fix this?
Troy: There is too much old/contradictory documentation on setting up a modern develop server and associated programs for contributing code to Joomla!
A very detailed step by step guide, including code compliance, needs to be done for each of the major ide's used. PHPStorm, Visual studio code would be the top 2 I would imagine.
Christiane: The work is often time consuming and demanding. We have to check every issue and PR. We need to establish if something is a valid issue or not, if a test is a valid test or not. Sometimes it is very easy, sometimes special knowledge and much time is required. Biggest challenge are the issues that are not clear and cannot be replicated.
Do you need extra volunteers, and if so, in what capacities?
Jacob: Volunteers are always needed. This does not necessarily mean you need to be part of the team to contribute. We have many issues as well as PRs that can use someone to validate and test. If you have programming skills there are plenty of issues that need assistance.
Richard: We can never have enough volunteers. But like Jacob says, you do not necessarily need to be a team member. Most urgently we need people who test fixes for bugs and issues, so-called “pull requests”, on GitHub.
Troy: Documentation is heavily needed. There is too much "voodoo" that goes on especially given the dramatic changes in architecture that has occurred in the last 2 years.
Rick: There is this misconception that only a hardcore developer can help with testing patches. A lot of the patches can easily be tested by integrators or even users. The problem is that testing instructions are not always as clear as they should be, which could be discouraging. Therefore writing good testing instructions is really important. The challenge now is to convince people that starting to test patches isn’t hard and fun to do.
Also the JUG’s can play an important role in helping to test patches. I would encourage every JUG to make a patch testing session a part of their regular program.
If we want to help you, how could we do that? Occasionally, or by joining the team, or maybe both?
Richard: You can help us by reporting issues on GitHub and in the issue tracker, commenting on issues if you can help with investigation, creating pull requests on GitHub or testing other people’s pull requests.
If you do that occasionally it’s fine, but of course we are happy if you find the time to do that more regularly.
If the latter is the case, we will notice your GitHUb activity after a while, and our team lead will send you an invitation to join our team.
As a team member you would - in addition to your ongoing contribution - help us with the “management” stuff like setting pull requests to RTC (ready to commit, i.e. ready to be merged into the source code) when they have 2 successful human tests or assigning them labels to better categorize them.
Anybody who reports issues can be most helpful when doing as follows:
- Give your issue a meaningful title, provide the necessary details and stay responsive for clarifications, so check your email from time to time for mail from GitHub about your issue. Not just post an issue and go away.
- Not everything which does not work as you expect is a bug. The definition of a bug is that the software does not behave as desired by the programmer. The word “bug” in this context comes from old times of vacuum tube computers when real bugs were causing short circuits so the computer calculated strange results. So don’t give your issue a title like “Bug in Joomla” when it’s just about a UX issue which could be an improvement or just a matter of taste.
- Be available to test a fix (pull request) for your issue. Often it needs a certain environment or configuration or data to be able to reproduce an issue, and since you have run into the issue, you have that all. If possible make a full backup (files and database) which you later can use on a subdomain or a local testing environment to reproduce the issue and test the fix. Each pull request needs 2 successful human tests, so with your test it will already have 50% of the required tests.
Troy: Detailed, easily searchable articles on code changes.
