From 2ccfff5b352d2161fc44d80761d91acaa2113e04 Mon Sep 17 00:00:00 2001 From: "fryorcraken.eth" Date: Wed, 10 Jan 2024 15:07:06 +1100 Subject: [PATCH 1/9] Update PM process --- README.md | 150 +++++++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 119 insertions(+), 31 deletions(-) diff --git a/README.md b/README.md index caa8f2a..c4ec863 100644 --- a/README.md +++ b/README.md @@ -1,14 +1,18 @@ # Waku Project Management -Tracks/coordinate effort/tasks that targets Waku as a product across implementations (production readiness, scalability, etc). - ## Teams -The Waku Team is currently split in the following subteams: +The Waku Team is split in the following subteams: - Waku Research -- Waku Development (nwaku, js-waku, go-waku) +- Waku Development nwaku, js-waku, go-waku - Waku Eco Dev (DevRel, Docs) +- Waku Chat SDK + +The Waku Team also gets the support from other Logos groups, in particular: + +- Vac/DST: Distributed System Testing Team for simulations and QA/Testing +- Comms Hubs: For communication, marketing, digital content, etc. ## Work Tracking and Reporting Guidelines @@ -18,23 +22,92 @@ The current reporting requirements are 2 folds: #### 1. Weekly Reporting -Weekly reporting on work progress by milestones. +Weekly reporting provides an insight on the progress by milestones. #### 2. Monthly Reporting Monthly reporting is now handled by the Logos insight team. -### Terminology +### Terminology and Scope -| Name | Number of | Timeframe | Team Scope | Owner | Description | -|-----------------|-----------------------------------------|----------------------------------------|----------------------------------------------|-----------------------------|-----------------------------------------------------------------------------| -| (Key) Milestone | 1-3 per year | Set yearly-ish/as needed | Most subteams | Waku Lead | Key achievements for the Waku project, historical milestones. | -| Epic | Several per milestone | Set for a milestone, delivered monthly | Several subteams or external team (e.g. DST) | Team Members | Chunk of a _Milestone_ across all clients. | -| Task | Many per Epic | Set monthly-ish, delivered weekly | One subteam or individual | Team Member | May be one or several piece of work, client specific. | +| Name | Number of | Timeframe | Team Scope | Owner | Description | +|--------------|-----------------------|------------------------------------------------|-------------------------------------------------|------------------------|-------------------------------------------------------| +| Deliverable | 3-5 per year | Set yearly for grant request | Waku Team | Waku Lead | TBD | +| Milestone | ? | Pencilled for the year, planned for 2 quarters | Most subteams | Waku Lead | A, or cohesive set of, feature(s). | +| Epic | Several per milestone | Set for a milestone | Usually one subteam or external team (e.g. DST) | Subteam Lead or Member | Milestone work for a given subteam. | +| Task | Many per Epic | Set monthly-ish, delivered weekly | One subteam or individual | Team Member | May be one or several piece of work, client specific. | -### Epic Owner Responsibilities +### Milestone Definition -Each epic should have an owner per affected subteam (research, js-waku, go-waku, nwaku). +A *Milestone*: + +1. **Provides a tangible user benefit:** The milestone should aim to provide a distinct benefit or feature to the user, whether they are end users, operators or developers. In some case, a milestone may be a bundle of small features. The bundle of features should be cohesive and the benefit to the users should be easy to summarize. Most likely, a bundle milestone will be scoped to a given track. +2. **Minimal Scope:** The milestone should be trimmed to a minimal scope, encompassing only what is *just enough* to assess the potential impact of these features on the project's metrics (e.g. number of users, revenue). This means descoping any advanced features and aiming for a MVP-level delivery. +3. **Transversal:** While the vertical scope of a milestone should be minimal, the delivery should be complete in terms of research, engineering, QA, documentation and dev rel assets so that the feature can be pushed to users once the milestone is marked as complete. Feedback loops should be as small as possible to ensure the value of a milestone is measured in a timely manner. +4. **Attached Estimate:** An estimate should be associated with the milestone to facilitate the measurement of potential ROI. Additionally, tracking the estimate versus the actual progress is crucial for identifying any deviation and making informed decisions (e.g., deciding whether to continue if we learn the estimate is likely to be overrun). + +### Epics and Workflow + +A *milestone* is divided in *Epics*. Each *epic* is assigned to a given subteam. + +Waku lead is accountable for the delivery of a *milestone*. + +Each Waku subteam lead (or selected member) is accountable for the delivery of their epic. + +Typically, each *milestone* will be divided in the following *epics*: + +| Epic 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: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 | Implement protocol in js-waku, same as nwaku. | +| `E:go-waku` | go-waku | MVP quality software | Implement protocol in go-waku. May not always be relevant - need to conclude multiple client discussion. Otherwise, same as nwaku. | +| `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: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:Docs` | Doc | Documentation (not auto-generated) | Document the new feature across all implementations, using the dogfooding output as handover material from engineering teams. | +| `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 +flowchart LR + subgraph milestone [Milestone] + scope[Define scope and estimate] + end + subgraph researchE [E:Research] + scope-->research[RFC + Protocol Simulation + PoC] + end + subgraph nwakuE [E:nwaku] + research-- Handover -->nwaku[MVP, API, Code doc, unit test] + end + subgraph js-wakuE [E:js-waku] + research-- Handover -->js-waku[MVP, API, Code doc, unit test] + end + subgraph go-wakuE [E:go-waku] + research-- Handover -->go-waku[MVP, API, Code doc, unit test] + end + subgraph qaE [E:QA] + nwaku--Handover-->QA[QA, extended, interop and RFC-based testing] + js-waku--Handover-->QA + go-waku--Handover-->QA + end + subgraph dogfoodE [E:Dogfood] + nwaku-->Dogfooding[Developer use new software and API, interoperability] + js-waku-->Dogfooding + go-waku-->Dogfooding + end + subgraph docsE [E:Docs] + Dogfooding-- Handover -->Docs[Update and create guides] + end + subgraph ecodevE [E:Eco-Dev] + Dogfooding-- Handover -->Eco-Dev[Dev Rel and BD assets, plan Comms] + Docs-->Eco-Dev + end +``` + +### Accountability + +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). +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. @@ -42,10 +115,10 @@ For research team, it is expected that most of the research work is done by the - Capturing problem statement - Designing protocol/solution - Implementing PoC in reference implementation -- Running tests/simulations to confirm behaviour (to be offloaded to test engineer once hired) +- Running tests/simulations to confirm behaviour (to be offloaded to test engineer) -For development teams, it is expected that design/break down is done by epic owner. -But actual workcan be picked up by other team member. +For development teams, it is expected that design/break down is done by the epic owner. +But actual work can be picked up by other team member. Epic owner must: - Understand the change and its implications, @@ -58,35 +131,50 @@ However, subsequent/other changes may be picked up in parallel or sequentially b Hence: - dependencies must be clearly stated in _Task_ issue description - Team members must assign _Task_ issues to themselves when work starts -- Team member must update issues to track progress +- Team members must update issues to track progress The program manager should ensure that epics are getting the right assignee in a timely fashion. -For example, when research work starts for a given epic, epic owners from development team should be assigned, so they know to participate in discussions. +For example, when research work starts for a given milestone, epic owners from development team should be assigned, so they know to participate in discussions. Program manager should also ensure that issues are being created in a timely fashion, -an is encouraged to use client PM call as a forum to check epics to be assigned. -For example, when PoC is near completion then breaking down the work should be started. +an is encouraged to use client PM call as a forum to check epics to be assigned, for example when a given epic is near completion. + +#### Handovers + +The following handovers are defined: + +| Handover | Expectations when handing over | Expectations when accepting handover | +|-------------------------------|-----------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------| +| Research to development teams | - RFC PR is merged
- PoC PR is merged | - RFC content and PoC are reviewed
- Own code and functionality
- Own minor RFC changes | +| Development teams to QA | - Happy path and selected error path tests exist
- APIs are implemented to enable interop testing | - Review RFC
- Review existing tests | +| Development teams to Docs | - Working usage of API is provided
- Auto-generated documentation for public API is present | - Review examples
- Understands functionality
| +| Docs to Eco Dev | - Docs PR is merged with functioning code | - Understands functionality
- Execute guides | + + +The group or person handing over is expected to initiate a sync (meeting) or async (chat or GitHub) discussion to go through the output and overview. + +Once the handover is accepted, the given epic can be closed. ### GitHub Usage A _Milestone_: -- MUST have a matching GH issue in the https://github.com/waku-org/pm repo with `milestone` label assigned. -- MUST have a GH Milestone in https://github.com/waku-org/pm repo, to which relevant _Epics_ are added. -- SHOULD have a roadmap to delivery done at planning phase, the GH milestone is then used to track progress. +- MUST have a matching GitHub issue in the https://github.com/waku-org/pm repo with `milestone` label assigned. +- MUST have a GitHub Milestone in https://github.com/waku-org/pm repo, to which relevant _Epics_ are added. +- The GitHub milestone MUST be used to track progress. An _Epic_: -- MUST have a matching GH issue in the https://github.com/waku-org/pm with `epic` label assigned. -- MUST have a label with format `E:` created across all relevant https://github.com/waku-org/ repos (see [labels.yml](./.github/labels.yml)). -- SHOULD be added to a GH Milestone. +- MUST have a matching GitHub issue in the https://github.com/waku-org/pm repo. +- MUST have a label with format `E: `. +- SHOULD be added to a GitHub Milestone. - SHOULD have a `Planned Start` and `Due Date` set (these are GitHub projects fields you can find in the `Projects` section of the issue view sidebar). - MAY list _Tasks_ present in other repos. -- MUST have one assignee **per subteam**, who represent the epic owner. +- MUST have assignee(s), who represent the epic owner (see [accountability](#accountability)) A _Task_: -- MAY be tracked as a todo item in a GH Issue (_Task_ or _Epic_), +- MAY be tracked as a todo item in a GitHub Issue (_Task_ or _Epic_), - OR MAY be tracked as a single GH issue - that MUST be labelled with related _Epic_ label (`E:...`), - OR MAY be tracked as a GH Pull Request - - that MUST be labelled with related _Epic_ label (`E:...`), + - that MUST have a reference to the related GitHub _Task_ or _Epic_ issue - MUST have an _acceptance criteria_ and/or a list of _tasks_ (that can be other GH issues). Finally, for _Tasks_ that do not belong to a given _Epic_ or _Milestone_: @@ -101,8 +189,8 @@ Finally, for _Tasks_ that do not belong to a given _Epic_ or _Milestone_: Which means, in terms of _navigation_: - Work for a Milestone is described in the related GitHub issue and tracked in the GitHub milestone. -- In the GitHub milestone, we have a list of _Epics_ to be achieved, the _Epics_ are being closed as the work is done across all clients. -- To look at remaining work for an _Epic_, one need to look at all issues/PRs (_Tasks_) with the corresponding _Epic_ label (`E:...`) +- In the GitHub milestone, we have a list of _Epics_ to be achieved, the _Epics_ are being closed as the work is done and handed over. +- To look at remaining work for an _Epic_, one need to look at all issues (_Tasks_) with the corresponding _Epic_ label (`E:...`) ### Reporting From 10daef26629913f6d2c7ac5bf13d002d22536019 Mon Sep 17 00:00:00 2001 From: "fryorcraken.eth" Date: Wed, 10 Jan 2024 15:27:27 +1100 Subject: [PATCH 2/9] Mention for SDK --- README.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/README.md b/README.md index c4ec863..8a37b8c 100644 --- a/README.md +++ b/README.md @@ -103,6 +103,23 @@ flowchart LR end ``` +### Engineering-Only Milestones + +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 + +The Chat SDK team is focusing on go-waku integration in status-go and follows Status' PM for issues and labelling. + +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 | +|-------------|----------------|----------------------------------------------------|------------------------------------------------------------| +| `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 | + +Handover to QA, Docs, Eco Dev with MVP quality software is still expected down the track but may be pending growing teams. + ### Accountability Each epic should have an owner per subteam. From 2b1eaf945d08f1cd67d4d43470a6fead531aac28 Mon Sep 17 00:00:00 2001 From: "fryorcraken.eth" Date: Wed, 10 Jan 2024 15:29:13 +1100 Subject: [PATCH 3/9] Update templates --- .github/ISSUE_TEMPLATE/epic.md | 2 +- .github/ISSUE_TEMPLATE/milestone.md | 4 ---- 2 files changed, 1 insertion(+), 5 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/epic.md b/.github/ISSUE_TEMPLATE/epic.md index 09d55c6..1464470 100644 --- a/.github/ISSUE_TEMPLATE/epic.md +++ b/.github/ISSUE_TEMPLATE/epic.md @@ -1,7 +1,7 @@ --- name: Epic Issue Template about: Track Epics -title: "[Epic] " +title: "[Research/nwaku/go-waku/js-waku/docs/QA/Eco-Dev] " labels: epic assignees: '' diff --git a/.github/ISSUE_TEMPLATE/milestone.md b/.github/ISSUE_TEMPLATE/milestone.md index d614db1..b648356 100644 --- a/.github/ISSUE_TEMPLATE/milestone.md +++ b/.github/ISSUE_TEMPLATE/milestone.md @@ -7,11 +7,7 @@ assignees: '' --- -2023 Key Milestones: https://notes.status.im/s/iylE6wdli# - **Milestone**: - -**Priority Tracks**: Secure Scalability, Production Readiness, Growth, Generating Revenue (Sustainability & Longevity). # Summary From 0ff5ed9a31a65bffaa6f2a3cf3db410daa885abd Mon Sep 17 00:00:00 2001 From: "fryorcraken.eth" Date: Wed, 10 Jan 2024 21:26:10 +1100 Subject: [PATCH 4/9] list epics --- .github/ISSUE_TEMPLATE/epic.md | 2 +- .github/ISSUE_TEMPLATE/milestone.md | 10 ++++++++++ 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/.github/ISSUE_TEMPLATE/epic.md b/.github/ISSUE_TEMPLATE/epic.md index 1464470..3c573c1 100644 --- a/.github/ISSUE_TEMPLATE/epic.md +++ b/.github/ISSUE_TEMPLATE/epic.md @@ -1,7 +1,7 @@ --- name: Epic Issue Template about: Track Epics -title: "[Research/nwaku/go-waku/js-waku/docs/QA/Eco-Dev] " +title: "[Research/nwaku/go-waku/js-waku/Docs/QA/Eco-Dev] " labels: epic assignees: '' diff --git a/.github/ISSUE_TEMPLATE/milestone.md b/.github/ISSUE_TEMPLATE/milestone.md index b648356..a26a038 100644 --- a/.github/ISSUE_TEMPLATE/milestone.md +++ b/.github/ISSUE_TEMPLATE/milestone.md @@ -17,6 +17,16 @@ assignees: '' +# Epics + +- research: +- js-waku: +- nwaku: +- go-waku: +- QA: +- Docs: +- Eco-Dev: + # RAID (Risks, Assumptions, Issues and Dependencies) From 4afa1ab76e29eb67a06ec13684a123c80a18e68e Mon Sep 17 00:00:00 2001 From: "fryorcraken.eth" Date: Wed, 10 Jan 2024 21:35:38 +1100 Subject: [PATCH 5/9] typo --- .github/ISSUE_TEMPLATE/epic.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/ISSUE_TEMPLATE/epic.md b/.github/ISSUE_TEMPLATE/epic.md index 3c573c1..176c5ec 100644 --- a/.github/ISSUE_TEMPLATE/epic.md +++ b/.github/ISSUE_TEMPLATE/epic.md @@ -17,7 +17,7 @@ assignees: '' # Acceptance Criteria - + # Tasks From 6c5fd81a7b6aef32d61fe10e5dfeffabd46793f2 Mon Sep 17 00:00:00 2001 From: "fryorcraken.eth" Date: Wed, 10 Jan 2024 22:45:11 +1100 Subject: [PATCH 6/9] Let's not forget about Rust --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 8a37b8c..8252427 100644 --- a/README.md +++ b/README.md @@ -60,8 +60,8 @@ Typically, each *milestone* will be divided in the following *epics*: |--------------|-------------------------|------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | `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:js-waku` | js-waku | MVP quality software | Implement protocol in js-waku, same as nwaku. | -| `E:go-waku` | go-waku | MVP quality software | Implement protocol in go-waku. May not always be relevant - need to conclude multiple client discussion. Otherwise, same as nwaku. | +| `E:js-waku` | js-waku | MVP quality software, including all supported env (e.g. React Native) | Implement protocol in js-waku, same as nwaku. | +| `E:go-waku` | go-waku | MVP quality software, include all supported bindings (i.e. Rust) | Implement protocol in go-waku. May not always be relevant - need to conclude multiple client discussion. Otherwise, same as nwaku. | | `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: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:Docs` | Doc | Documentation (not auto-generated) | Document the new feature across all implementations, using the dogfooding output as handover material from engineering teams. | From a042b3230381de78f65e90bca7915e686279dfce Mon Sep 17 00:00:00 2001 From: "fryorcraken.eth" Date: Wed, 10 Jan 2024 22:45:24 +1100 Subject: [PATCH 7/9] Let's not forget about Rust --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 8252427..7c08d65 100644 --- a/README.md +++ b/README.md @@ -61,7 +61,7 @@ Typically, each *milestone* will be divided in the following *epics*: | `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:js-waku` | js-waku | MVP quality software, including all supported env (e.g. React Native) | Implement protocol in js-waku, same as nwaku. | -| `E:go-waku` | go-waku | MVP quality software, include all supported bindings (i.e. Rust) | Implement protocol in go-waku. May not always be relevant - need to conclude multiple client discussion. Otherwise, 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: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: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:Docs` | Doc | Documentation (not auto-generated) | Document the new feature across all implementations, using the dogfooding output as handover material from engineering teams. | From be525f5a0d639bf4b34f716346d1fcd94b2180c9 Mon Sep 17 00:00:00 2001 From: "fryorcraken.eth" Date: Fri, 12 Jan 2024 16:38:17 +1100 Subject: [PATCH 8/9] Implement feedback --- .github/ISSUE_TEMPLATE/milestone.md | 2 +- README.md | 35 +++++++++++++---------------- 2 files changed, 17 insertions(+), 20 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/milestone.md b/.github/ISSUE_TEMPLATE/milestone.md index a26a038..9f4e685 100644 --- a/.github/ISSUE_TEMPLATE/milestone.md +++ b/.github/ISSUE_TEMPLATE/milestone.md @@ -19,7 +19,7 @@ assignees: '' # Epics -- research: +- research: - js-waku: - nwaku: - go-waku: diff --git a/README.md b/README.md index 7c08d65..1b72682 100644 --- a/README.md +++ b/README.md @@ -32,7 +32,6 @@ Monthly reporting is now handled by the Logos insight team. | Name | Number of | Timeframe | Team Scope | Owner | Description | |--------------|-----------------------|------------------------------------------------|-------------------------------------------------|------------------------|-------------------------------------------------------| -| Deliverable | 3-5 per year | Set yearly for grant request | Waku Team | Waku Lead | TBD | | Milestone | ? | Pencilled for the year, planned for 2 quarters | Most subteams | Waku Lead | A, or cohesive set of, feature(s). | | Epic | Several per milestone | Set for a milestone | Usually one subteam or external team (e.g. DST) | Subteam Lead or Member | Milestone work for a given subteam. | | Task | Many per Epic | Set monthly-ish, delivered weekly | One subteam or individual | Team Member | May be one or several piece of work, client specific. | @@ -50,22 +49,20 @@ A *Milestone*: A *milestone* is divided in *Epics*. Each *epic* is assigned to a given subteam. -Waku lead is accountable for the delivery of a *milestone*. - Each Waku subteam lead (or selected member) is accountable for the delivery of their epic. Typically, each *milestone* will be divided in the following *epics*: -| Epic 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: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) | 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: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: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:Docs` | Doc | Documentation (not auto-generated) | Document the new feature across all implementations, using the dogfooding output as handover material from engineering teams. | -| `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. | +| 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: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: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: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: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:Docs` | Doc | Documentation (not auto-generated) | Document the new feature across all implementations, using the dogfooding output as handover material from engineering teams. | +| `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 flowchart LR @@ -159,12 +156,12 @@ an is encouraged to use client PM call as a forum to check epics to be assigned, The following handovers are defined: -| Handover | Expectations when handing over | Expectations when accepting handover | -|-------------------------------|-----------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------| -| Research to development teams | - RFC PR is merged
- PoC PR is merged | - RFC content and PoC are reviewed
- Own code and functionality
- Own minor RFC changes | -| Development teams to QA | - Happy path and selected error path tests exist
- APIs are implemented to enable interop testing | - Review RFC
- Review existing tests | -| Development teams to Docs | - Working usage of API is provided
- Auto-generated documentation for public API is present | - Review examples
- Understands functionality
| -| Docs to Eco Dev | - Docs PR is merged with functioning code | - Understands functionality
- Execute guides | +| Handover | Expectations when handing over | Expectations when accepting handover | +|-------------------------------|----------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------| +| Research to development teams | - RFC PR is merged
- PoC PR is merged | - RFC content and PoC are reviewed
- Own code and functionality
- Own minor RFC changes | +| Development teams to QA | - Happy path and selected error path tests exist
- APIs are implemented to enable interop testing | - Review RFC
- Review existing tests | +| Development teams to Docs | - Working usage of API is provided
- Auto-generated documentation for public API is present | - Review examples
- Understands functionality
| +| Docs to Eco Dev | - Docs PR is merged with functioning code | - Understands functionality
- Execute guides | The group or person handing over is expected to initiate a sync (meeting) or async (chat or GitHub) discussion to go through the output and overview. From bdc4b3166578c447b603111d6d2326dd90627e56 Mon Sep 17 00:00:00 2001 From: "fryorcraken.eth" Date: Mon, 22 Jan 2024 11:37:29 +1100 Subject: [PATCH 9/9] Team prefers lower case across --- README.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index 1b72682..92fccb6 100644 --- a/README.md +++ b/README.md @@ -55,14 +55,14 @@ Typically, each *milestone* will be divided in the following *epics*: | 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: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: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: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:Docs` | Doc | Documentation (not auto-generated) | Document the new feature across all implementations, using the dogfooding output as handover material from engineering teams. | -| `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: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: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:docs` | Doc | Documentation (not auto-generated) | Document the new feature across all implementations, using the dogfooding output as handover material from engineering teams. | +| `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 flowchart LR