First, you can use the WYSIWYG editor, although for proposals it is better to modify wiki markup by hand. The WYSIWYG editor is never as good as hand-markup if you are a heavy user of macros, or cool things like templates. Thankfully, on the right-hand side of the editor is a quick help guide that is visible at all times. You can click that link for the full guide (at the top of the Help Tips) to see all markup options. It's based on Textile and pretty easy to learn, and generally good to know when working on the wiki.
h3. When I put PHP code in my page, why do I get errors?
You need to wrap the code with {{\{code\}}} tags before and after the code sample. Otherwise, the open and close curly braces will appear to be wiki tags.
h3. What should I concentrate on for my proposal?
In the early stages, concentrate on use cases, goals, and the purpose of the proposal so that the design can be measured against these requirements. Later, flesh out the API and class relationships, along with the theory of operation (how you perceive it will work). Once those elements are fairly stable, start to concentrate on the code.
h3. When will my proposal move to the Laboratory?
If your proposal shows promise but doesn't directly contribute to the current roadmap, it may be accepted into the Laboratory for continued development as a component. In this case, your project will receive space in the Subversion repository and an issue tracker assigned to it. Successful Laboratory projects are candidates for future inclusion within the framework core.
h3. When will my proposal move to the Incubator?
Accepted core proposals are moved to the Incubator and become part of the main release track. If your project was previously a part of the Laboratory, its issue tracker and repository will move into the main project at this time. For proposals moving directly into the Incubator, repository space will be created.
Laboratory projects without basic DocBook documentation and unit testing are unlikely to move into the Incubator. Also, please following the [Zend Framework coding standards|ZFDEV:PHP Coding Standard (draft, ZF 0.2 RC1)], as that can also be a blocking point.
h3. Do I need to include requirements, acceptance criteria, milestones, and so on?
Yes. Often the details and number needed are quite small, but without knowing the requirements and milestones, how will the community know the status of the component, when it will be "done", and what should be expected when it is?
...