NOTE: When creating a new proposal and you are editing the Wiki markup for it, you may click on the Preview pane to see what it looks like before you Save. Currently, the Preview pane for this plugin generates several errors that we are working on fixing. Do not be alarmed by the errors; your page should Save just fine provided that the Wiki markup is valid. In any case, you can always edit the page, so please do not postpone saving your new proposal because of errors on the Preview pane, and we will strive to fix the problem as soon as reasonably possible. Thank you for your continued patience!
NOTE: this page is editable by everyone, so if it isn't clear, update it!
From the Zend Framework Proposal Home Page you will find a link to create a new proposal. This will ask you for the name, usually something like "Zend_Magic Proposal" and then create a proposal from a template, and fill it with sample data. This page is now saved and ready for editing. Instructions for the basic steps that need performed will be at the top of the page.
These tags wrap the content for your proposal. By looking at the sample data and by looking at the page in view mode, you can infer the meaning of each. When you enter edit mode, just replace the sample contents with your own to fill out the proposal. What you are doing is really just setting the value of variables that a template will render against to create your page when viewed.
These tags allow us to apply a template in real time to the proposals so that we can change the formatting, add new fields, and keep uniformity between the proposals.
If you make a mistake, or accidentally remove any tags, just look at the source of another proposal to find what you are looking for.
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 in how you perceive it working.
Once you are fairly stable with those elements, then start to worry about code.
When proposals are moved into "under review" they will have a issue tracker setup for them, as well as possibly a Laboratory SVN project created if coding needs to be done to prove out the proposal.
Proposals that are not accepted into Incubator right off, may want a Laboratory SVN project to support ongoing development so that they can continue to work on the component. The issue tracker will work hand-in hand with that as well.
Accepted proposals will move to Incubator meaning that they are part of the main release track. Their issue tracker will merge into the main framework project and become a component of that project rather than a stand-alone project. Their SVN repository (if they have one in Laboratory) will move into a subdirectory within the main project.
Projects are unlikely to move to Incubator that do not have basic DocBook documentation and are showing signs of having decent test coverage. Also please following the [Zend Framework coding standards] as that will be a blocking point as well.