This team has the very important and sometimes 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.
The Tracker Team should also make sure the issue has the correct Type and Priority. Remember, many users reporting bugs are not familiar with all of the fields and terminology. In many cases, this could be the user's first contribution or interaction with the project.
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 end result without going through one or more tries.
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.
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 2.5). They will be responsible for creating and fixing issues in this area of the code.