[RFC] - How QA Team will work.

Title: RFC - How QA Team will work. ------------------------------------------------------ Author: helgi at trance dot is Revision: 0 Status: Active There has been talked about forming QA team but no action yet taken. The following is a good idea about how the QA team will work, what rights they have and so on. The Issues ----------- There is no QA team for PEAR only few people that try to help with that QA issue but those people don't have any karma to changes those package that have QA issues. PEAR claims quality but that can't be meet if there is no real QA team. To summarize the problem * No QA team = can't claim Quality * Nobody has defined how the QA is supposed to work, how it should be structured and what its rights (karma) are supposed to be. The Proposed Solution. ----------------------- QA Group Membership: Have a limited number (no more than 5) core QA people with extended QA-karma New members must be voted into the QA team and don't get any special karma, but the mailing list will remain open of course. As a member of QA team one would get the right to vote when that comes to hand. New member as to get 2/3 or 3/4 of the votes in his favor to get in the team, this is to prevent that the member will have anyone against him and making it a possible flame war or any such with in the group. This should empower the QA team sufficiently to handle issues but doesn't trivialize access rights. Manual/Web page: Seems that there is a lack of QA material in the manual that people agree on and there is also need to make it move visible for people so they will actually follow those rules/guidelines. QA controls the QA part of the manual just like package maintainer controls the package related docs in the manual. Voting: Everything regarding QA that goes in the pear manual will be voted by the QA team members so no nothing goes in the manual about QA that at least more then half of the members agree on, thus decisions should be simple majority. Decisions effecting a specific package which requires the karma level of the core team can also be voted on by the entire team, but ultimate decision is up to the QA core team. QA team gets its own subsection on pear web so people can more easily access QA material and get maybe the newest decisions from the QA team, also where package maintainers can configure additional access rights the maintainer wants to give to the QA team, though that if QA makes any changes at all to package they will have to email the lead so the know of the change no matter how small the change is. QA core group access right: If any QA related thing is found in a package that QA has not permission to change the package then QA will file a bug report. The issue can stay open for 2 months (4+2+2 weeks) until QA may fix it themselves. If the issue isn't fix with in a month QA will email the maintainers about the issue (if the bug system won't have auto bug report notice every X week in the future) and if the problem isn't fixed with in 2 weeks from that QA will send yet another email to the maintainers and if no answer nor fix to the problem is provided with in 2 weeks QA will get the permission to modify any file needed to fix that QA issue on the count of thinking the maintainers don't care anymore, are *dead* or simple don't have time. Then the QA will email the maintainers about that QA team has fixed the QA bug and which files were effected. If any major QA things are found in any package and the QA team doesn't have permission to change that package with out contacting the lead first then the QA team will file a bug report. Any major issues can stay open for 1 months (2+1+1 weeks) until QA may fix it themselves. QA team will email the lead and if no fix is provided when 1 week has passed then there will be another email sent, if there is no fix after 1 week time from that then QA get permission to fix the problem and then email the maintainers about that QA team has fixed the QA bug and which files were effected. QA team can decide what are major issues after discussion on QA Mailing list. QA has to keep track of those QA issues that are in bug report some how, with a wiki of some kind for example. This would only be for having overview over which package maintainers need to be email for reminders and such things. Also QA must get the permission to delete any release that might have any issues that have been found after the release to reduce the effects of the problem. QA will be given the right to make release for packages that have gotten QA fixes in CVS but haven't released anything month from the time the fixes were added. Package maintainers can also grant QA the rights to make a release if necessary. Summarize of the solution QA core group access right: * Max 5 core members that get the right karma. * QA will get more permission to modify packages that haven't given QA permission to do such things, the modify rights are granted based on if the package leads don't react with the problem with in specific time frame * QA core gets the rights to delete and make release of packages if needed * QA core team is allowed to add QA related notes to each package homepage QA team in general: * Rest of the QA team will identify QA problems, help writing QA related documents, helping people resolve their QA problems and such things and same goes with QA core members. * More focus is needed on writing QA related things in the manual and make then more visible * Make a little QA corner at pear.php.net so QA is more visible for people and package devs are more aware of the QA team and how it works. * keep track of what QA does regarding packages that QA doesn't have permission to edit trough a wiki of some sort * QA team needs to approve an first stable release for a given major version number (done by votes) Actions Required if accepted. ----------------------------- * Forming of the QA team, voting which persons should be in the core of the QA team. * Giving the core dudes full CVS karma on the pear CVS module, as well as full access rights to package management part of pear web? * Getting list of who want to be in the team and vote which of them will be in the team. * Make that little QA pear page * Improve the QA manual pages * Finding out which packages lead allow QA to help keeping their package QA approved * Better coordination of the work which is done, who is going to do what. Know before hand who is going to write some more entries to the manual and so on. * Make a wiki page of some sort for the info tracking regarding QA editing package that QA doesn't have permission to edit. Change log ---------- Initial Release : 24 March 2004