Bug Squad Coding Team
From Joomla! Documentation
The coding team works with Confirmed issues and creates patches to correct these issues if they haven't already been provided. When a patch is completed, and when a test plan has been added that tells the testers how to test the patch, the issue is changed to Pending status.
Many times the first patch submitted for an issue will not be the actual patch that is committed. There are many reasons for this. Someone else may have a different approach to the solving the issue, a tester might find a problem, or the person who submitted the patch will think of a better way to do it.
It is important to be positive and flexible and not expect that every patch you submit will go straight into the SVN. That does not mean the work is not helpful or valuable. In many cases, it is not possible to get to the result without going through one or more tries.
The "Golden Path" for any issue (which are usually bugs but can sometimes be other things) in any Joomla release is that it moves through the following stages:
Open → Confirmed → Pending → Ready to Commit → Fixed in Master
The Coding Team is responsible for the part of the process that moves issues from Confirmed to Pending. If the bug squad was run like a hospital, the coding team is like the doctors and specialists that perform surgery on patients that have come up from the emergency room triage.
To be involved in the Coding Team you should either know, or be prepared to learn:
- The PHP programming language
- SQL syntax
- Version control using GitHub
- How to create, apply and analyse a "patch file"
- The basic principles of Object Oriented Programming (OOP)
Does that sound a bit scary? If it does, it boils down to if you want to be a part of the coding team, you need to have some programming skills. If you are a beginner programmer, the Coding Team is going to be like going to the gym regularly. You'll start out very sore and your brain will probably hurt, but after a while those bugs are going to be no match for you. Stick with it and you'll come out of your tour of duty with some pretty serious programming punch, not to mention a wealth of experience passed down from other Joomla Jedi masters.
The Testing Team has gone before you ensuring that issues move to Confirmed are the real deal (as far as they can tell). As a member of the Coding Team, 99% of your work will be to devise a code patch to rectify the issue that has been raised. You also need to include a test plan so that the people that follow you actually know how to work out whether the issue has been fixed. Once you do this, you'll upload the patch to the issue and then set the status to Pending. When this happens the Testing Team will pick up your patch and make sure that it applies without any conflicts, and then follow your test plan to verify the patch does the job. All going well, the Testing Team will then promote the issue to Ready to Commit and you can start to relax and think about shore leave--after you've finished all the other issues of course.
It's entirely possible that things will go this smoothly, but just as often they don't.
Sometimes you will need to ask for more information from the person that raised the issue if the root cause of the problem is not immediately obvious. This could be a short conversation, or it could go on for quite some time depending on the complexity of the issue. If you begin to enter into a long dialogue, it is advisable to change the status to In Progress.
Sometimes an issue just seems impossible to work out, or you might be concerned that your patch is going to have side effects on other parts of the framework. In this case, change the status to Needs review and one of the Joomla Jedi's will take a look and see if they can assist with the problem.
Whenever a problem is being solved in the framework (those are all the files under the /libraries/ folder), you are encouraged to write or update the Unit Tests for the part of the code you are fixing. This is not always possible but should always be attempted.
When you are making changes to layouts, you need to be mindful that both Frontend and Backend templates use layout overrides. In Joomla 1.6, Beez5 on the Frontend uses layout overrides to provide HTML5 support and Hathor in the Backend uses layout overrides extensively to provide accessibility support. When you make patches to layouts make sure that you do any related layouts in the core templates as well.
Members of the Coding Team also need to be disciplined and have attention to detail. Joomla has a strong tradition of following a published coding style, and it is your job to ensure it is upheld. Beautiful code is easier to read and easier to debug. Always be mindful that you are in a team, and that team involves the future generations of Joomla developers that you haven't even met yet (and sometimes even your future self).