How We Crowdsource Innovation, Part Deux
Today, a revised version of our Whitepaper went live on our website. In it we outline our general approach to harnessing our capacity for innovation and driving it towards impactful engineering projects.
Over the next few months I’d like to expand on several aspects of the whitepaper. Today, I would like to discuss the process we intend to use to scrutinize community-driven projects. If you have questions, or want to converse with some of the team, I encourage you to visit our telegram channel.
We begin with a concept, coming from a member (or members) of the community. It can be as simple as a sketch on a napkin, or as detailed as a CAD assembly drawing. It can start with exploring a pressing problem, or it can start by identifying a solution. The community ideates, with unfettered collaboration occurring while the signals generated during the process help to define and solidify specifications within the project. The concept evolves organically, as do social reputations of members within the community. Ideas, concepts, know how, and research documents are all aggregated and attached to a project during this stage, with the outcome requiring a proposal to be crafted.
The proposal must include milestones and associated budgets to structure a logical development path. For this, we’re taking inspiration from NASA’s Commercial Orbital Transportation Services (COTS). The purpose of the COTS program was to lower NASA’s costs while giving COTS partners incentive to design, build, and demonstrate their systems in a timely manner. This would allow the community to agree on fixed milestones with success criteria to evaluate the lifecycle of the project, and allocate resources in a logical and metered way. Similar to a DAICO, but on a project by project basis.
Ultimately, we want a thorough amount of study and sufficient signalling from the community before a project is adopted by the network. This is to mitigate ‘hype’ or perpetual motion projects.
Once a proposal is completed, we move into a compliance review phase. This allows the network to confirm the proposal is sufficiently thorough or whether it requires further development before progressing. In order to reduce proposal spam, we will require a number of RLP to be bonded to the proposal at time of submission - if the proposal passes the compliance review the RLP is returned, if the proposal fails the compliance review the RLP is forfeited to the rLoop Network. The rLoop Core Team will always available to provide input before the compliance review phase.
Next we source relevant external domain experts to review the proposals and provide their feedback. This is one of the ways we try to engage experts and collective groups, which cognitive science shows is a highly effective model. These reviewers provide feedback across a variety of categories which would be dependent on the projects. The reviewers will also be sourced based on the specific needs of the project.
Now the rLoop Community has a thorough ‘report card’ for the proposal, which includes visibility on all of the signalling and collaboration from the community during the ideation process, a proposal with milestones and associated budgets, a compliance review approval, and a score card from external experts. An educated decision on which projects are best suited for the network to adopt can now be made.
The desired end goal of any project is functional hardware. The end product of certain projects may just be knowledge, but they will be contributing to the rLoop knowledgebase — a network-wide resource that will be the topic of another post!
P.S. I wanted to congratulate the design team on the Whitepaper, I think it looks fantastic! And if you have questions, or want to converse with some of the team, I encourage you to visit our telegram channel.
