From d8ac0831dcc2156acf41cce8ae85d822e165a326 Mon Sep 17 00:00:00 2001 From: jessiebroke <18238304+jessiebroke@users.noreply.github.com> Date: Tue, 28 Nov 2023 01:16:03 -0500 Subject: [PATCH] update README.md to reflect current project tracking & reporting flow --- README.md | 103 ++++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 101 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index c50bebc..ac17a20 100644 --- a/README.md +++ b/README.md @@ -1,2 +1,101 @@ -# codex-pm -For populating milestone, epic, and planning labels to all Codex organization repos. +# 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:` 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:...`) + +### 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 \ No newline at end of file