Welcome 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

Every idea starts from somewhere. Generally you have free reign on how to develop your own project- the process gating comes in when you begin to test with the public or with a group, along with preparing documentation.

Beta Testing

Now you are ready to start a beta. Check out this guide on how to pull it off.

Having a controlled beta test and a place to collect feedback is important. Some developers think that simply releasing to the public as a "beta test" is enough. (It is not.) Doing so makes it difficult to gather feedback, gauge adoption, or maintain communication with a quality set of testers. It will also add to the mound of untested rubbish that archivers will collect and bundle (which can be dangerous in terms of safety).

Final Packaging

Your product's release package (or repository) must satisfy the (Release Package Requirements)[https://gitlab.deterrencedispensed.com/deterrence-dispensed/information-and-tutorials/-/wikis/For-Developers/Resources/Release-Package-Requirements] checklist.

In the checklist, a standard folder structure is defined for your package, along the requirement for an Assembly Guide PDF. This PDF is very important- it contains essential information on assembly and troubleshooting for your design.

The goal of the final release package is simple: conclusively deliver everything needed to build and assemble the product. This includes everything from a parts list, instructions, models, and the sources themselves.

Release

To submit your project for release under the Gatalog, contact a beta administrator or moderator. Your project's packaging will be reviewed based on the objective checklist above, and subjective quality of your documentation.

After this, it's hands-off for you from here, unless your project gets returned to you with feedback on items to address before release. Your project will be uploaded to the Gatalog's Odysee page and promoted on social media.