• The apocalypses/exegeses aren't at all necessary for participating in Parrot development. They're quite long, and unless you're going to be working on the perl6 compiler, not all that relevant to the current development directions. It's just as good to know other potential target languages well.
• BUT: Please do consider working on the perl6 compiler! It's mostly inactive right now, and there are a ton of things that can be done on it even without any further progress on the language spec.
• Yes, you can certainly be of help even if you don't know C or Perl. The rest of this list will suggest things that need work, not all of which require programming:
• Documentation. We have some, but it's not all that coherent. There are a few starts on introductory docs, but nothing that really ties everything together. And some of the docs are, of course, out of date.
• Testing. The main areas that could use more tests are the perl6 compiler and the IMCC intermediate compiler. (What would be personally useful to me is perl6 regex test cases.)
• Benchmarking. We have a couple of small benchmark programs, but the overall state is very primitive. Nothing is standard, and there is very little in the way of a harness, or automated comparisons, or reporting.
• Tinderbox. We are very low on tinderbox machines right now. If you have a vaguely unusual architecture OR compiler OR configuration (eg 64-bit Perl, even on a 32-bit arch), then we could really use more tinderbox machines. We currently have zero Windows tinderboxen running.
• Development. There are lots of things to be done. The big things at the moment are objects, exceptions, and metadata. And there are plenty of other things, too. (Oh, another one: integrating all of the various languages' builds and tests.)

Some parts of Parrot are easy to understand and get involved in. Others are difficult, and will require reading through the archives to avoid repeating the same paths we've already covered. (In fact, that's another useful documentation contribution -- if you see something that keeps coming up over and over again, people appreciate summary documents that describe the various approaches we've considered and their advantages and disadvantages.) But it's a friendly list, so don't worry about people threatening to disembowel your relatives and pets if you say something that's been said already. You will need to subscribe to perl6-internals in order to participate effectively, and as with most development lists, patches usually speak louder than words (even for documentation).