diff --git a/PROCESS.md b/PROCESS.md index ad99111..f10fe16 100644 --- a/PROCESS.md +++ b/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,7 +33,7 @@ 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. @@ -42,47 +41,26 @@ Phase 3: If the scope is agreed upon, the team can proceed to create Epics and s ## 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. | - | --> - - - +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_: + +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 | @@ -176,9 +145,3 @@ Waku Lead: @fryorcraken Program Manager: @chair28980 Team Lead: @plopezlpz @Ivansete-status @jm-clius @weboko VAC PoC: @jm-clius - -### TLDR - -- 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