Gather the required information about the new lists. This includes the precise name and domain, the email addresses of the people who will be moderators (ideally three+ and well spread).

Send to apmail@apache.org and Cc your PMC. Add an issue to Jira in the "Mailing Lists" category.

Please be specific about which details.

Send to apmail@apache.org and Cc your PMC. Add an issue to Jira in the "Mailing Lists" category.

Gather the email addresses of the people who will be moderators (ideally three+ and well spread).

Send to apmail@apache.org and Cc your PMC.

See instructions for mailing list moderation.

You can usually do this yourself. Refer to the instructions via the documentation for your particular project.

The mail management software used by the Apache is mature and rarely goes wrong. This means that it's most likely something you're doing something a bit wrong which causes unsubscription to fail. Read the help for the list (post to the address given by the List-Help header value, e.g. dev-help@{$tlp}.apache.org).

The most common reason why someone ends up not being able to unsubscribe is that they have forgotten the address they were subscribed from. You must post the unsubscribe message from the subscription address. You can find the subscription address by examining the full headers of an email received from the list. The Received headers should allow you to track the inbound progress of the mail.

If you are still unsuccessful at unsubscribing yourself, then contact the moderators for the particular list. You can do this via the {$listname}-owner address (e.g. dev-owner@{$tlp}.apache.org). Tell them the exact email address that you are subscribed with (see above).

New projects will need to ask for their SVN-space to be created.

Send to infrastructure@apache.org and Cc your PMC. Add an issue to Jira in the "Subversion" category.

First be sure of your facts. If you are a committer, then make sure that you are using 'https'. Also ensure that you have established your svn password. See the Machine and Service Status for known issues about Subversion services.

One common complaint is that after new committer accounts are created, your project PMC has not properly added your username to the SVN authorisation. See notes. If you can successfully commit to your project repositories, but cannot access the "committers" repository, then you have not been added to the "committers-[a-z]" group. Ask your project PMC.

For other access troubles, send to infrastructure@apache.org and Cc your PMC, and remember to provide the URL for the repository in question.

The infrastructure team use a public monitor for Apache machines. This also lists scheduled downtime. If the machine is listed by the monitor as down then it's very likely that infrastructure already knows about it and so helpful messages posted to infrastructure to let us know the machine is down aren't needed.

The infrastructure team use a public monitor for mirrors. Bad mirrors are automatically removed from the rotation of "preferred" mirrors. If a mirror stays bad for more than a couple of weeks, it is usually removed permanently. If the mirror is listed by the monitor as down then helpful messages posted to infrastructure to let us know aren't needed.

To update your project website you need to be in the relevant UNIX group on the server. Do 'ssh people.apache.org; cd /www/$project.apache.org; ls -l' to see which group owns the files. Now do 'groups' to see which you are in. If the group is not listed, then send email to root@ (and Cc your PMC) asking to add your username to the relevant group.

Sometimes new committers do not configure their account properly. So when they create new files, these files have incorrect group permissions (see above) and other project committers cannot update. Send email to infrastructure@ (and Cc your PMC) asking them to fix the group permissions for the relevant directory. Also ask the committer to configure their account or else it will keep happening.

Raise an INFRA issue in JIRA under wiki.

Day to day maintenance of the Apache issue tracking systems. Users should report issues and ask questions to the appropriate project first though the appropriate mailing list.

Day to day maintenance of issue tracking is delegated to projects. Each project should have at least one person with rights to perform basic administration on the project's issue tracking system. The major exceptions to this rule are outages of the issue tracking applications. These should be reported to the main infrastructure mailing list but please check first that this outage is not already known.

Questions about the issue tracking systems should be directed to the main infrastructure mailing list and issues reported in JIRA.