QA rights/responsibilities

Fixing bugs/making releases

If any QA related issues are found in a package that QA has not
been granted permission to change without consulting the maintainer,the
QA team will file a bug report. If the issue remains unresolved for 1
month (2+1+1 weeks; see below), QA may fix it themselves.

If the issue isn't fixed with in two weeks QA will email the
maintainers about the issue (if the bug system won't have auto bug
report notices every X week in the future) and if the problem isn't
fixed within one week from that, QA will send yet another email to the
maintainers and if no answer nor fix to the problem is provided within
one week, all members of the core QA team will get the permission to
modify any file needed to fix that QA issue as well as make a new
release.

If any major QA issues are found in any
package and the QA team doesn't have permission to change that package
without contacting the lead first then the QA team will file a bug
report. Any major issues can stay open for 2 weeks (5+5+4 days; see
below), QA may fix it themselves.

If the issue isn't fixed within 5 days QA will email the
maintainers about the issue (if the bug system won't have auto bug
report notices every X week in the future) and if the problem isn't
fixed with in 5 days, from that QA will send yet another email to the
maintainers and if no answer nor fix to the problem is provided with in
4 days, all members of the core QA team will have permission to modify
any file needed to fix that QA issue as well as make a new
release.

The same time frames apply when the QA team want to make a release
because of unreleased fixes/improvements which are only available via
SVN, or when the QA team wants to determine if a package has been
orphaned (using the time frames specified for non major issues).

The QA team can decide what are major issues after discussion on
the QA Mailing-list.

The QA team will for this reason keep track of those QA issues in
their pear web subsection. This would only be for having overview over
which package maintainers need to be emailed for reminders and such
things.

Orphaned Packages

The QA team can use the above stated rules to determine if a
package is orphaned. The core QA team gets lead rights on all orphaned
packages until the original maintainer returns or a new maintainer is
found.

Deleting Package releases

The core QA team also has 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. This right must be exercised with
caution.

Package maintainers can also grant QA the rights to make a
releases for their packages.