Project:Proxy Maintainers/Policies and Guidelines
- 1 Proxy-Maintenance Policies
- 2 Internal Project Policies
- 3 Pending Policy Changes
- 4 Guidelines
Maintainership Requests and Maintainer Bugs
The process for managing Maintainer Bugs and new Maintainership Requests from contributors can be found here.
Proxied Maintainer Activity Requirements
Proxied Maintainers are required to be reasonably active in handling bug reports that have been opened for their package. If a proxied maintainer has been inactive without prior notification for a reasonably long period (determined at the discretion of the project members involved, at least one month), the proxied maintainer may be dropped, or another proxied maintainer may be added as a co-maintainer.
The developers should encourage users to make their own decisions about their packages, such as which versions should be kept in the tree. Respect the user's decisions within the boundaries of logic; do not simply reject them. Instead, explain your logic so that it becomes a learning experience for them. Ultimately, you are responsible for commits that you make on behalf of the user. Therefore, while not encouraged, you may override the decisions of the proxied maintainer. Disputes regarding developer autonomy may be directed to the project lead.
Authority to Commit
This policy implements a priority approach to ascertain which developers may commit a proxied user's contribution and accounts for the current possible scenarios. The fora currently used now include:
- The list of orphaned packages commonly labelled maintainer-needed.
- Regular packages dropped by a developer picked up by user maintainers.
- Pull requests submitted via the new Gentoo GitHub mirror.
The first priority is given to members of the project, second to developers with established knowledge in the field of the category of the package. Since the project hosts a full scope of packages, negotiations between developers are taken as an 'understood' and required approach in determining authority. Commits by 'non member' developers without contact with members of the project are discouraged and fall short of respecting the set processes / operations of the project.
With regard to the newly established Gentoo's GitHub mirror, this policy states that:
- Those developers need first prompt the project's members, via IRC or the alias, offering the option of committing.
- Once this proves fruitless, developers of the GitHub mirror are free to commit the pull request on behalf of the user.
- Recommended timeout period, 1 week and up to the discretion of the developers.
Internal Project Policies
Changing Project Policy
This policy defines the methods for proposing future changes to the official policy and the process for which the proposal has to undergo to receive official recognition. All proposed changes to project policy must be submitted to the project email address as a RFC. This provides all stakeholders, whether they be developers or proxied-maintainers, with a means to provide their input regarding the proposed change before its implementation. A week after inception, a proposal receives official recognition when deemed satisfactory to the majority of the team members.
Pending Policy Changes
These are pending RFC on the Proxy-Maint Alias. Changes here that have not been RFC'd on the alias, as per official policy, will be promptly discarded.
Reaching out to a Prospective User
Member developers of the Proxy Maintainers team should encourage users to participate in this project when they notice a open bug for an orphaned package.
Such template (or a similar one) can be used to inform users about this project:
Hello, This package has no maintainer so this bug may go unnoticed for a long time. Gentoo has a dedicated team for assisting users in maintaining orphaned packages. If you are interested in maintaining this package, please contact firstname.lastname@example.org or join #gentoo-proxy-maint on Freenode IRC. : https://wiki.gentoo.org/index.php?title=Project:Proxy_Maintainers Kind regards, <Devname>
Changes by a Developer not part of Proxy Maintainers
If a developer come across a package that they need to work on, and the assigned proxied maintainer does not seem to be active, contact/cc the proxy-maint alias. Upon doing so, the status of the proxied maintainer will be assessed as per internal policy.