User:MGorny/Proxy-maint Constitution

From Gentoo Wiki
Jump to: navigation, search
Warning
This page is a work in progress by MGorny (talk | contribs). Treat its contents with caution.

This document specifies the most elementary policies for proxy-maint project members.

Proxy-maint Constitution

  1. The goals of the proxy-maint project are to:
    1. Provide non-developers with the ability to maintain ebuilds in gentoo.git repository.
    2. Provide training on ebuild writing and development practices for proxied maintainers.
  2. The following restrictions on maintainer boundaries apply:
    1. Proxy-maint project members merge contributions only to packages that are maintained via that project (i.e. have proxy-maint project listed explicitly in metadata.xml) or (optionally) to packages with no listed maintained (maintainer-needed). Project members are asked not to merge contributions to packages maintained solely by other developers on behalf of the project.
    2. Contributions made to another proxied maintainer's package (i.e. when the patch author is not metadata.xml) are to be additionally reviewed by one of the package's proxied maintainers.
    3. (Additional) proxied maintainers can be added to a package either if it has no maintainers or none of the current maintainers object to it.
    4. At the same time, other Gentoo developers are asked not to merge contributions to proxy-maintained packages if they are neither members of the project nor explicitly listed as maintainers of the package(s) in question.
  3. The proxy-maint developers are granted the following freedoms:
    1. Freedom to choose how to review. The proxy-maint members may apply any review techniques they find appropriate with regards to particular contributor and/or contribution.
    2. Freedom to choose what to review. The proxy-maint members are free to skip contributions or resign from review already in process for any reason. However, they should not explicitly reject contributions unless it is clear that other members would not merge it either.
    3. Freedom to defer some of the issues. The proxy-maint members may accept a contribution with known issues if those issues are either minor and/or not regressions, and they think the contributor put significant effort already or they're convinced he'll address them later.
  4. The proxy-maint developers are asked to respect the following quality requirements:
    1. All merged contributions should be tested, and reviewed for any obvious issues. It is inevitable for some issues to go unnoticed but we should at least try to keep the likeliness of bug reports immediately following the merge low.