Actions

Difference between revisions of "Bug Squad"

From Joomla! Documentation

(fix links for wiki article consolidation)
(update to include team descriptions)
Line 1: Line 1:
 
[[Image:workgroups_bugsquad.jpg|right]]
 
[[Image:workgroups_bugsquad.jpg|right]]
The Joomla! Bug Squad is the second team within the development work group. Their main responsibilities are:
+
The Joomla! Bug Squad (JBS) is a team within the development work group. Their job is to identify and fix bugs in Joomla. This includes the following:
  
 
* Scan the [http://forum.joomla.org/viewforum.php?f=199 Joomla! Bug Reporting Forum] for reported issues and help community members with solving these issues.
 
* Scan the [http://forum.joomla.org/viewforum.php?f=199 Joomla! Bug Reporting Forum] for reported issues and help community members with solving these issues.
* Maintaining the [[http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=32 Tracker]].
+
* Maintaining the [[http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=32 Version 1.5 Bug Tracker]] and [[http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=8103 Version 1.6 Issue Tracker]] .
 
* Fix reported bugs and resolve reported issues according to the [[Bug Tracking Process]].
 
* Fix reported bugs and resolve reported issues according to the [[Bug Tracking Process]].
  
As described in the [[Joomla! Maintenance Procedures]] the Bug Squad will be in the lead when a development branch is in maintenance mode. Beside this, the Bug Squad is also supporting with testing and quality assurance when a new major or minor version is developed. Generally speaking the bug-squad is in the lead when a version switches from beta-stage to the stable-stage within the [[Development Cycle]] of Joomla!
+
The Bug Squad is also supporting with testing and quality assurance when a new major or minor version is developed. Generally speaking the bug-squad is in the lead when a version switches from beta-stage to the stable-stage within the development cycle of Joomla!
  
The Bug Squad has been created in the last week of December 2007. No specific structure within the team has been determined yet, but as this team will grow it is to be expected the following main structure as described below will evolve. Remember this is a structure that not necessarily represents an hierarchical structure, and also the positions are not limited to one person. One person can for example perfectly be team leader of the Joomla! 1.0 branch, but also be tester who has commit access to the code-base.
+
The Bug Squad was created in December 2007. As of May 2010, JBS has been organised into the following teams:
 +
* Tracker Team - monitors the forums and trackers
 +
* Coding Team - creates patches for Confirmed Issues
 +
* Testing Team - tests Pending issues
 +
* Automated Testing Team - creates automated system and unit tests for tracker issues
 +
* Migration / Upgrade Team - responsible for supporting migration and upgrading from the prior version to the current version.
 +
 
 +
These teams are not rigid, and JBS members can participate in whatever activities they wish. The purpose of the teams is to make it easier for JBS members to focus their efforts and learn the skills required to successfully contribute to the project.
 +
 
 +
===Tracker Team===
 +
This team has the very important and difficult job of filtering all of the forum posts and bug reports and sorting out which ones are real bugs that are ready to be worked on. From the standpoint of the tracker, their job is to move issues from Open status to Confirmed status. Of course, many issues will also be put into other status codes, including Information Required, Needs Review, Duplicate, Not a Bug, and so on.
 +
 
 +
Before an issue is marked Confirmed, it needs to be reproduced and documented so that others can reproduce the problem.
 +
 
 +
===Coding Team===
 +
The coding team works with Confirmed issues and creates patches to correct these issues. 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.
 +
 
 +
===Testing Team===
 +
This team tests Pending issues and, when tests are successful, documents this and moves the issue to Ready to Commit status. At this point, one of the JBS coordinators will commit the patch to the SVN.
 +
 
 +
===Automated Testing Team===
 +
Automated testing is a key technology that we will incorporate into the workings of JBS. At the present, this is a somewhat specialized skill, so we will start by developing a separate team of people who are familiar with this and can help write automated tests and train other JBS members on automated testing. Our aim is to eventually make automated testing a routine part of fixing issues.
 +
 
 +
===Migration / Upgrade Team===
 +
This team is responsible for coding and documenting the upgrade process for users migrating sites or extensions from one version to the next (for example, from version 1.5 to 1.6). They will be responsible for creating and fixing issues in this area of the code.
  
 
<noinclude>[[Category:Development Working Group]][[Category:Bug Squad]]</noinclude>
 
<noinclude>[[Category:Development Working Group]][[Category:Bug Squad]]</noinclude>

Revision as of 12:02, 20 May 2010

Workgroups bugsquad.jpg

The Joomla! Bug Squad (JBS) is a team within the development work group. Their job is to identify and fix bugs in Joomla. This includes the following:

The Bug Squad is also supporting with testing and quality assurance when a new major or minor version is developed. Generally speaking the bug-squad is in the lead when a version switches from beta-stage to the stable-stage within the development cycle of Joomla!

The Bug Squad was created in December 2007. As of May 2010, JBS has been organised into the following teams:

  • Tracker Team - monitors the forums and trackers
  • Coding Team - creates patches for Confirmed Issues
  • Testing Team - tests Pending issues
  • Automated Testing Team - creates automated system and unit tests for tracker issues
  • Migration / Upgrade Team - responsible for supporting migration and upgrading from the prior version to the current version.

These teams are not rigid, and JBS members can participate in whatever activities they wish. The purpose of the teams is to make it easier for JBS members to focus their efforts and learn the skills required to successfully contribute to the project.

Contents

Tracker Team

This team has the very important and difficult job of filtering all of the forum posts and bug reports and sorting out which ones are real bugs that are ready to be worked on. From the standpoint of the tracker, their job is to move issues from Open status to Confirmed status. Of course, many issues will also be put into other status codes, including Information Required, Needs Review, Duplicate, Not a Bug, and so on.

Before an issue is marked Confirmed, it needs to be reproduced and documented so that others can reproduce the problem.

Coding Team

The coding team works with Confirmed issues and creates patches to correct these issues. 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.

Testing Team

This team tests Pending issues and, when tests are successful, documents this and moves the issue to Ready to Commit status. At this point, one of the JBS coordinators will commit the patch to the SVN.

Automated Testing Team

Automated testing is a key technology that we will incorporate into the workings of JBS. At the present, this is a somewhat specialized skill, so we will start by developing a separate team of people who are familiar with this and can help write automated tests and train other JBS members on automated testing. Our aim is to eventually make automated testing a routine part of fixing issues.

Migration / Upgrade Team

This team is responsible for coding and documenting the upgrade process for users migrating sites or extensions from one version to the next (for example, from version 1.5 to 1.6). They will be responsible for creating and fixing issues in this area of the code.