Re: [RFC] - How QA Team will work.

Hi, First of all, this stuff should be edited by someone with English as the first language, as it is extremely difficult to understand now. Helgi Þormar wrote:

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.

I don't like the idea of Yet Another 'core'. There may be some coordinator(s) for the process, although. We already have PEAR Group for precisely this. And the only way for a person to become a member of QA team should be by submitting quality bugfixes, not through some obscure voting process.

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.

No special group is needed for this, only volunteers to write the relevant chapter. Volunteers?

Voting:

This is IMNSHO not needed.

QA core group access right:

I don't like the proposed solution. Suggestion: package maintainer *may* explicitly grant the rights to apply patches to his package and to do bugfix releases. A responsible package maintainer will do this if he does not currently have time to work on the package himself. PEAR QA team *should* actively monitor bug tracker and ask package maintainer(s) for such rights if the package's bugs do not get fixed for [some period], with a copy of email sent to the list for future reference. If the maintainer does not react for [some other period] then the package *should* be declared "orphaned". QA team automatically gets rights to apply patches and do bugfix releases for "orphaned" packages. (NB: "orphaned" packages require a separate RFC) For each bug QA team fixes a test case *should* be added to the package.

Summarize of the solution

    QA core group access right:
        *  Max 5 core members that get the right karma.

-1

        *  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

see above.

        *  QA core gets the rights to delete and make release of            packages if needed

package releases should be deleted only in extreme cases (a list of such cases might come in handy). Another approach is to demote the package stability status (e.g. stable->beta).

        *  QA core team is allowed to add QA related notes to each            package homepage

-1, we have bug tracker for this.

    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

Lots of words, little sense.

        *  QA team needs to approve an first stable release for a given            major version number (done by votes)

-1, without the defined standards for what "stable" is this is useless.

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.

I don't understand the "who want to be in the team" part. You want to be in the team --- you fix bugs. That simple, no voting needed.

        *  Finding out which packages lead allow QA to help keeping            their package QA approved

This should be somehow handled through web interface. Are there volunteers to add such functionality

        *  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.

That's what maillists are for.

        *  Make a wiki page of some sort for the info tracking            regarding QA editing package that QA doesn't have permission            to edit.

?