Codex Project Management

For creating/tracking milestones, epics, and issues as well as populating/updating planning labels to all Codex organization repos.

Sub-teams

The Codex team is currently split into the following sub-teams:

• Codex Client
• Codex Marketplace
• Codex Infrastructure
• Codex Testing
• Codex Research
• Codex BD [TBA]

with support from the following external Logos teams:

• Token Engineering (Vac)
• Smart-Contracts (Vac)
• Communications (Acid.Info)

Work Tracking and Reporting Guidelines

1. Weekly Reporting
   • Each sub-team should have a weekly sync to discuss progress and blockers
   • Each sub-team should have a bi-weekly report to share with the Codex team
   • The project lead should have a weekly report to share with the Logos team
2. Monthly Reporting
   • Monthly reporting is done via the Program Lead/Owner via the Monthly Report that encompasses Codex updates inclusive of other Logos projects

Terminology

Name	Number of	Timeframe	Team Scope	Owner	Description
(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:

• 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 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. Hence:

• Dependencies must be clearly stated in Task issue description
• Team members must assign Task issues to themselves when work starts
• Team member must update issues to track progress

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.

GitHub Usage

A Milestone:

• 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)
• 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:...)

Reporting

Monthly:

Handled by Insights team

Weekly: Report progress on each active Epic or Task per sub-team.

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.

Milestones

https://github.com/codex-storage/codex-pm/milestones