Difference between revisions of "Bug Squad Coding Team"

From Joomla! Documentation

(New page: The "Gloden 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 &rarr...)
 
m (temporary, will improve this update to page, onlyinclude tags, starting to stitch together the pages of Teams back to bug squad page for transclusion)
(3 intermediate revisions by 3 users not shown)
Line 1: Line 1:
The "Gloden 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:
+
<onlyinclude>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 to the SVN. 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 end result without going through one or more tries.</onlyinclude>
 +
 
 +
 
 +
===More information===
 +
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 &rarr; Confirmed &rarr; Pending &rarr; Ready to Commit &rarr; Fixed in SVN
 
Open &rarr; Confirmed &rarr; Pending &rarr; Ready to Commit &rarr; Fixed in SVN
Line 25: Line 33:
 
Whenever a problem is being solved in the framework (those are all the files under the <code>/libraries/</code> 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.
 
Whenever a problem is being solved in the framework (those are all the files under the <code>/libraries/</code> 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.
+
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 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).
 
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).
  
 
<noinclude>[[Category:Development Working Group]][[Category:Bug Squad]]</noinclude>
 
<noinclude>[[Category:Development Working Group]][[Category:Bug Squad]]</noinclude>
 +
[[Category:Working Groups]]

Revision as of 00:13, 28 November 2012

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 to the SVN. 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 end result without going through one or more tries.


More information[edit]

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:

  • The PHP programming language;
  • SQL syntax;
  • How to checkout and update a Subversion (SVN) source code repository;
  • How to create, apply and analyse a "patch file"; and
  • The basic principles of Object Oriented Programming (OOP for short).

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, 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 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).