Rules of Engagement
Waku is a nascent technology and the Waku community is still growing. Hence, the Waku team is keen to work closely with projects to help leverage Waku technology to drive the success of their own applications.
We describe below the expected flow for working with Waku and some rules of engagement to set expectations for project teams interacting with the Waku team.
1. Initial discussion
We encourage the initial discussion to happen over a video call. However, in-person event or online discussions are also an option.
During this initial interaction, the project team should present their product and the needs they have in relation to peer-to-peer communication and real time interaction.
The Waku team will provide an overview of Waku and point to specific protocol and software that should help fulfil such needs.
Benefits and caveats are highlighted and further documentation and examples will be provided.
2. Solution design
Projects should review Waku documentations and libraries in their own time; start building a PoC using Waku.
Projects should start designing over Waku and come up with skeleton design or user flows about specific friction points or complex area (e.g. user experience, scaling).
Project should appoint one or two Waku SME (Subject Matter Expert) to drive most discussions with Waku team to start acquire expertise on Waku behaviour.
Project's Waku SMEs should present unresolved design issues to Waku team.
The Waku team will then review and provide skeleton design solutions on how to overcome said unresolved or complex issues.
3. Commitment
The project should finalise a design, solution or protocol they will build using Waku.
If they wish to, they can present this solution to the Waku team to get feedback and identify technical gaps.
The Waku team can provide feedback, highlight potential caveats, and communicate on delivery timeline for gaps, if any.
While the Waku team can provide feedback or even design potential solution on how Waku could be integrated in an application. It is the responsibility of the project team to understand the potential caveats and limitations that may incur with such a design.
The Waku team can provide options, but it is up to the project team to decide on the final solution.
4. Building
The project then start building their MVP using Waku. The Waku team can provide support regarding API usage, bugs encountered, documentation gaps.
Waku team will use feedback raised by project to improve APIs, fix bugs and enhance documentation. Waku team continues R&D to deliver any committed technical gaps.
Project delivers their MVP.
The Waku team is keen to help any usage of Waku library. Please note that code snippets are necessary for preliminary investigations of issues.
Sometimes, a code snippet is not enough; in this case, a minimal reproduction repo is necessary to allow us to do further investigation. If the project is open-source, then the Waku team might try to further investigate using it, as long as the reproduction steps are easy.
If no code is provided to help with the investigation, then there is nothing the Waku team can do.
For any unresolved issue, the project must open an issue on the related GitHub repository under the waku-org organisation.
5. Ongoing relation
Once the project application is live, the Waku team is keen to maintain regular contact. This can include discussion around performance, bugs found by users, etc.
The Waku team is keen to regularly present new and upcoming development to project team, highlight items that are particularly relevant.
If a project wishes to take onboard any new Waku protocol, or decide to extend their product with a new functionality using Waku, the circle can resume from step 1.