| (Key) Milestone | 1-3 per year | Set yearly-ish/as needed | Most subteams | Codex Lead | Key achievements for the Codex project, historical milestones. |
| Epic | Several per milestone | Set for a milestone, delivered monthly | Several subteams or external team (e.g. Commujnications) | Team Members | Chunk of a _Milestone_ across all clients. |
| Task | Many per Epic | Set monthly-ish, delivered weekly | One subteam or individual | Team Member | May be one or several piece of work, client specific. |
### Epic Owner Responsibilities
Each epic should have an owner per affected subteam (e.g. Codex Client, Codex Marketplace, Codex Infrastructure, Codex Testing, Codex Research, Codex BD) who is responsible for:
- Capturing the problem statement
- Defining the scope
- Defining the success criteria
- Designing and implementing the PoC
- Creating unit & integration tests/simulations to confirm PoC performance meeting success criteria
For development teams, it is expected that design/break down is done by epic owner. But actual work can be picked up by other team member. Epic owner must:
- 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 epic owner will do the core change or first change for a given epic. However, subsequent/other changes may be picked up in parallel or sequentially by other team members.
The program manager should ensure that epics are getting the right assignee in a timely fashion. For example, when research work starts for a given epic, epic 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, an is encouraged to use client PM call as a forum to check epics to be assigned. For example, when PoC is near completion then breaking down the work should be started.
- MUST have a matching GH issue in the https://github.com/codex-storage/codex-pm repo with `milestone` label assigned
- MUST have a GH Milestone in https://github.com/codex-storage/codex-pm repo, to which relevant _Epics_ are added
- SHOULD have a roadmap to delivery done at planning phase, the GH milestone is then used to track progress
An _Epic_:
- MUST have a matching GH issue in the https://github.com/codex-storage/codex-pm with `epic` label assigned.
- MUST have a label with format `E:<epic name>` created across all relevant https://github.com/codex-storage/ repos (see [labels.yml](./.github/labels.yml))
- SHOULD be added to a GH Milestone
- SHOULD 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 one assignee **per subteam**, who represent the epic owner
A _Task_:
- MAY be tracked as a todo item in a GH Issue (_Task_ or _Epic_),
- OR MAY be tracked as a single GH issue
- that MUST be labelled with related _Epic_ label (`E:...`),
- OR MAY be tracked as a GH Pull Request
- that MUST be labelled with related _Epic_ label (`E:...`),
- 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 _Milestone_:
- MUST have either labels:
-`bug`: This is a bug, likely reported by a user
-`enhancement`: This is an enhancement out of the scope of the technical roadmap, likely reported by a user
- Major enhancements should be carefully reviewed and prioritized
-`documentation`: Documentation improvement or correction
-`dependencies`: Upgrade dependencies in a timely manner to avoid time wasting when the dependency upgrade becomes critical
Which means, in terms of _navigation_:
- Work for a Milestone is described in the related GitHub issue and tracked in the GitHub milestone.
- In the GitHub milestone, we have a list of _Epics_ to be achieved, the _Epics_ are being closed as the work is done across one or more sub-teams
- To look at remaining work for an _Epic_, one need to look at all issues/PRs (_Tasks_) with the corresponding _Epic_ label (`E:...`)
- Every Friday, all team members must include a weekly summary of their work and progress in the #standups channel within the Codex Discord server inclusive of any links to relevant Epics/Issues/PRs.
- On Monday, project lead or responsible person for report can generate a report and post it in the Logos Discord server in the #leads-roundup channel.
