My take on this:

• 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).

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.