An Incubator PMC member who is also an ASF member or a PMC chair edits
asf-authorization-template and adds a [/incubator/podling] section.
If the section refers to an @podling group, a definition of that group, as a
comma-separated list of availids (usernames), MUST be added to the
[groups] section. Alternatively, just set @incubator = rw as the section's
body.

An Incubator PMC member runs svn mkdir ^/incubator/podling. The commit
mail will get delivered to the mailing list created earlier.

If additional services need to be created (beyond mailing lists, svn tree, and
web site), file one "Create Foo Podling" parent ticket in JIRA and one sub-task
ticket for each service. (If you have N services, create N sub-tasks.)
To save everyone's time, consult
"Providing needed information"
before filing each ticket.

Note that the new PMC chair is still responsible for using modify_unix_group.pl as appropriate.
The group membership is initialized on a best-guess basis, but the chair must check
that it's accurate and add/rm people as needed. The modify_committee.pl data, however,
is initialized directly from the Board resolution and as such should be correct.

Whether you have SSH access to people.apache.org (or to a PMC
jail/zone/VM) via public-key authentication

Whether you ever set up OPIE on any *.apache.org box. (This is only
applicable to people who had root on PMC VMs.)

Whether you have access to the private part of a PGP key associated with
your Apache account.

Whether the contact information on your ICLA is valid.

(ASF Members only) Whether the contact information in your members.txt entry is valid.

Whether you are able to send a new ICLA, with the same signature as your
original one, which specifies new contact information.

Whether there is any other way in which we (infra) might satisfy
ourselves that you --- a person asking us to reset the password
of a given @apache.org account --- is the legitimate owner of that
account.

Note: please do not ask other ASF committers or Members to email root@ and
vouch for you.

On Requests

This section applies to everything from "add a moderator" through
"create an account for a committer" and up to "set up a new TLP".

What can I ask for?

See list of services we run. If you want something that isn't
listed, get in touch --- it might be possible to support it (especially if the
feature request is equipped with volunteers who will help maintain it ---
hint, hint).

Where should I submit my request?

Briefly, if there is a dedicated webapp, use it;
if not, file a JIRA ticket. The
complete answer is in the table above. Please read the table before
filing a ticket - often you or someone in your PMC can effect the change without
involving infra at all.

Before you press Send

Do ask in your project whether someone has the karma to implement the
requested change before asking infra. (This eases the load on the infra
team: we are a dozen volunteers looking after 100+ projects, so we delegate
what we can.) The moderators and volunteer admins of the project's issue
tracker and wiki can often address issues with those services.

Do aggregate requests: instead of sending five emails each asking for
one more moderator to be added, send one email asking for five moderators to
be added.

Do CC your PMC on emails. In JIRA tickets, it is helpful to link to a
thread that demonstrates PMC consensus. (If you request a significant or
major configuration change, we will probably ask for that link if you don't
provide it.)

If you create a JIRA ticket, do create it in the right JIRA component.
(If it's not obvious which component is the right one, it's a bug in the
documentation.) (This helps our volunteers efficiently spot outstanding
tasks in their areas.)

If linking to a file, provide PGP signature or checksum. If to a remote repository, you will be asked to review and sign off on the import ("Yes, that is the repository and history we asked to import and have IP rights for") before it will be writable.

My issue got closed with a request to reopen it.

Then reopen it. Usually we ask that you do something as you reopen it, so do
that too (or say why you didn't).

Background: we tend to close issues that are not actionable upon by us for an
extended period, since we use the INFRA queue as a todo list. In our
workflow, this kind of close/reopen cycle is a matter of ordinary routing
(much like reverting a commit that broke the build
system).

My issue got ignored.

There could be a few reasons: some areas are staffed mainly by
volunteers, so may have longer turn-around times (relative to other
areas); sometimes we're busy on backend projects (e.g., installing new
hardware via our remote hands) and have little time for user-facing
tasks; sometimes an issue blocks on prerequisite new hardware to get
shipped, installed, and configured, which takes time; sometimes
we're just backlogged and are working on issues ahead of yours in the
queue; and sometimes we do tickets of a certain category in batch, and
yours will be done in the next batch in a few days.

If you'd like to inquire as to the status and ensure your issue
doesn't get lost, feel free to add a comment to the relevant JIRA issue
(if any) to that effect, or email the infrastructure@ list with a
question. If the matter remains unresolved after that, feel free to
escalate the matter to the VP, Infrastructure or to the
operations@ privately-archived mailing list (everyone may post to it).

In case of emergency

The following describes how to page root@ people when there is an absolutely
urgent problem, such as a malicious cracker having an active root shell on
archive.apache.org. This is only intended for pressing, ASF-wide problems
that must be handled at once, even if that means waking people up in the middle
of the night or having them miss their flight.

Normally, pinging #asfinfra or emailing root@ or infrastructure-private@
suffices. Pinging people privately (via email, Hipchat, or twitter) is generally
discouraged as then only a single person is aware of a request. . If all of these
have been exhausted, or are not sufficiently timely, the last resort is to look
up root@ people (see list of names here or here) and call them or SMS them.

Finally, the VP Infrastructure has the authority to
contact third parties directly. The contact information is available
to him via docs/vp/littleblackbook.txt.

Reminder: this facility is for emergency use only. It wakes people up.