mirror of
https://github.com/logos-messaging/pm.git
synced 2026-01-02 14:13:09 +00:00
146 lines
6.7 KiB
Markdown
146 lines
6.7 KiB
Markdown
# Work Tracking and Project Management Process
|
|
|
|
## Motivation and Goal
|
|
|
|
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
|
|
- documentation on how to use said properties is delivered
|
|
|
|
See [Waku Methodology](https://www.notion.so/Waku-Mission-and-Methodology-1a58f96fb65c80b9b789c1bbb9e99915) (draft) for more.
|
|
|
|
## Team Structure
|
|
|
|
The Waku team is currently organized in the following subteams:
|
|
|
|
- Nim: Looking after [logos-messaging-nim](https://github.com/logos-messaging/logos-messaging-nim/), [nim-sds](https://github.com/logos-messaging/nim-sds), and other components below the Reliable Channel API.
|
|
- Chat: Looking after the [Chat SDK](https://github.com/logos-messaging/nim-chat-poc).
|
|
- Messaging Logos Core: ensuring messaging libraries are available as Logos Core modules.
|
|
|
|
## Documents
|
|
|
|
- [Logos Messaging FURPS](https://roadmap.logos.co/messaging/furps)
|
|
- [Logos Messaging Milestones](https://roadmap.logos.co/messaging/milestones)
|
|
|
|
## Terminology and Scope
|
|
|
|
### FURPS
|
|
|
|
[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.
|
|
- "a FURPS" refers to an individual FURPS statement (e.g. "S1. available in libwaku").
|
|
- 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
|
|
|
|
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.
|
|
|
|
### Deliverable
|
|
|
|
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.
|
|
|
|
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. `[nim] Support error code in light push: Implement Light Push FURPS F1, S1.`
|
|
2. `[js] Support error code in light push: Implement Light Push FURPS F1, S2.`
|
|
|
|
Note: `[chat]` and `[nim]` are the current valid teams.
|
|
|
|
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 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 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.
|
|
|
|
### Task
|
|
|
|
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).
|
|
|
|
## 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/logos-messaging/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 _Deliverable_:
|
|
- MUST be defined as an issue in the https://github.com/logos-messaging/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; a Waku subteam lead or team member.
|
|
- SHOULD NOT have a dependency on another deliverable in the **same** milestone.
|
|
- MUST have a checklist to ensure the following items are done:
|
|
- specs
|
|
- code
|
|
- dogfooding
|
|
- docs
|
|
|
|
Finally, for _Tasks_ or _PRs_ that do not belong to a _Deliverable_:
|
|
- 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
|
|
|
|
| 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
|
|
- Team Lead: @Ivansete-status @jazzz
|
|
- DST/QA PoC: @stubbsta |