Project:Proxy Maintainers/Policies and Guidelines
Proxy-Maintenance Policies
Maintainer Bugs
The process for managing Maintainer Bugs from contributors can be found here.
Proxied Contributor e-mail Domain Regulation
The Proxy-Maint team exists to collaborate with regular users who wish to contribute to Gentoo. That means the team works with a lot of different people, and therefore sees many different names and e-mail domains. While the contribution may be of good will, and the contributor may not realize their domain name is offensive, distasteful or unfunny, it may not hold true for other people. The Proxy-Maint team must guide the user, because the metadata used to store proxied maintainers' contact information is visible in:
- the repository itself
- https://packages.gentoo.org website
- bugzilla
- repology
- who knows where else.
furthermore, upstream developers contact proxy-maint and the proxied maintainer directly via e-mail. For these reasons, the contact information is largely unavoidable and per team vote (2024-08-16) it is prohibited to add a "potentially offensive" e-mail domain name, or username, to Gentoo's metadata.xml files. In addition the Proxy-Maint team members should outright reject any contributions that fall under this discretion, to prevent the authorname or e-mail from being recorded in Gentoo's git history by asking the contributor to use another e-mail to author and sign-off their commits with.
"What counts as potentially offensive?"
We will not have a list of blocked words, but rather use your common sense and your own judgement to decide that. If a developer is unsure about domain used to contribute, ask opinion from other team members. A rule of thumb could be to think whether a spam filter has a chance to tag the sender as junkmailer, or whether it's blocked by Google's GMail.
We live around the globe and words may have different meanings in different areas.
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.
Developer Autonomy
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
Closes: https://bugs.gentoo.org/NNNNNN
Signed-off-by: Proxie M. Tainer <nickname@example.com>
Signed-off-by: Genti Dev-Loper <example@gentoo.org>
Closes: https://github.com/gentoo/gentoo/pull/NNNN
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.
Guidelines
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[1] for assisting users in maintaining orphaned packages. If you are interested in maintaining this package, please contact proxy-maint@gentoo.org or join #gentoo-proxy-maint on Libera.Chat IRC. [1]: 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.