This document rocks. I think it really embodies what perlmonks is to me. In the interests of providing a snappy, concise document, I have some suggestions for the intro.

If you are an experienced Perl programmer who simply has not posted before, we apologise for inconveniencing you.

I'd strike this sentence. The document is very good info for experienced perl coders who happen to be new to perlmonks. Item #2 definitely shouldn't be apologized for.

If you are new to Perl you will often find the answer you seek is already available, so if you need it yesterday have a look through these links.

IMHO, strike this too. This is addressed in item #1 just below.

We believe there are no stupid questions, so if you can't find an answer just ask.

This is an *excellent* sentence. I would move this into item 3, for when the reader is thinking about asking questions.

And I would move the last two sentences to the end of the document, just before credits, otherwise we're saying goodbye to them in the middle of the document they're supposed to read all of.

With these changes, the document would flow like this:

-----------

Welcome to the Monastery!

This node is being developed as a collaborative effort by Perl Monks to help people who may be unfamiliar with online forums in general, or sites based on the Everything engine which drives the site in particular. This is the 'Executive Summary' - for a more detailed version of this doc and its history click New Monks. New posters to Perl Monks may (in the fullness of time) be sent a link to here to provide a useful entry point to all things Monastery and Perl. This is our attempt to help newcomers get the most out of the monastery and a language we love.

1. Instant answers for common Perl problems

Perl Monks has its own extensive Question and Answer section which has a different focus from the standard Perl FAQ. Most common perl coding problems are addressed in these two documents.

2. Please, please, please use the following

#!/usr/bin/perl -w # "-w" turns on all sorts of warnings about probable errors. 

use diagnostics;   # optional; causes warnings to be explained in greater detail.

use strict;        # generates compile and run-time errors for certain unsafe constructs.

3. Getting Answers

We believe there are no stupid questions, so if you can't find an answer just ask. To get the fastest, friendliest, most useful answer we recommend you read these:
How to get the most of your question from the monks | Before You Post ...

-----------
then at the bottom:
-----------

7. Want more?

For extensive link lists try ybiC, merlyn, outside links, or new monks for starters.
Hope to see you back soon.

Cheers!

-----------

___
-DA