Our GSoC student Reda Muhamed asked: How does Joomla work? How does an idea actually find its way into the Joomla core? The answer is surprisingly interesting. It all starts with an issue on GitHub. See how many steps are necessary and how many people -  users, testers, developers, maintainers, release managers and more - are involved until a new feature or bug fix finds his way into the Joomla core.

You have an idea how Joomla could be improved? Or you think you found a bug? Then you can open an issue on GitHub. GitHub is the place where Joomla is built. If you want to contribute yourself, you need a GitHub account.  

The issue

Anyone can open an issue and describe an idea or a bug and every issue starts an avalanche! 

When the issue is submitted it appears in the issue list on GitHub and everyone can read and comment on it. Some users could try to replicate the issue on their own site, they can ask for more information and discuss the problem, confirm the issue or applaud your idea in the comments. 

The Bug Squad

Issues are different. Some are very simple, such as a typo in an error message. Others require deep technical knowledge and extensive debugging. 

This is where the Joomla Bug Squad comes in. The members of this team know how to debug and replicate issues, they decide if an issue is valid and classify it. If it is a bug they investigate: Is it old or new? How is the impact, how many installations are affected? 
If the issue is classified as a feature request, it moves into the feature workflow. Sometimes the decision is not easy and there are controversial discussions.

The Feature workflow 

While bugs need  to be resolved sooner or later, feature requests require additional discussion and approval. 

The team of maintainers evaluates every feature request:
Is it a good feature Joomla should include? Will it cause a break in backward compatibility (b/c)? This means the feature has an impact on existing Joomla sites and could affect 3rd party extensions.

Maintainers regularly discuss such topics in dedicated meetings before making a decision.
Some feature requests are rejected. If a feature request is accepted, it is in the waiting queue, sometimes for a longer time until a developer takes care of it.

Development – Pull Request (PR)

If a  bug has been confirmed, then someone needs to write the code. Any developer can contribute code to Joomla. Of course, no user can change the Joomla code, but anyone can suggest changes and make a Pull Request (PR). 

Sometimes it is easy – for example fixing a typo in a comment. Sometimes it is very difficult – first to find what happens, then to write the code following all requirements of code conventions and coding concepts of Joomla. If you think: nothing is difficult with Vibe Coding! then please first ask chatGPT "why is vibe coding a bad idea for PRs in Joomla"? 

Quality Checks - Maintainers 

Automatic Tests

As soon as your PR is submitted, automatic tests start running. There is a special team in Joomla, the Automatic Testing Team, which is responsible for managing test tools. If all the automatic tests were successful, the system generates packages which contain the changes of the PR. Users can download these packages for testing.

If these automatic tests find errors in the code the test fails and the developer is asked to fix the error.

Code Review

Maintainers check the code in a review if it is convenient to the Joomla standards. They can approve the code or make suggestions for improvement and ask for an update.

User tests

Anyone can test any PR. Some tests are very easy, some need a special preparation and environment (for example a a multilingual site with thousands of articles), some are so difficult that only developers can do it.
How to test is not in scope of this article. But you should know that user tests are a bottleneck in joomla development. Fortunately there are some users who like testing and help a lot, there is a PR testing group on  Mattermost and there are Pizza , Bugs and Fun events. Join us! 

Enjoy this article: Confessions of an Open Source Tester

Tests must be confirmed in the joomla issue tracker and it is such a great feeling to press the „Tested“ button on the Issues tracker!

Ready to Commit

As soon as there are two successful tests on the issue tracker, a member of the bug squad or maintainer team can set the PR to RTC (Ready to Commit). If it is a difficult and big PR with many code changes or if something in the PR is not quite clear, this RTC state can last a long time, waiting for a maintainers' and release managers' decision. 

During this time the Joomla core can be changed by other PRs, or someone finds an error in the PR then the state RTC can be removed and it goes back to the development cycle. 

Merge

A PR which is ready to commit can be merged into the Joomla Core. Here Release Managers come in. Every Joomla Version has two release managers. At the end they decide if a PR can be merged in which version. 

Joomla versions follow a strict rule (aka SEMVER). At the moment (June 2026) we have:

• 5.4.x   is still supported. It gets all bug fixes.
• 6.1.x   is the official stable version, it gets all bug fixes.
• 6.2     is in development. It will replace 6.1 at the next stable release. It can contain code enhancements and small new features which don’t break backward compatibility.
• 7.0     is prepared for development. All new features which can break backward compatibility are developed for this version. 

Documentation

If your PR has an impact on the user site, for example a new input field on a form, the user documentation and the help screen for this form need to be changed accordingly. 

If the PR adds a new class or method to the core, the developer documentation needs to be expanded. 

Translation

Did the PR add new language keys into the core? Then the translation team becomes active. As many translators as Joomla has languages have to translate new messages. 

Release Team

Releases are perfectly organised. A Joomla release does not jump on stage without preparation. Release managers prepare up to three  -alpha and  -beta Versions and release candidates (rc) before a Joomla Version can come out.
The CMS Release Team performs tests on all these builds . They check if all the merged PRs work not only in separated tests but also in combination with the whole application. 
And (this is top secret) they also test security fixes which are added by the Security Strike Team. 

And now - tadaa - the Release

Finally - the next stable release is built in a release party on mattermost. Every community member can join and watch the release! If your PR was merged or if you have tested a PR, you are a proud Joomla contributor and your name will appear on the release document, for example this one for 6.1.1

Congratulations! 

And now: Did you count how many people are working for a single PR?