Project:Quality Assurance/QA Team Draft Policy

On this page we will list several topics, for each topic we can have multiple alternative ideas; we can then later discuss these alternatives, when acknowledged by the QA team lead it can then be moved to a real QA team policy.

The syntax used per topic is:

{{Code|Example topic and its ideas|

Topic
Explanation or question regarding the topic.

First idea
Explanation of first idea.

Second idea
Explanation of second idea. }}

Messaging the maintainer (Example)
How do we make the maintainer aware of our actions?

We message them on IRC
It's better to use IRC because ... (personal, immediate response, ...)

We always message them on mail
It's better to send e-mails because ... (scriptable, always reachable without requiring to find the person, ...)

How much notification/permission is required?
The QA team is empowered to make changes, but what changes need approval from the package maintainer, what changes should the package maintainer be notified of, etc.

Functionality change rule
Suggestion for a dividing line: if the ebuild's functionality is or could be changed, ping the maintainer and wait a reasonable amount of time for a response before making the change. Things like small repoman fixes (extra spaces, unquoted vars, etc.) or even slightly larger changes like EAPI bumps will not need notification, while larger changes like eclass migrations which could affect the package require permission first.

Yes, revbump
Makes sure that the user gets all of the latest features

No, don't revbump
Less rebuilding for users and stabilizing work for arch teams