Suggested goals + a few methods/requirements for the goals

Suggested Goals for the PHP QA Team ============================================================ Close Bug Reports ----------------- Close as many bug reports as possible. To accomplish this goal, we will focus on clearing out false, incorrect and old bug reports first. This approach should also reduce the risks associated with letting QA team members close bug reports. To do this QA Team members will need CVS accounts - or - A modified bug database that allows the QAT to close bugs** ** This solution is favored by the developers Timely Quality Assurance ------------------------ Providing the developers with timely quality assurance for PHP release candidates. Create a QA Team Roster ----------------------- Create a list of the QA Team members. Track what platforms they have access to. Modify The Bug Database ----------------------- The bug database needs to have a modified interface. The interface should to: - reduce the occurance of multiple reports on the same bug - improve the accuracy of the reports - make it easier for the QAT to reproduce the bug - track the solution to the bug Develop Test Suite for Release Candidates ----------------------------------------- The suite should contain code libraries, regression tests, standard checklists for issues, etc... The suite should be automated. Monitor Php Lists For Possible Bugs And Bug Fixes ------------------------------------------------- QA Team members need to monitor the other mailing lists. They should watch for people posting bug reports and bug fixes. The posters of the reports/fixes should be asked to submit a formal bug report Provide Client Side Bug Reporting --------------------------------- Add functionality to PHP to help developers submit bugs. Probably the best solution that has been proposed is the addition of a submit_bug() function that would automatically send platform data, along with PHP interpreter state when it is called. This solution would address the security concerns that have been raised by the possible display of platform information to malicious visitors. Bugs gathered from this source would need to be filtered by an agent before they could be considered truly useful. Note that filtering many spurious bug reports should be relatively simple. Bug reports that were generated due to parse errors could be ignored or flagged as low priority. However, all of this would require developer involvement and is probably the least plausible goal! :) Notes: No one is credited in this condensed version of the posts to the list. The messages have been condensed to the most key points for the sake of everyone's time. Zak Greant Creative Director Nucleus Information Service Inc. "Few things are harder to put up with than a good example. " - Mark Twain