From aff21d4066e28b7dedb4ecefb41f834d905b010d Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Fri, 16 May 2025 13:36:14 +1000 Subject: [PATCH 01/14] Simplify process - Remove "deliverable" layer - "deliverable" now only refers to non-software work - Tracking work is directly related to FURPS --- PROCESS.md | 223 +++++++++++++++++++++++++---------------------------- 1 file changed, 107 insertions(+), 116 deletions(-) diff --git a/PROCESS.md b/PROCESS.md index 7886d76..8629468 100644 --- a/PROCESS.md +++ b/PROCESS.md @@ -2,132 +2,123 @@ ## Motivation and Goal -Implement the following attribute when delivering: +Provide a clear visibility to anyone (CCs or not) of: + - What work is planned + - What work is in progress + - What work is done + +Software properties are considered *delivered* when: + +- it is ready-to-use +- the behaviour is documented in [specifications](https://waku.org/specs) +- the software has been used (dogfooding) by the Waku team + +See [Waku Methodology](https://www.notion.so/Waku-Mission-and-Methodology-1a58f96fb65c80b9b789c1bbb9e99915) (draft) for more. + +## Team Structure + +The Waku team is current organized in the following subteams: + +- Core Research +- nwaku +- js-waku +- Chat/App Dev +- Chat/App Research +- Business Dev -1. Clear tracking of work across the teams so that when we says that a milestone is delivered, then: - - 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, Tasks) can easily be closed and marked as complete thanks to: - - Minimal external dependencies - - Minimal intra-team dependency - - Finite, well-define scope. -3. Each milestone and the effort needed to achieve it has a clear value thanks to a well-defined, value-driven, and minimal scope. ## Terminology and Scope -| Name | Number of | Timeframe | Team Scope | Owner | Description | -|--------------|-----------------------|------------------------------------------------|-------------------------------------------------|------------------------|-------------------------------------------------------| -| 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. | -| 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 - -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 cases, 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 bundled 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). - -## Workflow - -A *Milestone* is divided into *Deliverables*. A *Deliverable* is divided into *Tasks* that are assigned to a given subteam. - -### Accountability - -For development teams, it is expected that design/break down is done by the *Deliverable* and/or *Task* owner. -But actual work can be picked up by other team members. -Task owner must: - -- Understand the change and its implications, -- Liaise with researcher for any doubt or questions or design issues related to specific client/use case, -- Create issues (_Tasks_) to break down work in client repo, include an _acceptance criteria_ in each issue to ensure that the objective/end goal/behaviour is clearly described. - -It is likely that the task owner will do the core change or first change for a given task. -However, subsequent/other changes may be picked up in parallel or sequentially by other team members. - -Hence: -- dependencies must be clearly stated in _Task_ issue description -- Team members must assign _Task_ issues to themselves when work starts -- Team members must update issues to track progress - -The program manager should ensure that Deliverables are getting the right assignee in a timely fashion. -For example, when research work starts for a given milestone, Deliverable 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, and is encouraged to use client PM call as a forum to check deliverables to be assigned, for example when a given deliverable 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 | - -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 deliverable can be closed. - -### GitHub Usage - -A _Milestone_: -- MUST have a GitHub Milestone in https://github.com/waku-org/pm repo, to which relevant _Deliverables_ are added. -- The GitHub milestone MUST be used to track progress. - -A _Deliverable_: -- MUST be defined as an issue in the https://github.com/waku-org/pm repo. -- MUST be included in its parent _Milestone_. -- 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 - -A _Task_: -- MUST be tracked as a todo item in a GitHub Issue (_Deliverable_) -- 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 _Deliverable_: -- MUST qualify as - - `Bugs` - bugs reported by users or discovered internally. - - `Tests` - maintaining and fixing broken tests, if a test must be fixed as a result from a change from a *Deliverable* the work should be tracked and group with that *Deliverable*. - - `Releases` - work related to releasing version upgrades. - -Which means, in terms of _navigation_: -- Work for a Milestone is described in the [Roadmap](https://roadmap.logos.co/waku/waku-milestones) and tracked in the GitHub milestone in the pm repo. -- In the GitHub milestone, we have a list of _Deliverables_ to be achieved, the _Deliverables_ are being closed as the work is done and handed over. - -### Responsibilities - -| Task | Responsible | Accountable | -| ----------------------------------------------------------- | --------------- | --------------- | -| Set Milestones and Deliverables in master document | Waku Lead | Insights | -| Create GitHub milestones and deliverables issues in pm repo | Team Leads | Waku Lead | -| Create issues, PR (tasks) and link them to **deliverables** | Team Member | Team Lead | -| Close deliverable | Waku Lead | Program Manager | -| Handover to Vac-QA, Vac-DST | Team Lead | Vac PoC | -| Proceed with Dogfooding | Team Lead | Waku Lead | - -Responsible: who does the work -Accountable: delegates and reviews - -Waku Lead: @fryorcraken -Program Manager: @chair28980 -Team Lead: @plopezlpz @Ivansete-status @jm-clius @weboko -VAC PoC: @jm-clius - ## 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: +[FURPS](https://en.wikipedia.org/wiki/FURPS) are used to define software behaviour and property. +They are defined as: - F: Functionality - U: Usability - R: Reliability - P: Performance - S: Supportability +Moreover: + +- A *set of FURPS* define the behaviour of a specific protocol implementation or feature. +- Individual FURPS (e.g a specific `F`unctionality statement) should be owned by one and only one Waku subteam. +- "a FURPS" refers to an individual FURPS statement (e.g. "S1. available in libwaku"). - For every `P` (Performance) there must be a Grafana panel (pointed to fleet), and a **Vac-DST** simulation to *sign-off* the `P` (search for “**Vac-DST**”). -- For every `R` (Reliablity) there should be a test suite by Vac-QA that sign-off the `R` in unreliable network environment (search for “**Vac-QA**”); and potentially a Grafana panel (pointed to fleet), and a Vac-DST simulation (if relevant). -- Deliverables deliver a number of FURPS: `deliverable name: FURPS they deliver` -- Deliverables are owned by one or several teams, specified in parenthesis after deliverable \ No newline at end of file +- For every `R` (Reliability) there should be a test suite by Vac-QA that sign-off the `R` in unreliable network environment (search for “**Vac-QA**”); and potentially a Grafana panel (pointed to fleet), and a Vac-DST simulation (if relevant). + +## Feature + +A feature is a specific domain of Waku software behaviour. +It can be a protocol, or a set of closely-related protocols. +It has one related set of FURPS. + +For example, "End-to-end reliability" is a feature that refers to the SDS protocol. + +## Milestone + +A *Milestone* define a completion date and effort estimate for a collection of FURPS within or across given features. +Milestones are set for the whole Waku team and may involve the effort of one or several Waku subteams. +Dependencies on other groups to achieve a milestone should be minimalized. + +## Deliverable + +When the **work** is not related to software behaviour (e.g. a contributor guide, some BD activities), +then a *deliverable* is used to define the expected output. + +Deliverables are an alternative to FURPS statements. + +## Task + +A *task* is a piece of work necessary to deliver a FURPS statement. +A task may be defined as a checkbox, or a GitHub issue. +It is up to a subteam to decide how they organize their tasks (e.g. whether to use epics, issues per task, etc). + +### Rules + +Here are some rules to ensure the efficacy of our process. +What is not explicitly defined is left to the subteam's choice. + +A _Milestone_: +- MUST have a GitHub Milestone in https://github.com/waku-org/pm repo, to which relevant _FURPS_ statements or _Deliverables_ are added. +- MUST have an *estimated date of completion* +- MUST have an effort estimate, stating how many CCs are needed to work on this for a given half-year (e.g. one research, half an engineer) + +A _Feature_: +- MUST have corresponding label defined in https://github.com/waku-org/pm repo with format `F: ` + +A _FURPS_ (or FURPS statement): +- MUST HAVE a GitHub issue in https://github.com/waku-org/pm repo + - which MUST be included in its parent _Milestone_. + - which MUST have a feature label +- MUST have an easy way to find the related Pull Requests + +A _Deliverable_: +- MUST be defined as an issue in the https://github.com/waku-org/pm repo. +- MUST be included in its parent _Milestone_. +- MUST have an _Output_ section in the description detailing the result of work of the Deliverable. + +Finally, for _Tasks_ that do not belong to a _FURPS_ or _Deliverable_: +- MUST either qualify as (with related GitHub labels) + - `bug` - bugs reported by users or discovered internally, SHOULD be linked back to a corresponding _FURPS_ and _Milestone_ + - `test` - maintaining and fixing broken tests, SHOULD ideally be linked back to a corresponding _FURPS_ and _Milestone_ + - `release` - work related to releasing version upgrades. + - `dependencies` - work related to releasing version upgrades. + + +### Responsibilities + +| Task | Does it | Ensure it's done | +|-----------------------------------------------------------|-----------------|------------------| +| Set Milestones, FURPS and Deliverables in master document | Waku Lead | Insights | +| Create GitHub milestones in pm repo | Program Manager | Waku Lead | +| Create FURPS and Deliverables issues in pm repo | Team Leads | Program Manager | +| Create issues, PR (tasks) and link them to **FURPS** | Team Member | Team Lead | +| Close FURPS and Deliverables | Waku Lead | Program Manager | +| Handover to Vac-QA, Vac-DST | Team Lead | Vac PoCs | +| Proceed with Dogfooding | Team Lead | Waku Lead | + +Waku Lead: @fryorcraken +Program Manager: @chair28980 +Team Lead: @plopezlpz @Ivansete-status @jm-clius @weboko @jazzz +VAC PoC: @jm-clius, @stubbsta for Vac-DST From 712bd21dd79f97bf14b2efb355a53a84278f3da3 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Fri, 16 May 2025 13:41:48 +1000 Subject: [PATCH 02/14] Fix hierarchy, add ref to docs --- PROCESS.md | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/PROCESS.md b/PROCESS.md index 8629468..bbeb601 100644 --- a/PROCESS.md +++ b/PROCESS.md @@ -17,7 +17,7 @@ See [Waku Methodology](https://www.notion.so/Waku-Mission-and-Methodology-1a58f9 ## Team Structure -The Waku team is current organized in the following subteams: +The Waku team is currently organized in the following subteams: - Core Research - nwaku @@ -26,10 +26,14 @@ The Waku team is current organized in the following subteams: - Chat/App Research - Business Dev +## Documents + +- [Waku FURPS](https://www.notion.so/Waku-FURPS-1498f96fb65c803faedef2a591c22c00) +- [Waku Milestones](https://roadmap.logos.co/waku/waku-milestones) ## Terminology and Scope -## FURPS +### FURPS [FURPS](https://en.wikipedia.org/wiki/FURPS) are used to define software behaviour and property. They are defined as: @@ -47,7 +51,7 @@ Moreover: - For every `P` (Performance) there must be a Grafana panel (pointed to fleet), and a **Vac-DST** simulation to *sign-off* the `P` (search for “**Vac-DST**”). - For every `R` (Reliability) there should be a test suite by Vac-QA that sign-off the `R` in unreliable network environment (search for “**Vac-QA**”); and potentially a Grafana panel (pointed to fleet), and a Vac-DST simulation (if relevant). -## Feature +### Feature A feature is a specific domain of Waku software behaviour. It can be a protocol, or a set of closely-related protocols. @@ -55,26 +59,26 @@ It has one related set of FURPS. For example, "End-to-end reliability" is a feature that refers to the SDS protocol. -## Milestone +### Milestone A *Milestone* define a completion date and effort estimate for a collection of FURPS within or across given features. Milestones are set for the whole Waku team and may involve the effort of one or several Waku subteams. Dependencies on other groups to achieve a milestone should be minimalized. -## Deliverable +### Deliverable When the **work** is not related to software behaviour (e.g. a contributor guide, some BD activities), then a *deliverable* is used to define the expected output. Deliverables are an alternative to FURPS statements. -## Task +### Task A *task* is a piece of work necessary to deliver a FURPS statement. A task may be defined as a checkbox, or a GitHub issue. It is up to a subteam to decide how they organize their tasks (e.g. whether to use epics, issues per task, etc). -### Rules +## Rules Here are some rules to ensure the efficacy of our process. What is not explicitly defined is left to the subteam's choice. @@ -105,7 +109,6 @@ Finally, for _Tasks_ that do not belong to a _FURPS_ or _Deliverable_: - `release` - work related to releasing version upgrades. - `dependencies` - work related to releasing version upgrades. - ### Responsibilities | Task | Does it | Ensure it's done | @@ -121,4 +124,4 @@ Finally, for _Tasks_ that do not belong to a _FURPS_ or _Deliverable_: Waku Lead: @fryorcraken Program Manager: @chair28980 Team Lead: @plopezlpz @Ivansete-status @jm-clius @weboko @jazzz -VAC PoC: @jm-clius, @stubbsta for Vac-DST +VAC PoC: @jm-clius, @stubbsta for Vac-DST \ No newline at end of file From bf010960aada09a2da7a32175b840e87bac9654e Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Sun, 18 May 2025 21:59:49 +1000 Subject: [PATCH 03/14] Can't get rid of deliverables --- PROCESS.md | 54 ++++++++++++++++++++++++++++++------------------------ 1 file changed, 30 insertions(+), 24 deletions(-) diff --git a/PROCESS.md b/PROCESS.md index bbeb601..1286239 100644 --- a/PROCESS.md +++ b/PROCESS.md @@ -46,7 +46,6 @@ They are defined as: Moreover: - A *set of FURPS* define the behaviour of a specific protocol implementation or feature. -- Individual FURPS (e.g a specific `F`unctionality statement) should be owned by one and only one Waku subteam. - "a FURPS" refers to an individual FURPS statement (e.g. "S1. available in libwaku"). - For every `P` (Performance) there must be a Grafana panel (pointed to fleet), and a **Vac-DST** simulation to *sign-off* the `P` (search for “**Vac-DST**”). - For every `R` (Reliability) there should be a test suite by Vac-QA that sign-off the `R` in unreliable network environment (search for “**Vac-QA**”); and potentially a Grafana panel (pointed to fleet), and a Vac-DST simulation (if relevant). @@ -59,22 +58,37 @@ It has one related set of FURPS. For example, "End-to-end reliability" is a feature that refers to the SDS protocol. -### Milestone - -A *Milestone* define a completion date and effort estimate for a collection of FURPS within or across given features. -Milestones are set for the whole Waku team and may involve the effort of one or several Waku subteams. -Dependencies on other groups to achieve a milestone should be minimalized. - ### Deliverable -When the **work** is not related to software behaviour (e.g. a contributor guide, some BD activities), -then a *deliverable* is used to define the expected output. +A deliverable is the work tackled by one subteam in regards to one FURPS set. +In other words, it tracks the delivery of specific FURP(S), for one feature, by one subteam. -Deliverables are an alternative to FURPS statements. +For example: + +> Light Push FURPS +> - F1. Light push returns itemized error code when the service node cannot forward a message. +> - S1. nwaku service node +> - S2. Browser edge node + +To track the work to achieve these FURPS, two deliverables should be created: + +1. [nwaku] Support error code in light push: Implement Light Push FURPS F1, S1. +2. [js-waku] Support error code in light push: Implement Light Push FURPS F1, S2. + +When the **work** is not related to software behaviour (e.g. a contributor guide, some BD activities), +then a deliverable is used to define the expected output, without referring to specific FURPS. + +Deliverables are owned by one, and only one, subteam. +If a deliverable's execution depends on a group external to Waku, then it should be explicitly stated. + +### Milestone + +A *Milestone* define a completion date and effort estimate for a collection of deliverables, +across one or several subteams. ### Task -A *task* is a piece of work necessary to deliver a FURPS statement. +A *task* is a piece of work necessary to a deliverable. A task may be defined as a checkbox, or a GitHub issue. It is up to a subteam to decide how they organize their tasks (e.g. whether to use epics, issues per task, etc). @@ -88,21 +102,13 @@ A _Milestone_: - MUST have an *estimated date of completion* - MUST have an effort estimate, stating how many CCs are needed to work on this for a given half-year (e.g. one research, half an engineer) -A _Feature_: -- MUST have corresponding label defined in https://github.com/waku-org/pm repo with format `F: ` - -A _FURPS_ (or FURPS statement): -- MUST HAVE a GitHub issue in https://github.com/waku-org/pm repo - - which MUST be included in its parent _Milestone_. - - which MUST have a feature label -- MUST have an easy way to find the related Pull Requests - A _Deliverable_: - MUST be defined as an issue in the https://github.com/waku-org/pm repo. - MUST be included in its parent _Milestone_. -- MUST have an _Output_ section in the description detailing the result of work of the Deliverable. +- MUST have an _Output_ section in the description detailing the result of work of the Deliverable, this may be a list of FURPS. +- MUST have only one owner, assigned to the GitHub issue. -Finally, for _Tasks_ that do not belong to a _FURPS_ or _Deliverable_: +Finally, for _Tasks_ that do not belong to a _Deliverable_: - MUST either qualify as (with related GitHub labels) - `bug` - bugs reported by users or discovered internally, SHOULD be linked back to a corresponding _FURPS_ and _Milestone_ - `test` - maintaining and fixing broken tests, SHOULD ideally be linked back to a corresponding _FURPS_ and _Milestone_ @@ -115,9 +121,9 @@ Finally, for _Tasks_ that do not belong to a _FURPS_ or _Deliverable_: |-----------------------------------------------------------|-----------------|------------------| | Set Milestones, FURPS and Deliverables in master document | Waku Lead | Insights | | Create GitHub milestones in pm repo | Program Manager | Waku Lead | -| Create FURPS and Deliverables issues in pm repo | Team Leads | Program Manager | +| Create Deliverables issues in pm repo | Team Leads | Program Manager | | Create issues, PR (tasks) and link them to **FURPS** | Team Member | Team Lead | -| Close FURPS and Deliverables | Waku Lead | Program Manager | +| Close Deliverables | Waku Lead | Program Manager | | Handover to Vac-QA, Vac-DST | Team Lead | Vac PoCs | | Proceed with Dogfooding | Team Lead | Waku Lead | From aa4f2fc80904e8aff8b8bd487366f5c5787ed406 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Mon, 19 May 2025 09:28:53 +1000 Subject: [PATCH 04/14] Can't get rid of deliverables --- PROCESS.md | 1 + 1 file changed, 1 insertion(+) diff --git a/PROCESS.md b/PROCESS.md index 1286239..1ebc79e 100644 --- a/PROCESS.md +++ b/PROCESS.md @@ -106,6 +106,7 @@ A _Deliverable_: - MUST be defined as an issue in the https://github.com/waku-org/pm repo. - MUST be included in its parent _Milestone_. - MUST have an _Output_ section in the description detailing the result of work of the Deliverable, this may be a list of FURPS. +- If tracking FURPS, the FURPS only belong to one feature aka FURPS set. - MUST have only one owner, assigned to the GitHub issue. Finally, for _Tasks_ that do not belong to a _Deliverable_: From 2aac889dbcf4dce61e299cdd7cb403ff95574011 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Mon, 19 May 2025 21:33:39 +1000 Subject: [PATCH 05/14] Update milestone definition --- PROCESS.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/PROCESS.md b/PROCESS.md index 1ebc79e..2510334 100644 --- a/PROCESS.md +++ b/PROCESS.md @@ -83,8 +83,13 @@ If a deliverable's execution depends on a group external to Waku, then it should ### Milestone -A *Milestone* define a completion date and effort estimate for a collection of deliverables, -across one or several subteams. +A milestone describes a specific objective we aim to achieve. +It holds the narrative of **why** we are doing this work and what is the value attached to completing the work. + +A milestone usually involve effort from most of the Waku team. +The work should be organized to prioritise the delivery of complete milestones, over individual deliverables. + +Milestone have estimation of effort and date of completion defined. ### Task From 3edc779a48ec179c71942ac5756e20acd9b7db7d Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 21 May 2025 13:14:16 +1000 Subject: [PATCH 06/14] measurement statement --- PROCESS.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/PROCESS.md b/PROCESS.md index 2510334..e67e06b 100644 --- a/PROCESS.md +++ b/PROCESS.md @@ -47,7 +47,8 @@ Moreover: - A *set of FURPS* define the behaviour of a specific protocol implementation or feature. - "a FURPS" refers to an individual FURPS statement (e.g. "S1. available in libwaku"). -- For every `P` (Performance) there must be a Grafana panel (pointed to fleet), and a **Vac-DST** simulation to *sign-off* the `P` (search for “**Vac-DST**”). +- For every `P` (Performance) there should be a Grafana panel (pointed to fleet), and a **Vac-DST** simulation to *sign-off* the `P` (search for “**Vac-DST**”). + If it cannot be measured, then it cannot be a statement (in some instances, DST simulation may be enough). - For every `R` (Reliability) there should be a test suite by Vac-QA that sign-off the `R` in unreliable network environment (search for “**Vac-QA**”); and potentially a Grafana panel (pointed to fleet), and a Vac-DST simulation (if relevant). ### Feature From 0b99ba89aea4efee296f438c1dc79b32c32da78d Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 21 May 2025 14:46:58 +1000 Subject: [PATCH 07/14] Add documentation as a criteria --- PROCESS.md | 1 + 1 file changed, 1 insertion(+) diff --git a/PROCESS.md b/PROCESS.md index e67e06b..6085e96 100644 --- a/PROCESS.md +++ b/PROCESS.md @@ -12,6 +12,7 @@ Software properties are considered *delivered* when: - it is ready-to-use - the behaviour is documented in [specifications](https://waku.org/specs) - the software has been used (dogfooding) by the Waku team +- documentation on how to use said properties is delivered See [Waku Methodology](https://www.notion.so/Waku-Mission-and-Methodology-1a58f96fb65c80b9b789c1bbb9e99915) (draft) for more. From ec247d73b9d1cb968b0b74b3944acd82ff44b0e5 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 21 May 2025 14:48:44 +1000 Subject: [PATCH 08/14] add checklist --- PROCESS.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/PROCESS.md b/PROCESS.md index 6085e96..3981a59 100644 --- a/PROCESS.md +++ b/PROCESS.md @@ -115,6 +115,11 @@ A _Deliverable_: - MUST have an _Output_ section in the description detailing the result of work of the Deliverable, this may be a list of FURPS. - If tracking FURPS, the FURPS only belong to one feature aka FURPS set. - MUST have only one owner, assigned to the GitHub issue. +- MUST have a checklist to ensure the following items are done: + - specs + - code + - dogfooding + - docs Finally, for _Tasks_ that do not belong to a _Deliverable_: - MUST either qualify as (with related GitHub labels) From 6ecc75bc7926a43a2e776679472f25264e1c9a8d Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 22 May 2025 12:17:39 +1000 Subject: [PATCH 09/14] fix formatting --- PROCESS.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/PROCESS.md b/PROCESS.md index 3981a59..a7fcb84 100644 --- a/PROCESS.md +++ b/PROCESS.md @@ -140,7 +140,7 @@ Finally, for _Tasks_ that do not belong to a _Deliverable_: | Handover to Vac-QA, Vac-DST | Team Lead | Vac PoCs | | Proceed with Dogfooding | Team Lead | Waku Lead | -Waku Lead: @fryorcraken -Program Manager: @chair28980 -Team Lead: @plopezlpz @Ivansete-status @jm-clius @weboko @jazzz -VAC PoC: @jm-clius, @stubbsta for Vac-DST \ No newline at end of file +- Waku Lead: @fryorcraken +- Program Manager: @chair28980 +- Team Lead: @plopezlpz @Ivansete-status @jm-clius @weboko @jazzz +- VAC PoC: @jm-clius, @stubbsta for Vac-DST \ No newline at end of file From c341533ac382a7e4cd11e4f4fae04999d6694b79 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 22 May 2025 12:22:07 +1000 Subject: [PATCH 10/14] updated responsibilities --- PROCESS.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/PROCESS.md b/PROCESS.md index a7fcb84..0937a35 100644 --- a/PROCESS.md +++ b/PROCESS.md @@ -114,7 +114,7 @@ A _Deliverable_: - MUST be included in its parent _Milestone_. - MUST have an _Output_ section in the description detailing the result of work of the Deliverable, this may be a list of FURPS. - If tracking FURPS, the FURPS only belong to one feature aka FURPS set. -- MUST have only one owner, assigned to the GitHub issue. +- MUST have only one owner, assigned to the GitHub issue; usually a Waku subteam lead. - MUST have a checklist to ensure the following items are done: - specs - code @@ -130,15 +130,15 @@ Finally, for _Tasks_ that do not belong to a _Deliverable_: ### Responsibilities -| Task | Does it | Ensure it's done | -|-----------------------------------------------------------|-----------------|------------------| -| Set Milestones, FURPS and Deliverables in master document | Waku Lead | Insights | -| Create GitHub milestones in pm repo | Program Manager | Waku Lead | -| Create Deliverables issues in pm repo | Team Leads | Program Manager | -| Create issues, PR (tasks) and link them to **FURPS** | Team Member | Team Lead | -| Close Deliverables | Waku Lead | Program Manager | -| Handover to Vac-QA, Vac-DST | Team Lead | Vac PoCs | -| Proceed with Dogfooding | Team Lead | Waku Lead | +| Task | Does it | Ensure it's done | +|------------------------------------------------------|--------------------|-------------------| +| Set Milestones, FURPS and Deliverables | Waku Lead | Insights | +| Create GitHub milestones in pm repo | Program Manager | Waku Lead | +| Create Deliverable issues in pm repo | Deliverable Owner | Program Manager | +| Create issues, PR (tasks) and link them to **FURPS** | Team Member | Deliverable Owner | +| Close Deliverables | Waku Lead | Program Manager | +| Handover to Vac-QA, Vac-DST | Deliverable Owner | Vac PoCs | +| Proceed with Dogfooding | Deliverable Owner | Waku Lead | - Waku Lead: @fryorcraken - Program Manager: @chair28980 From 4ac5cbf28199afcea3e48939b4a95771fea2a619 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Fri, 23 May 2025 13:44:41 +1000 Subject: [PATCH 11/14] deliverable owner, release/deps --- PROCESS.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/PROCESS.md b/PROCESS.md index 0937a35..4b70d99 100644 --- a/PROCESS.md +++ b/PROCESS.md @@ -114,7 +114,7 @@ A _Deliverable_: - MUST be included in its parent _Milestone_. - MUST have an _Output_ section in the description detailing the result of work of the Deliverable, this may be a list of FURPS. - If tracking FURPS, the FURPS only belong to one feature aka FURPS set. -- MUST have only one owner, assigned to the GitHub issue; usually a Waku subteam lead. +- MUST have only one owner, assigned to the GitHub issue; a Waku subteam lead or team member. - MUST have a checklist to ensure the following items are done: - specs - code @@ -125,20 +125,20 @@ Finally, for _Tasks_ that do not belong to a _Deliverable_: - MUST either qualify as (with related GitHub labels) - `bug` - bugs reported by users or discovered internally, SHOULD be linked back to a corresponding _FURPS_ and _Milestone_ - `test` - maintaining and fixing broken tests, SHOULD ideally be linked back to a corresponding _FURPS_ and _Milestone_ - - `release` - work related to releasing version upgrades. - - `dependencies` - work related to releasing version upgrades. + - `release` - work associated with releasing new versions. + - `dependencies` - work associated with updating dependency versions. ### Responsibilities -| Task | Does it | Ensure it's done | -|------------------------------------------------------|--------------------|-------------------| -| Set Milestones, FURPS and Deliverables | Waku Lead | Insights | -| Create GitHub milestones in pm repo | Program Manager | Waku Lead | -| Create Deliverable issues in pm repo | Deliverable Owner | Program Manager | -| Create issues, PR (tasks) and link them to **FURPS** | Team Member | Deliverable Owner | -| Close Deliverables | Waku Lead | Program Manager | -| Handover to Vac-QA, Vac-DST | Deliverable Owner | Vac PoCs | -| Proceed with Dogfooding | Deliverable Owner | Waku Lead | +| Task | Does it | Ensure it's done | +|------------------------------------------------------------------|---------------------|-------------------| +| Set Milestones, FURPS and Deliverables | Waku Lead | Insights | +| Create GitHub milestones in pm repo | Program Manager | Waku Lead | +| Create Deliverable issues in pm repo | Deliverable Owner | Program Manager | +| Create issues, PR (tasks) and link them to the deliverable issue | Deliverable Owner | Deliverable Owner | +| Close Deliverables | Waku Lead | Program Manager | +| Handover to Vac-QA, Vac-DST | Deliverable Owner | Vac PoCs | +| Proceed with Dogfooding | Deliverable Owner | Waku Lead | - Waku Lead: @fryorcraken - Program Manager: @chair28980 From 763504ffdecdf28dbf04e94ebeb6800025b6ad94 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Fri, 23 May 2025 13:45:23 +1000 Subject: [PATCH 12/14] typo --- PROCESS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/PROCESS.md b/PROCESS.md index 4b70d99..e50f3e9 100644 --- a/PROCESS.md +++ b/PROCESS.md @@ -88,7 +88,7 @@ If a deliverable's execution depends on a group external to Waku, then it should A milestone describes a specific objective we aim to achieve. It holds the narrative of **why** we are doing this work and what is the value attached to completing the work. -A milestone usually involve effort from most of the Waku team. +A milestone usually involves effort from most of the Waku team. The work should be organized to prioritise the delivery of complete milestones, over individual deliverables. Milestone have estimation of effort and date of completion defined. From 7952bbe36a847498b6959688ed980ffada472bdb Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Tue, 27 May 2025 11:50:47 +1000 Subject: [PATCH 13/14] clarify ownership --- PROCESS.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/PROCESS.md b/PROCESS.md index e50f3e9..720b135 100644 --- a/PROCESS.md +++ b/PROCESS.md @@ -130,15 +130,15 @@ Finally, for _Tasks_ that do not belong to a _Deliverable_: ### Responsibilities -| Task | Does it | Ensure it's done | -|------------------------------------------------------------------|---------------------|-------------------| -| Set Milestones, FURPS and Deliverables | Waku Lead | Insights | -| Create GitHub milestones in pm repo | Program Manager | Waku Lead | -| Create Deliverable issues in pm repo | Deliverable Owner | Program Manager | -| Create issues, PR (tasks) and link them to the deliverable issue | Deliverable Owner | Deliverable Owner | -| Close Deliverables | Waku Lead | Program Manager | -| Handover to Vac-QA, Vac-DST | Deliverable Owner | Vac PoCs | -| Proceed with Dogfooding | Deliverable Owner | Waku Lead | +| Task | Does it | Ensure it's done | +|------------------------------------------------------------------|-----------------|------------------| +| Set Milestones, FURPS and Deliverables | Waku Lead | Insights | +| Create GitHub milestones in pm repo | Program Manager | Waku Lead | +| Create Deliverable issues in pm repo | Team Lead | Program Manager | +| Create issues, PR (tasks) and link them to the deliverable issue | Team Member | Team Lead | +| Handover to Vac-QA, Vac-DST | Team Member | Team Lead | +| Proceed with Dogfooding | Team Member | Team Lead | +| Close Deliverable | Waku Lead | Program Manager | - Waku Lead: @fryorcraken - Program Manager: @chair28980 From b37cab6535215ebc772e0ef269285fddd344390e Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Tue, 27 May 2025 11:51:44 +1000 Subject: [PATCH 14/14] fix sentence --- PROCESS.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/PROCESS.md b/PROCESS.md index 720b135..647dd13 100644 --- a/PROCESS.md +++ b/PROCESS.md @@ -122,11 +122,11 @@ A _Deliverable_: - docs Finally, for _Tasks_ that do not belong to a _Deliverable_: -- MUST either qualify as (with related GitHub labels) - - `bug` - bugs reported by users or discovered internally, SHOULD be linked back to a corresponding _FURPS_ and _Milestone_ - - `test` - maintaining and fixing broken tests, SHOULD ideally be linked back to a corresponding _FURPS_ and _Milestone_ - - `release` - work associated with releasing new versions. - - `dependencies` - work associated with updating dependency versions. +- MUST qualify either as (with related GitHub labels) + - `bug`: bugs reported by users or discovered internally, SHOULD be linked back to a corresponding _FURPS_ and _Milestone_ + - `test`: maintaining and fixing broken tests, SHOULD ideally be linked back to a corresponding _FURPS_ and _Milestone_ + - `release`: work associated with releasing new versions. + - `dependencies`: work associated with updating dependency versions. ### Responsibilities