Project:Proxy Maintainers/Policies and Guidelines
The process for managing Maintainer Bugs 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.
Certificate of Origin for proxied maintainer contributions
The Gentoo Certificate of Origin requires that committers confirm their agreement to the terms of GLEP 76 by signing the commits. For proxied contributions, both the proxied maintainer and the committing developer must sign off. Both signatures must use the real names. The developer has to ensure that the proxied maintainer's signature is present and does not seem anonymous/pseudonymous.
It is sufficient to focus on catching obvious cases like nicknames, initials in place of surnames. When in doubt, ask the proxied maintainer whether this is his real name.
An example commit with complete signatures:
app-foo/bar: frobnicate the ebuild
Signed-off-by: Proxie M. Tainer <firstname.lastname@example.org>
Signed-off-by: Genti Dev-Loper <email@example.com>
Pull requests created before 2018-09-17 can currently be merged without Signed-off-by. The assignment bot, marks new pull requests with Signed-off-by: statement is missing, if the verification fails.
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 Libera.Chat IRC. : https://wiki.gentoo.org/wiki/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.