<!DOCTYPE HTML PUBLIC "-//FreeBSD//DTD HTML 4.01 Transitional-Based Extension//EN" [
<!ENTITY base CDATA "..">
<!ENTITY date "$FreeBSD$">
<!ENTITY title "Policies of the Ports Management Team: Maintainers and Committers">
<!ENTITY % navinclude.about "INCLUDE">
]>

<html>
&header;

<p>These are the time periods that apply to maintainer and committer
responses to issues brought to their attention via email.</p>

<a name="pr_timeout"></a>
<h3>Problem Report (PR) Timeouts</h3>

<p>The time limit for a maintainer to respond to a PR is two weeks.
  After that period, if it is a minor change, any ports committer can
  commit the change.  If it is a major change (e.g. would require a
  regression run), please contact portmgr first.</p>

<p>We have an add-on to the GNATS database known as the auto-assigner,
  which attempts to automatically notify maintainers of PRs; however,
  it depends on the Synopsis containing category/portname.  In general,
  various people attempt to catch and fix cases where it does not work,
  but you should not assume so.  Therefore, please 
  check to see whether or not the maintainer knows about the PR before
  declaring a timeout.  You can generally tell this from the Audit-Trail
  and Cc: lines in the PR.</p>

<a name="maintainer_reset"></a>
<h3>Maintainer Reset</h3>

<p>A maintainer who does not respond to any port issues for 3 months may
  be reset by any ports committer.  If you are
  a committer and concerned about whether you are doing the right
  thing, please contact portmgr.</p>

<p>This period may be shortened by portmgr if the email address returns
  with a hard bounce.  In this case, it is probably desirable to reset
  all the maintainer's ports and change any PRs set to 'feedback' back
  to 'open'.</p>

<a name="commit_privileges"></a>
<h3>Commit Privileges</h3>

<p>Ports committers who are not active for one year will lose commit
  privileges.  portmgr will contact the
  committer by email before invoking this limit.</p>

&footer ;
</body>
</html>
