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 statii:
Open → Confirmed → Pending → Ready to Commit → Fixed in SVN
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, then the coding team is like the doctors and specialist 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 following:
Does that sound a bit scary? If it does, it basically 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, then 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 you 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 issuse 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 very 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 as a general rule.
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, Beez2 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 very disciplined and have good attention to detail. Joomla has a strong tradition of following a published coding style, and it is your job to ensure it is upheld at all times. 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).