Vinh NguyenWelcome to the PDL process guidance documentation. The purpose of this guide is to succinctly explain the product development lifecycle, offer a concise release checklist, and provide succinct guidance for a quality release.
Methodology
This process guidance is written with a decentralized development nature in mind along with a decentralized organization.
Traditional organizations (such as Raytheon, Caterpillar, etc.) working with safety-critical solutions have rigorous controls from design to release that specifically define how a product is made. Under the context of a decentralized and volunteer driven organization, however, this is unsustainable and impossible to enforce. No products will get released.
A completely loose approach and an equally disjointed "organization" (akin to FOSSCAD) however, creates a large quantity of products, but with a low fidelity of quality and documentation. This too is unsustainable. More rubbish than gems are released.
The "Funnel Approach" seeks to meet in the middle of these extremes. Developers are free to engineer and test how they please, but as they get closer to a release, it is expected that they follow guidelines to ensure quality, with a final release requiring that the package satisfy a checklist and subjective review.
At the "top" and broader end of the "funnel", developers are free to design and test however they please. Not only does this maintain creative freedom, but it also retains the unyielding flexibility of experimentation and self-evaluation. No restrictions on how they maintain or version control their designs are imposed even.
At the "middle" of the funnel where it begins to narrow, developers submit their designs for a wider audience to test. Some discipline here is expected- developers are to be active within their beta rooms and respond to user feedback and questions. While infrastructure, such as GitLab for version control or issue tracking is offered, developers are not required to use these tools. These tools are offered to help a beta go smoothly.
At the very "end" of the funnel, the most narrow part of it, developers must finalize their beta and their deliverable archive must satisfy the Release Package Requirements checklist. Their product and documentation also undergoes a subjective review with Gatalog leadership to ensure a high fidelity of quality is present, rather than just "checking the boxes." At this point, if all goes well, the deliverable is then published to the Gatalog Odyssey page, and publicized.
Stages of development
Internal Development and Design
Beta Testing
Now you are ready to start a beta. Check out this guide on how to pull it off.