QA team membership
How the initial members are chosen
If there are more applicants than seats, there should be an open election, where everyone may cast as many votes as there are seats (only 1 vote may be cast per candidate). Of course, if there are less people than seats, all may be accepted and the remaining seats can be filled by QA group vote. Once the core team is formed all further team members can be voted in as per the rules stated below.
There will be a QA core team with a limited number (no more than 7, with the pear group this should give a sufficient amount of people with enough karma that can react to bad releases) people with extended "core-QA-karma". In order for the QA core team to react quickly, the core QA team should be spread out across all time zones as good as possible. This rather small number should empower the QA team sufficiently to handle issues but doesn't trivialize access rights.
This issue needs more discussion since Klaus raised a good point in his post but the problem is that it isn't wise to give many users so much karma.
All other people interested are free to join the QA team. However potential new members for the QA team (core and non core) must be voted in by a 2/3 majority of the existing members of the QA team (core and non core). This is to prevent that the addition of new members is done even though there is a considerable amount of opposition, as this could lead to internal quarrels which could result in reducing the QA teams ability to efficiently address QA issues. Removing a member from either group requires a 2/3 majority as well.
For casual helpers the QA mailing list will of course remain open.
All members of the QA team (core and non core) are eligible to participate in QA team votes.
Any member that leaves the QA team loses all his special karma which he may have received due to his membership. If any member of the core QA team leaves and as a result a time zone gets under staffed, QA should actively try to find a replacement.
When voting for a new member voters must be sure that the person has been helping with bug fixes in the past or has the potentials to help with that.