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

Fix hierarchy, add ref to docs

Browse Source
This commit is contained in:
fryorcraken 2025-05-16 13:41:48 +10:00
parent aff21d4066
commit 712bd21dd7
No known key found for this signature in database
GPG Key ID: A82ED75A8DFC50A4
1 changed files with 12 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
PROCESS.md
View File

@ -17,7 +17,7 @@ See [Waku Methodology](https://www.notion.so/Waku-Mission-and-Methodology-1a58f9
## Team Structure ## Team Structure
The Waku team is current organized in the following subteams: The Waku team is currently organized in the following subteams:
- Core Research - Core Research
- nwaku - nwaku
@ -26,10 +26,14 @@ The Waku team is current organized in the following subteams:
- Chat/App Research - Chat/App Research
- Business Dev - Business Dev
## Documents
- [Waku FURPS](https://www.notion.so/Waku-FURPS-1498f96fb65c803faedef2a591c22c00)
- [Waku Milestones](https://roadmap.logos.co/waku/waku-milestones)
## Terminology and Scope ## Terminology and Scope
## FURPS ### FURPS
[FURPS](https://en.wikipedia.org/wiki/FURPS) are used to define software behaviour and property. [FURPS](https://en.wikipedia.org/wiki/FURPS) are used to define software behaviour and property.
They are defined as: 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 `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). - 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. A feature is a specific domain of Waku software behaviour.
It can be a protocol, or a set of closely-related protocols. 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. 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. 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. 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. 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), 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. then a *deliverable* is used to define the expected output.
Deliverables are an alternative to FURPS statements. Deliverables are an alternative to FURPS statements.
## Task ### Task
A *task* is a piece of work necessary to deliver a FURPS statement. 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. 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). 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. Here are some rules to ensure the efficacy of our process.
What is not explicitly defined is left to the subteam's choice. 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. - `release` - work related to releasing version upgrades.
- `dependencies` - work related to releasing version upgrades. - `dependencies` - work related to releasing version upgrades.
### Responsibilities ### Responsibilities
| Task | Does it | Ensure it's done | | 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 Waku Lead: @fryorcraken
Program Manager: @chair28980 Program Manager: @chair28980
Team Lead: @plopezlpz @Ivansete-status @jm-clius @weboko @jazzz 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