Contents
The ASF Infrastructure provides and manages all infrastructure and services
for the Apache Software Foundation and so for every project.
This infrastructure includes the various machines and their operating
systems, the systems administration, the mailing lists, the version control
systems, the creation of committer accounts, various supporting software, the
establishment of services for each new project that comes via the Apache
Incubator, the distribution mirroring system, the various issue tracker
software, etc.
The ASF Infrastructure is a team of volunteer ASF committers.
Yes, volunteers. We need more ASF committers to assist us.
The Infrastructure team is a "President's Committee" rather than a "project".
Sander Striker chairs the committee at the moment (meaning he
sends regular reports to the ASF board every few months).
There is no precise definition for who is "on the infrastructure team",
the people doing the work are :-). They are all ASF committers.
There are various infrastructure mailing lists. See notes about their purpose and who can subscribe.
As a new volunteer, you will be mainly interested in "infrastructure@" which is
the main list for reporting issues. Please help by answering the simple
questions, like directing people to specific documentation.
Other infra lists are for developing solutions and doing core operations.
The irc channel on freenode.net called #asfinfra is used for
realtime issues and is especially useful when the mail server is down.
There are no logs for this channel. It is open to anyone who subscribes
to the infra mailing lists. We know who you are.
There is a website for infrastructure information at
www.apache.org/dev/
which also includes various information to assist all committers
and developers.
See
Updating the Infrastructure web site.
There is no Infrastructure wiki and there will not be one.
There is a Subversion repository
https://svn.apache.org/repos/asf/infrastructure
which is only available to people on the infrastructure team.
Some of its subdirectories have more relaxed access restrictions.
Talk to us if you need access.
There is a project in Jira for managing issues, called
INFRA.
Anyone can submit issues.
There is a custom policy in place where some issues are marked as more
secure.
ASF Infrastructure is a lot less organised in decision-making than your
average ASF software development project. Sometimes we vote, sometimes
people just do things because they know they make sense. Some people are
more familiar with the configuration of a machine and have the authority
to "lay down the law",
whereas others may have sufficient priviledges to change stuff there but
would only do so after extensive consultation. The only way to learn how
decision-making happens is to hang around on the infrastructure mailing lists and see
what happens. Amazingly big far-reaching decisions are sometimes made after
a 3-minute conversation on IRC. It is the only way Infra can stay productive.
The uptime of the ASF services is amazing considering how many admin hours
we need to spend and how little hardware resources we have to do loads of
stuff. We are very sensitive about protecting that service level, which is
why we are sensitive about giving people access to stuff. If there are a
lot of root people who know you and know how good you are at sysadmin, you
might get karma real easily. Otherwise, you might not. It is not
particularly "fair", and it certainly isn't neccessarily a "meritocracy",
but its the only way we know that guarantees our service level. Don't
take it personally.
In addition, the ASF does have certain sensitive data which
is dubbed "members-only". Therefore, there are some machines on which only
ASF members can gain login access. Root access is restricted to members
on most machines.
You do not need to be a top-notch sysadmin to help out (although that would
certainly be appreciated). There are many small tasks that you can help with,
and will learn about others as you go.
You need to be able to use SVN. You need to use Jira for some things and
e-mail for other things. Which method to use is not properly documented, but
will be explained on a case-by-case basis. You need to be able to handle
loads of emails. You need to do proper quoting. You need to use descriptive
and proper subject lines. You need to be familiar with the contents of
www.apache.org/dev/ website. You need to start small by submitting patches,
rather than expecting karma. You need to do as much preparation work for any
particular task as possible, to minimize the time a root person needs to
spend on it.
The Infra team is always very busy and consists of volunteers only. Please
always take that into account. Please don't ask questions that have been
asked before. If you ask a question to which the answer is not in the
documentation, please submit a documentation patch. If you know the answer
to a question, please always answer it even if you are not otherwise an
active Infra participant.
If a service is down, discussing it on #asfinfra is probably a better idea
than sending an e-mail about it, since usually the Infra team is already
aware of that anyway and working on it (we have monitoring systems and alerts).
Especially if there seems to be an issue with e-mail, don't send e-mail about
it (you would be surprised how many people do), rather jump on IRC and see
if you can help.
-
Read infrastructure mailing lists and be aware of what is going on. Read #asfinfra as well.
-
Work on documentation, especially procedural documentation and answers to
FAQs. It is more effective if we can simply refer people to a webpage.
-
Answer questions that other people ask on infrastructure@. This is immensely
beneficial to the rest of the team, as it allows them space to get on with
other things.
-
Work through the Issue Tracker and submit patches, comments, links, etc, that
may help in resolving them.
-
Look for support requests on infrastructure@ as they come in and volunteer to
handle them.
-
Add entries to the Issue Tracker for issues raised via e-mail that are
not yet being handled. We don't want them slipping through the cracks.
-
Hang out for a while until you become familiar with processes and people.
-
Thoroughly research an issue when you request a change, and provide the
results of your research in an easy to digest, easy to verify format. Don't
expect people to take your word for things, but provide relevant links.
Provide sample commandline statements you think may work for resolving a
particular task if possible. At a minimum, always RTFM!
-
Be conservative in sending e-mails. Keep e-mails concise and to the
point. Send as few e-mails as possible.
-
Say "thank you" every now and then, but don't spend an entire e-mail on
that.
-
Don't complain.
-
Be patient, very patient. Certain requests may be handled in a day,
others may take a week or two, more if its a complex issue, or indefinitely
if you didn't RTFM or didn't research your request properly.
-
Don't volunteer for stuff, and then not finish it. If you have troubles
then always ask for help.
-
Don't just come here to look after your pet project. We need people
to attend to issues across the whole ASF.
A time will soon come where you will see a lot of areas that need attention
and you'll become aware of what kind of attention they need. You can then
volunteer to give that attention, or at least write up a problem description
and potential solution process, and file that in the Issue Tracker.
Basically, we don't really need more root people. What we need is people who
help to make the root people more productive, and free them from the tasks
which do not require root access. That may not sound very glamorous, but it
is very very neccessary that it is done. That is very much appreciated.
The above guidelines may sound a little harsh and unthankful, but
that is an unintended side-effect of trying to be productive and keeping
everything afloat. Most of us are really nice in person :-)
|
