Update Milestone process

[fryorcraken]

No description provided.

[fryorcraken]

Dogfood is a separate epic to ensure it happens. It also encourage interoperability testing so that dogfooding happens across all clients.

We need to try and see if it works.

[chair28980]

Do we envision a new repo dedicated for the dogfood epics?

Edit: I see the detail now of a specific issue within a team's epic for dogfooding ✔️.

[fryorcraken]

I think all epic will have to continue to live in pm repo as per #107 (comment)

[fryorcraken]

I do not think we need a strict handover process. However, I believe it is worth mentioning.
It helps ensure the quality of the output.
It also means that once a team has handed over, then can close an epic.

Work may happen after a handover, especially in terms of maintenance and support but it is now out of the hand of the team that handed over.

[fryorcraken]

Regarding RFC, the aim is to ensure that researcher can focus on the next task.
It does not mean that they are totally out of the loop, but that dev engineers are taking ownership and can process with small RFC adjustment raised through implementation and interop.

In case of major issue with a protocol discovered at a late stage, then we can review on an adhoc basis on how to handle it.

[fryorcraken]

I believe one of the limitation we have is that a GitHub milestine is only on one repo and hence we need the related epics to be in the same repo.

I don't think there is a way to get the epic issue in the subteam repo.

[fryorcraken]

Having a roadmap in the milestone description that is not updated is not great so I removed this and expect to only use github fields for planning. Let's see how it goes.

[fryorcraken]

Nobody label their PR.
I don't think it impacts project management too much so that fine.

But I do expect a reference to the relate issue to appear in a PR so that context is provided.

[Ivansete-status]

IMO, a Task with sub-Tasks is an Epic. Then, I don't see the need for a Task to keep a list of other Tasks

[fryorcraken]

We are abusing the word "epic" to have a common terminology across dashboards.

[fryorcraken]

No matter how the multiple client discussion goes. I propose to ensure that Rust and C bindings are considered as support and included in any work

[fryorcraken]

Should we include this in the same epic than go-waku or have a dedicated one? I 'd suggest same epic @waku-org/go-waku-developers

[chaitanyaprem]

But I am wondering whether the priority would be same for C-bindings and rust similar to Golang API's for all milestongs. Maybe it is better to decide per milestone and based on SDK usage whether to deprioritize something?
Some milestones may not have changes in these bindings as well.

[fryorcraken]

I think there is a fair question of scope for each client. Which we are trying to clarify with the multiple client implement.
e.g. if js-waku is only for the browser then relay and service node side of req-res protocol do not need to be implemented.
go-waku scope is currently library for Status so strictly speaking it does not need RLN or autosharding either.

Once we set a scope for a client or binding then it will be clear whether a milestone should be done on such client.

For now, Rust is awkward. Created by Nomos for Nomos but used by TheGraph. TheGraph is valuable user but they do not see intending to use The Waku Network.

Also, our focus was on building The Waku Network, over having an array of language available (see how #42 is planned for later).

However, once we decide that Rust or any specific client should be fully supported, then I think it should be included in milestone work and not be considered a second class citizen.
If we push documentationf or the Rust bindings on docs.waku.org then we should aim for parity, and not wait for a project to tell us "hey this js-waku functionality, would be useful for us in Rust" before we decide to implement.

[jm-clius]

In general this LGTM. One clarification from my side - this seems to imply that the Epics-per-milestone is only used to distribute the responsibilities towards the same milestone to different subteams. In other words, we won't also use epics to break the milestone into smaller deliverables (that may also span several teams) as I've done in https://www.notion.so/Waku-Research-Milestones-2024-56b1d8c869f14acc934c2d2b2564fa2a ? For example, the Milestone delivery of Store Sync can be broken down into distinct phases: (1) improved Store protocol (2) basic sync protocol. Both of these phases would in turn require effort to be scheduled for each of the subteams. In my mind it make sense to use Epics to also indicate this further breakdown of the milestone.

[chair28980]

@jm-clius I agree with your point that Epics should breakdown into appropriately sized batches of work. Using the Milestone you referenced as a rough template of what the work might break down to coming out of the Research phase would be a similar breakdown into Epics as described in the Research doc https://www.notion.so/Waku-Research-Milestones-2024-56b1d8c869f14acc934c2d2b2564fa2a.

-  Milestone: Store Upgrade (SU)
- - Epic (SU1) [nwaku]
- - Epic (SU1) [go-waku] -- post mvp approval
- - Epic (SU1) [js-waku] -- post mvp approval
...
- - Epic (SU2) [nwaku]
- - Epic (SU2) [go-waku] -- post mvp approval
- - Epic (SU2) [js-waku] -- post mvp approval
...

If the feature moves forward out of the nwaku mvp implementation, the Epics would breakdown by subteams and phases.

[Ivansete-status]

LGTM! Thanks for it! 💯

[Ivansete-status]

How should we use this list?

[fryorcraken]

This was meant to have the link tot he various github issues but I opted to remove it as it is dupe info.

[Ivansete-status]

I think is better to just have three possible terms: Milestone; Epic; and Taks. The simpler the better

[fryorcraken]

Deliverable is something asked by C&J for grant reason.
For now, this can be ignored. I'll actually remove it from the doc for simplicity purposes.

[Ivansete-status]

Shall we restrict to only use low-case in our labels?

Suggested change

	| `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:Dogfood` | js-waku, go-waku, nwaku | 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. |
	| `E:Docs` | Doc | Documentation (not auto-generated) | Document the new feature across all implementations, using the dogfooding output as handover material from engineering teams. |
	| `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. |
	| `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:dogfood` | js-waku, go-waku, nwaku | 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. |
	| `E:docs` | Doc | Documentation (not auto-generated) | Document the new feature across all implementations, using the dogfooding output as handover material from engineering teams. |
	| `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. |

[fryorcraken]

I just made client name lowercase for now. I think whatever reads best as these are then used in insight dashboards.
The dashboards are then supposed to be public.

@chair28980 what do you prefer?

[chair28980]

@fryorcraken i prefer lowercase 😄

[Ivansete-status]

IMO, a Task with sub-Tasks is an Epic. Then, I don't see the need for a Task to keep a list of other Tasks

[fryorcraken]

(1) improved Store protocol (2) basic sync protocol.

Can (1) be done, delivered and useful to developers and users without (2)? If so, then I would consider (1) as a milestone. and (2) as a different milestone.
They can be both in the same track and "Milestone: TWN Store Upgrade (SU)" could simply be viewed as 2024 message reliability track work.

The idea is to have minimal scope for the milestone so we can push them from research to dev rel asap.

In the case of (1) and (2). If I remember correctly as soon as (1) is done in go-waku and nwaku, Status will want to use it. Likely before (2) is finished.
Which means that all the steps after research (nwaku, go-waku, dogfooding, doc) for (1) need to happen independently from (2).

IMO, this also makes it simpler to understand what is done, and what remains to be done.

[fryorcraken]

I agree with your point that Epics should breakdown into appropriately sized batches of work. Using the Milestone you referenced as a rough template of what the work might break down to coming out of the Research phase

I also accept we need some flexibility for research. Thinking incentivization for example. Research can focus on having a bear minimum PoC but then consider that such PoC would be useless without some addition.

In this case, the "research epic" is not really completed. The work can continue with a second PoC. Once a useful PoC is out, then the scope of the PoC makes the milestone scope and gets pushed across to dev, docs, dev rel etc.

Remaining work can then be scoped in a new milestone.

[fryorcraken]

@Ivansete-status (not sure why I could not comment).

IMO, a Task with sub-Tasks is an Epic. Then, I don't see the need for a Task to keep a list of other Tasks

Similarly to above. The aim is to scope epics to a specific team.
Each team has their own epic for a milestone.
A milestone is minimal in scope.

Now, to achieve your team epic (e.g. E:nwaku Autosharding for autoscaling) you need to do a number of tasks.

This framework is very flexible on how your organize the task. Whether it's a bunch of GitHub issues on the repo, or just a check list in the epic issue, or both.

As long as:

• The GitHub issue related to the epic have the right epic label
• The PR related to the epic are referring back to a GitHub issue with the label.

This way nobody has to remember to set epic labels in PRs.

[chair28980]

(1) improved Store protocol (2) basic sync protocol.

Can (1) be done, delivered and useful to developers and users without (2)? If so, then I would consider (1) as a milestone. and (2) as a different milestone. They can be both in the same track and "Milestone: TWN Store Upgrade (SU)" could simply be viewed as 2024 message reliability track work.

The idea is to have minimal scope for the milestone so we can push them from research to dev rel asap.

In the case of (1) and (2). If I remember correctly as soon as (1) is done in go-waku and nwaku, Status will want to use it. Likely before (2) is finished. Which means that all the steps after research (nwaku, go-waku, dogfooding, doc) for (1) need to happen independently from (2).

IMO, this also makes it simpler to understand what is done, and what remains to be done.

I agree with this approach but note that it deviates from the approach of approach of fewer, larger milestones.

[jm-clius]

Can (1) be done, delivered and useful to developers and users without (2)

It can. This is just an example, though. There are other milestones with interdependent "subcomponents" that becomes a bit difficult to schedule as individual milestones with clear user benefits. Take the milestone to provide basic service protocol incentivization: we could divide this into milestones each for Store, Filter, Lightpush, etc. but this now becomes a breakdown that does not quite match the practical reality. We're more likely to complete this as a Store PoC, followed by generalisation to all service protocols and then concerted dogfooding to come up with a blueprint for productionisation. Each of these could be communicated as a milestone in its own right, but the "clear user benefit" IMO is best expressed as the overall goal of "basic service protocol incentivization". Some of these fine-grained milestones may also not even impact any team other than the Research team - PoCs for example can be done up to production plan without any other team involvement. Epics would then allow us to differentiate which tasks, towards the same milestone, belong to which teams. That said, this is mostly a matter of semantics and organisation, so I'm also happy to use finer-grained milestones.

[fryorcraken]

Can (1) be done, delivered and useful to developers and users without (2)

It can. This is just an example, though. There are other milestones with interdependent "subcomponents" that becomes a bit difficult to schedule as individual milestones with clear user benefits. Take the milestone to provide basic service protocol incentivization: we could divide this into milestones each for Store, Filter, Lightpush, etc. but this now becomes a breakdown that does not quite match the practical reality. We're more likely to complete this as a Store PoC, followed by generalisation to all service protocols and then concerted dogfooding to come up with a blueprint for productionisation. Each of these could be communicated as a milestone in its own right, but the "clear user benefit" IMO is best expressed as the overall goal of "basic service protocol incentivization". Some of these fine-grained milestones may also not even impact any team other than the Research team - PoCs for example can be done up to production plan without any other team involvement. Epics would then allow us to differentiate which tasks, towards the same milestone, belong to which teams. That said, this is mostly a matter of semantics and organisation, so I'm also happy to use finer-grained milestones.

I think it's important to go back to the reason why the new process is designed as it is and I realized I may have not expressed it clearly.

The attributes I am aiming for are:

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 (epic, milestones) can be easily be closed and marked as complete thanks to:
   • Minimal external dependencies
   • Minimal inter team dependency (e.g. nwaku epic can be closed without waiting for QA)
   • Finite, well-define scope.
3. Each milestone and the effort needed has a clear value thanks to a well-defined, value-driven, minimal, scope.

I understand that you are saying that research may need several PoC before we can handover to dev.

I think it's fine if we have a system where a team may have several epics under a milestone. E.g:

Milestone: Store Incentivization

• E:Research Store incentivization - Improved protocol
• E:Research Store incentivization - Basic sync protocol\

Then, once All PoC are done and ready to be handed over:

• E:nwaku Store incentivization

The point of having a process and some guidelines is to make it easy to operate with the wanted attributes (see above), and hard to go against the attributes.

In the case you mentioned, there are 2 paths:

1. Take store incentivization from PoV to MVP to Prod
2. Take store incentivization to PoV, then take generalization to PoV to MVP to Prod

I would argue that (1) is the preferred path.
Minimal scope to bring a useful value to the users and validate assumptions around req-res protocol incentivization before making it generalized.
If we decide to increase the scope and go for (2) we need to have a clear justification (e.g risk assessment etc).

[fryorcraken]

I am merging to also re-org the files and avoid conflicht with weekly update but we can do more changes down the line.
It seems the only contention point is around having several epics for a give team (see #107 (comment)).

[fryorcraken]

#112