Project:Proxy Maintainers/Developer guide

This documents shortly documents policies and requirements for proxy-maint project members, i.e. developers merging the contributions from our users.

First of all: do not leave users hanging
If you left review comments, make sure to answer any questions the user may have in reply, and update your review when new commits are pushed. If the user doesn't say that explicitly, a new CI report indicates that the pull request has been updated. If you can't find time or motivation to finish reviewing, please explicitly say so and discard your review.

Leaving user's update unanswered for a long time both creates negative feedback to prospective proxied maintainers, and often defers others from looking at the PR (apparently X is doing it, so let's wait for him to finish).

Accepting new proxied maintainers
Please do not accept proxied maintainers who have not proved their skills. It's [|explained shortly in the User Guide]. If someone submits a 'pure' request for taking a package over, you can merge it straight away only if you know that he has been doing good maintenance work in the past. If you don't know that, please ask him to solve some problem with the package (fix a bug, do an EAPI bump, anything).

If the package really doesn't have anything to do, you can try asking him to fix some other package or otherwise help you in development work. Anything that helps you evaluate that he will be able to maintain the package.

The main goal of this policy is to prevent reassigning packages just to remove the maintainer for inactivity shortly afterwards.

Reviewing
Please refer to the review suggestions of the GitHub project as a good base for working on pull request and other contributions (the reviewing rules are quite universal). However, a few notes need to be added to that.

On behalf of proxy-maint team, please focus on reviewing contributions to proxy-maintained (and potentially proxy-maintained) packages. Please do not merge fixes to other developers' packages on behalf of the project. If a proxied maintainer is interested in helping with some package, you can encourage him to become a co-maintainer. Of course, you can also merge those pull requests on your own behalf, with respect to the policies in place.

It is usually reasonable to assume that proxy-maint is not only about getting stuff merged but also about training prospective developers. Therefore, it is acceptable to expect higher standards than normally (and if the user asks, present this very reason to him). However, do not expect too much. After all, we expect proxied maintainers to stay here for a while, so sometimes it is reasonable to say: please fix this later.

Cross-proxied maintainer commits
Sometimes users submit pull requests to packages maintained by (other) proxied maintainers. Whenever that's the case, please encourage proxied maintainers to review those pull requests, and try to get their approval before merging. You can also suggest the user to become a co-maintainer if he seems interested.

Proxied maintainers proxied via developers
Some developers are handling proxied maintainers directly. We generally assume that proxy-maint has authority to commit on behalf of the proxied maintainer if it is listed in metadata.xml. If proxy-maint is not listed there, please do not merge without explicit permission of the proxy.

If the user is interested in working with proxy-maint team, feel free to ask him to add us to metadata.xml. Once that happens, proxy-maint can merge at will.

Maintainer inactivity
Proxied maintainers are expected to maintain their packages just like regular developers, including responding to bugs and feature requests. If the proxied maintainer seems inactive, please try to contact him. If the proxied maintainer is unable to maintain the package correctly, you can remove him and submit the package up for grabs appropriately.

Maintainer bugs
When merging the first contribution of a new proxied maintainer, you should create a new maintainer bug for him. However, it is easy to forget about it. Therefore, it is best to use the scripts to create all missing bugs when you remember.

The script will scan your Gentoo repository checkout for all proxy-maintained packages and Bugzilla for maintainer bugs. It will create new maintainer bugs, as well as complain about those with outdated e-mail addresses and seemingly obsolete.

Note that you will need to obtain an API key from Bugzilla and place it in.