logos-storage/logos-storage-pm
1
0
Fork 0
mirror of https://github.com/logos-storage/logos-storage-pm.git synced 2026-01-03 14:03:07 +00:00
Code Issues Packages Projects Releases Wiki Activity

update README.md to reflect current project tracking & reporting flow

Browse Source
This commit is contained in:
jessiebroke 2023-11-28 01:16:03 -05:00
parent fe8fecd9f1
commit d8ac0831dc
No known key found for this signature in database
GPG Key ID: D901DC638A938F8C
1 changed files with 101 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

103
README.md
View File

@ -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:<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:...`)
### 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