logos-messaging/pm
1
0
Fork 0
mirror of https://github.com/logos-messaging/pm.git synced 2026-01-05 23:53:12 +00:00
Code Issues Packages Projects Releases Wiki Activity

Include multiple client conclusion

Browse Source 
- go-waku only focuses on status-go
- bindings step to expose new protocol on binding API
- docs should include protocol explanation
This commit is contained in:
fryorcraken.eth 2024-01-24 14:50:08 +11:00
parent 010bb52073
commit 9bedaf037a
No known key found for this signature in database
GPG Key ID: A82ED75A8DFC50A4
1 changed files with 26 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

48
PROCESS.md
View File

@ -39,23 +39,24 @@ Each Waku subteam lead (or selected member) is accountable for the delivery of t
Typically, each *milestone* will be divided in the following *epics*: Typically, each *milestone* will be divided in the following *epics*:
| Epic Label Prefix | Owner Sub-team | Output | Description | | Epic Label Prefix | Owner Sub-team | Output | Description |
|-------------------|-------------------------|------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| |-------------------|--------------------------|------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `E:research` | Waku Research | PoC, RFC, Protocol Simulations/Studies | Initial work done by the research team to create or change a protocol. Engineering-only Milestones may not have such epic | | `E:research` | Waku Research | PoC, RFC, Protocol Simulations/Studies | Initial work done by the research team to create or change a protocol. Engineering-only Milestones may not have such epic |
| `E:nwaku` | nwaku | MVP quality software | Bring software to MVP level, proceed with re-architecture of PoC if needed, ensure functionality is usable, refine APIs, auto-generated/API documentation, ensure interoperability works | | `E:nwaku` | nwaku | MVP quality software | Bring software to MVP level, proceed with re-architecture of PoC if needed, ensure functionality is usable, refine APIs, auto-generated/API documentation, ensure interoperability works |
| `E:js-waku` | js-waku | MVP quality software, including all supported env (e.g. React Native & Web) | Implement protocol in js-waku, same as nwaku. | | `E:js-waku` | js-waku | MVP quality software, including all supported env (e.g. React Native & Web) | Implement protocol in js-waku, same as nwaku. |
| `E:go-waku` | go-waku | MVP quality software, include all supported bindings (i.e. C and Rust) | Implement protocol in go-waku. May not always be relevant - need to conclude multiple client discussion. Otherwise, same as nwaku. | | `E:bindings` | nwaku | MVP quality software for supported bindings (WIP) | Expose new protocol/features on binding APIs. |
| `E:qa` | Vac/DST | RFC-based + functionality based tests, both unit and integration tests. | Test engineers take over and complete unit tests + add scenarios in integration test framework. In future, also add scenario to benchmark suite. | | `E:go-waku` | go-waku | MVP quality software, include all supported bindings (i.e. C and Rust) | Implement protocol in go-waku, only if needed by Status app. |
| `E:dogfood` | js-waku, go-waku, nwaku | Lab example updates, own nodes updated, etc. | Each dev team proceed by dogfooding the feature/API by using it themselves. Whether it is running their own node, or updating a selected number of examples. | | `E:qa` | Vac/DST | RFC-based + functionality based tests, both unit and integration tests. | Test engineers take over and complete unit tests + add scenarios in integration test framework. In future, also add scenario to benchmark suite. |
| `E:docs` | Doc | Documentation (not auto-generated) | Document the new feature across all implementations, using the dogfooding output as handover material from engineering teams. | | `E:dogfood` | js-waku, nwaku, bindings | Lab example updates, own nodes updated, etc. | Each dev team proceed by dogfooding the feature/API by using it themselves. Whether it is running their own node, or updating a selected number of examples. Go-waku can dogfood directly in status-go. |
| `E:eco-dev` | Eco Dev | Dev Rel assets (examples, video tutorial, etc), comms plan (X threads, blog posts) | Dev Rel can now prepare assets to push the feature to developers, comms can prepare copies to communicate about it, BD can push it to projects and partners. | | `E:docs` | Doc | Documentation (not auto-generated) | Document the new feature across all implementations, using the dogfooding output as handover material from engineering teams. This includes both coding guides but also a presentation ready visual documentation of the protocol behaviour. |
| `E:eco-dev` | Eco Dev | Dev Rel assets (examples, video tutorial, etc), comms plan (X threads, blog posts) | Dev Rel can now prepare assets to push the feature to developers, comms can prepare copies to communicate about it, BD can push it to projects and partners. |
```mermaid ```mermaid
flowchart LR flowchart LR
subgraph milestone [Milestone] subgraph milestone [Milestone]
scope[Define scope and estimate] scope[Define scope and estimate]
end end
subgraph researchE [E:Research] subgraph researchE [E:research]
scope-->research[RFC + Protocol Simulation + PoC] scope-->research[RFC + Protocol Simulation + PoC]
end end
subgraph nwakuE [E:nwaku] subgraph nwakuE [E:nwaku]
@ -67,20 +68,23 @@ flowchart LR
subgraph go-wakuE [E:go-waku] subgraph go-wakuE [E:go-waku]
research-- Handover -->go-waku[MVP, API, Code doc, unit test] research-- Handover -->go-waku[MVP, API, Code doc, unit test]
end end
subgraph qaE [E:QA] subgraph go-wakuE [E:bindings]
research-- Handover -->go-waku[API, Code doc, unit test]
end
subgraph qaE [E:qa]
nwaku--Handover-->QA[QA, extended, interop and RFC-based testing] nwaku--Handover-->QA[QA, extended, interop and RFC-based testing]
js-waku--Handover-->QA js-waku--Handover-->QA
go-waku--Handover-->QA go-waku--Handover-->QA
end end
subgraph dogfoodE [E:Dogfood] subgraph dogfoodE [E:dogfood]
nwaku-->Dogfooding[Developer use new software and API, interoperability] nwaku-->Dogfooding[Developer use new software and API, interoperability]
js-waku-->Dogfooding js-waku-->Dogfooding
go-waku-->Dogfooding go-waku-->Dogfooding
end end
subgraph docsE [E:Docs] subgraph docsE [E:docs]
Dogfooding-- Handover -->Docs[Update and create guides] Dogfooding-- Handover -->Docs[Update and create guides and protocol documentation]
end end
subgraph ecodevE [E:Eco-Dev] subgraph ecodevE [E:eco-dev]
Dogfooding-- Handover -->Eco-Dev[Dev Rel and BD assets, plan Comms] Dogfooding-- Handover -->Eco-Dev[Dev Rel and BD assets, plan Comms]
Docs-->Eco-Dev Docs-->Eco-Dev
end end
@ -88,7 +92,7 @@ flowchart LR
### Engineering-Only Milestones ### Engineering-Only Milestones
Some milestones may not involve the Waku Research team. In this case, the flow still applies but `E:Research` is skipped. Some milestones may not involve the Waku Research team. In this case, the flow still applies but `E:research` is skipped.
### Chat SDK and other Special SDK Work ### Chat SDK and other Special SDK Work
@ -96,17 +100,17 @@ The Chat SDK team is focusing on go-waku integration in status-go and follows St
Once the team starts building an independent Chat (or other) SDK, the flow will be as above but with research handled by VAC/ACZ and only one dev team: Once the team starts building an independent Chat (or other) SDK, the flow will be as above but with research handled by VAC/ACZ and only one dev team:
| Epic Prefix | Owner Sub-team | Output | Description | | Epic Prefix | Owner Sub-team | Output | Description |
|-------------|----------------|----------------------------------------------------|------------------------------------------------------------| |--------------|----------------|----------------------------------------------------|------------------------------------------------------------|
| `E:ACZ` | Vac/ACZ | RFC | RFC describing a specific, likely agnostic protocol | | `E:acz` | Vac/ACZ | RFC | RFC describing a specific, likely agnostic protocol |
| `E:SDK` | Chat SDK | PoC and then MVP quality software, Application RFC | Implement the ACZ RFC, define API and application protocol | | `E:chat sdk` | Chat SDK | PoC and then MVP quality software, Application RFC | Implement the ACZ RFC, define API and application protocol |
Handover to QA, Docs, Eco Dev with MVP quality software is still expected down the track but may be pending growing teams. Handover to QA, Docs, Eco Dev with MVP quality software is still expected down the track but may be pending growing teams.
### Accountability ### Accountability
Each epic should have an owner per subteam. Each epic should have an owner per subteam.
Most epics will have a unique owner (e.g. a Waku Research team member owns a `E:Research` epic). Most epics will have a unique owner (e.g. a Waku Research team member owns a `E:research` epic).
For _Dogfood_ and _QA_ epics, one owner per client should be set. For _Dogfood_ and _QA_ epics, one owner per client should be set.
The epic owner is responsible for breaking down the work in smaller issues in the related repo. The epic owner is responsible for breaking down the work in smaller issues in the related repo.