update reporting guidelines

PROCESS.md

@@ -8,7 +8,7 @@ Implement the following attribute when delivering:
    - it is usable by all types of users (operators, web devs, system devs).
    - It is documented (docs, dev rel)
    - It is of high quality (QA, Dogfooding)
-2. Items (Milestones, Deliverables, Epics, Tasks) can easily be closed and marked as complete thanks to:
+2. Items (Milestones, Deliverables, Tasks) can easily be closed and marked as complete thanks to:
     - Minimal external dependencies
     - Minimal intra-team dependency
     - Finite, well-define scope.
@@ -20,8 +20,7 @@ Implement the following attribute when delivering:
 |--------------|-----------------------|------------------------------------------------|-------------------------------------------------|------------------------|-------------------------------------------------------|
 | Milestone    | ?                     | Pencilled for the year, planned for 2 quarters | Most subteams                                   | Waku Lead              | A, or cohesive set of, feature(s).                    |
 | Deliverable         | Several per milestone | Set for a milestone                            | Subteam leads | Waku Lead | Deliverable may be the result of the work of one, some or all Waku subteams.                   |
-| Epic         | Several per deliverable | Set for a deliverable                            | Usually one subteam or external team (e.g. DST) | Subteam Lead or Member | Milestone work for a given subteam.                   |
-| Task         | Several per Epic         | Set monthly-ish, delivered weekly              | One subteam or individual                       | Team Member            | May be one or several piece of work, client specific. |
+| Task         | Several per Deliverable         | Set monthly-ish, delivered weekly***              | One subteam or individual                       | Team Member            | May be one or several pieces of work, client specific. |
 
 ## Milestone Definition
 
@@ -34,55 +33,34 @@ A *Milestone*:
 
 ## Milestone scoping process flow
 
-Phase 1: Waku lead defines the scope within the Milestone. The scope is then discussed asynchronously in the comments of the GitHub issue by relevant subteams and stakeholders, scope of Epics and subtasks are defined.
+Phase 1: Waku lead defines the scope within the Milestone. The scope is then discussed asynchronously in the comments of the GitHub issue by relevant subteams and stakeholders, scope of tasks are defined.
 
 Phase 2: During a Waku PM call, the team reviews the Milestone to confirm scope or identify areas that require additional scoping.
 
 Phase 3: If the scope is agreed upon, the team can proceed to create Epics and schedule work for kickoff.
 
 ## Workflow
 
-A *Milestone* is divided into *Deliverables*. A *Deliverable* is divided into *Epics*. Each *Epic* is assigned to a given subteam.
+A *Milestone* is divided into *Deliverables*. A *Deliverable* is divided into work that is assigned to a given subteam.
 
-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 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: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:bindings`      | nwaku                    | MVP quality software for supported bindings (WIP)                                  | Expose new protocol/features on binding APIs.                                                                                                                                                                                                | -->                                       | -->
-<!-- | `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: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.                                                                                 | -->
+Typically, each *milestone* will be divided in the following *deliverables*:
 
 ### 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.
 
-### Chat SDK and other Special SDK Work
+### Chat 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.
+The Chat 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:
+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:chat sdk` | Chat SDK       | PoC and then MVP quality software, Application RFC | Implement the ACZ RFC, define API and application protocol |
+Handover to VAC QA and VAC DST 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.
+### Deliverables
 
 ### 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).
-
-The epic owner is responsible for breaking down the work in smaller issues in the related repo.
-
 For research team, it is expected that most of the research work is done by the epic owner, which includes:
 - Capturing problem statement
 - Designing protocol/solution
@@ -135,19 +113,12 @@ A _Deliverable_:
 - MUST have an _Output_ section in the description detailing the result of work of the Deliverable.
 - MUST have a `Planned Start` and `Due Date` set
 
-An _Epic_:
-- MUST have a matching GitHub issue in the relevant team's repo.
-- MUST have a label with format `Epic`.
-- MUST be added to the description of the parent _Deliverable_ issue.
-- MUST 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 assignee(s), who represent the epic owner (see [accountability](#accountability))
-
 A _Task_:
 - MUST be tracked as a todo item in a GitHub Issue (_Deliverable_ or _Epic_)
 - 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 _Deliverable_:
+<!-- replace with Maintenance -->
+Finally, for _Tasks_ that do not belong to a _Deliverable_:
 - MUST qualify as, and have one of the following labels:
   - `bug`: This is a bug, likely reported by a user
   - `maintenance`: This is maintenance work that is out of the scope of the technical roadmap
@@ -161,10 +132,8 @@ Which means, in terms of _navigation_:
 | Task                                                        | Responsible     | Accountable     |
 | ----------------------------------------------------------- | --------------- | --------------- |
 | Set Milestones and Deliverables in master document          | Waku Lead       | Insights       |
-| Create GitHub milestones and deliverables issues in pm repo | Program Manager | Waku Lead       |
-| Create epic for team                                        | Team Lead       | Program Manager |
+| Create GitHub milestones and deliverables issues in pm repo | Team Leads | Waku Lead       |
 | Create issues, PR (tasks) and link them to **epics**             | Team Member     | Team Lead       |
-| Close epic                                                  | Team Lead       | Program Manager |
 | Close deliverable                                           | Waku Lead       | Program Manager |
 | Handover to Vac-QA, Vac-DST                                 | Team Lead       | Vac PoC (?)     |
 | Proceed with Dogfooding                                     | Team Lead       | Waku Lead       |
@@ -177,8 +146,15 @@ Program Manager: @chair28980
 Team Lead: @plopezlpz @Ivansete-status @jm-clius @weboko
 VAC PoC: @jm-clius
 
-### TLDR
+## FURPS
+
+Fore each *milestone*, FURPS headlines are defined by the Waku Lead.
+
+[FURPS](https://www.marcinziemek.com/blog/content/articles/8/article_en.html) are defined as:
+- F: Functionality
+- U: Usability
+- R: Reliability
+- P: Performance
+- S: Supportability
 
-- Milestones and Deliverables are defined in the pm repo
-- Deliverables have many epics, one epic per subteam
-- Team lead is responsible to ensure Vac-QA is aware of changes, but no need to create a QA epic
+For each (R) and (P) headline, a grafana dashboard should be produced as output for the given *milestone*.

README.md

@@ -8,56 +8,64 @@ The Waku Team is comprised of the following subteams:
 - Waku Development nwaku, js-waku, go-waku
 - Waku Chat
 
-The Waku Team also gets the support from other Logos groups, in particular:
+The Waku Team is also supported by other Logos groups, in particular:
 
 - [VAC/DST](https://vac.dev/): Distributed System Testing Team for simulations and QA/Testing
 - Comms Hub: For communications, marketing, digital content, etc.
 
-## Work Tracking and Project Management Process
-
-See [PROCESS.md](./PROCESS.md)
+*For tracking and project management processes please see* [PROCESS.md](./PROCESS.md)
 
 ## Reporting Guidelines
 
-### Requirements
+### Weekly Reporting
 
-#### Weekly Reporting
+Weekly reporting provides an insight on the progress by Milestones. Updates are published to https://roadmap.logos.co/tags/waku-updates.
 
-Weekly reporting provides an insight on the progress by milestones.
+- Updates are collected and submitted by the team leads.
+- Add to the relevant pull request in the roadmap repository: https://github.com/logos-co/roadmap/pulls
+- Provide updates for each Deliverable currently in-progress.
+- Use the achieved, next, blockers format templated under each Deliverable.
+- Indicate if there is a scope change or due date change.
+- Use the [Maintenance Deliverable](https://github.com/waku-org/pm/issues/275) for Maintenance, Tests, and Bugs that do not have a parent Milestone or Deliverable.
+- Indicate which team the update is for, e.g.:
+```md
+    - achieved:
+        - [nwaku] Added testing for…
+        - [chat] Update libraries in…
+```
 
-### Reporting
+## Milestones
 
-**Weekly Updates**:
+Milestones are defined in the Waku roadmap and tracked as Github in this repo.
+Roadmap: https://roadmap.logos.co/waku/waku-milestones
+Github: https://github.com/waku-org/pm/milestones
 
-Report progress on each **active** Deliverables per sub-team.
+<img src="img/milestone.png" width="500" height="375">
 
-Every week, all team members must add their update in the appropriate discord thread *WITH LINKS* to the GitHub **issues** (not pull requests) they own and worked on over the past week and/or plan to work on next week.
+## Deliverables
 
-If work is done on several *Tasks* related to the same *Epic*, team members are free to link the common parent *Epic* issue.
+### Creation
 
-Please include an update for the following categories:
+If a Deliverable has not yet been created, the Lead for the sub-team scheduled to kick-off the work. All Deliverables should be created in the Waku PM repo: https://github.com/waku-org/pm
 
-- achieved: what was achieved this week.
-- next: what will be worked on next.
-- blocked: blocking items, not required if no blockers exist.
+You can use the Deliverable template: https://github.com/waku-org/pm/issues/new?template=deliverable.md
 
-PM compiles the updates following sign-off from sub-team Leads and publishes to https://roadmap.logos.co.
+Upon creation of a Deliverable in Github please notify the PM.
 
-### Process Flow
+### Assignees
 
-```md
-Submit Updates (Everyone) - Tuesday
-         │
-         ▼
-Review/Signoff (Leads) - Wednesday
-         │
-         ▼
-Compile (PM) - Thursday
-         │
-         ▼
-Publish (PM) - Monday
-```
+For each team involved in work for the Deliverable, the Lead for that team should be an assignee on the Deliverable.
 
-## Milestones
+### Adding sub-issues
+
+Create or add sub issues to the deliverable by using Github’s new “sub-issue” feature:
+
+![sub-issues-image](img/sub-issues.png)
+
+## Maintenance Deliverable
+
+This Maintenance Deliverable tracks all work not specifically described in the Waku roadmap covering Maintenance, Bugs, and Tests.
+
+[2025 H1 Maintenance Deliverable](https://github.com/waku-org/pm/issues/275)
 
-https://github.com/waku-org/pm/milestones
+<img src="img/maintenance.png" width="500" height="375">