On Thu, Jul 17, 2003 at 03:53:45PM -0700, Tim Howell wrote: > I've got some extra time to spend on Parrot in the next few months and > I'd really like to get involved. I have decent C and perl skills. > Where would I be most useful?
Having answered a few of these queries, each time in a somewhat different way, I'll give you the answer that I think I've finally settled upon: The most useful thing for Parrot right now is to have more people who have a large percentage of the project in their head. By that, I just mean people who have detailed familiarity with several parts of the system, and a good overall picture of where things stand and what's left to be done or improved. The overall picture often follows from the details. In order to get there, first download it and compile it. Read a few tests to get a feel for PASM (or PIR (.imc)) code, and write up a simple example and run it. Read through as much of the introductory documentation as your attention span allows, and make an effort to understand the system by way of the documentation. This will not work. The documentation is too unfocused, obsolete, and incomplete. Do what you can to fix it. (Either submit patches, ask questions and submit patches after you get answers, or figure things out for yourself and submit patches with the results.) Or clone Simon Glover, and he'll beat the docs into shape for you. Then, when you realize you've sailed well off the end of the intro docs, start diving into the specific areas that hold the most interest for you. A happy hacker is a good hacker. Read the docs specific to that area, if any. Search through the mailing list archive for relevant messages. Monitor the mailing list to keep abreast of the current thrust of development. Through all of this, ask lots of questions. The mailing list is still very beginner-friendly, in part because there are quite a few people lurking about with fresh scars from clawing their way into the project. Submit patches. A common trick, when your query "why does X work the way it does? I'm sure there's a good reason, but on the face of it the whole thing looks absurd." is ignored, is to change it to what you think it ought to be and then submit a patch. You may stumble upon the reason along the way, and if not, many people here will pay more attention to a patch than a question. Sometimes it's simply because it's easier understand what you're driving at when you show code, even if it's just a small piece of what would be the final solution. And sometimes it prods people into responding for fear of your patch getting applied. Oh, I guess I should say to read the TODO file. At this point, that would mostly be good so that you can patch it into being accurate.
