Development Process
What Do I Do If…
…I need help from another team?
Add the label for the team whose input you need: help-Backend,
help-Frontend, or help-UIUX. For example, if you’re on the frontend team
and need backend input, add help-Backend.
…I need help from another team, and I’m blocked until I receive it?
Do the above (add the relevant help-* label), then also:
- Add the
proc-Blockedlabel, so the issue is visibly stalled rather than silently idle. - Assign the issue to that team’s lead. If you don’t know who that is,
check the target repository’s
.ayode/issue-automation.configfile for itsteamLeadentry.
…I have a question about the issue?
Add a comment starting with request: @<username> (e.g. request: @octocat)
— the space between the colon and the @ matters: without it, GitHub’s
comment editor won’t offer its autocomplete dropdown of valid usernames, so
typing the space first is how you actually pick the right person. The
automation bot posts a tracking comment that notifies that person, and keeps
the request visible — oldest first — on their Daily Plan report until they
respond and check the confirmation box.
Executable Issue Plans
GitHub issues must contain enough verified context and planning for engineering work to begin immediately. An issue plan is executable only when it is sufficiently annotated, scoped, and validated so that no additional investigation, planning, or other preparatory work is required before execution.
The required preparation depends on the kind of work:
- RCA — Root Cause Analysis: An evidence-based investigation recorded on a GitHub issue after a bug in the development silo or an incident in the production silo. It determines the underlying cause and contributing conditions. A completed RCA must be followed by an ERP.
- ERP — Executable Remediation Plan: The plan for correcting the bug or production incident identified through RCA. It defines the verified cause, remediation scope, concrete changes, risks, dependencies, validation, and acceptance criteria needed for remediation to begin immediately.
- EIP — Executable Implementation Plan: The plan for delivering a new feature. It defines the feature scope, concrete changes, risks, dependencies, validation, and acceptance criteria needed for implementation to begin immediately.
The issue-management process is:
- Bug or production incident: complete the RCA, produce the ERP, then execute the remediation.
- New feature: produce the EIP, then execute the implementation.
An RCA by itself is not an executable plan. Likewise, an ERP or EIP that still requires preparatory work is incomplete and must not proceed to execution.
| Status | Description | Team Responsible for Moving Issue Into Status |
|---|---|---|
| Backlog (Unrefined) | Raw idea, request, defect, or work item that has not yet been clarified or prioritized. | Project Management |
| Backlog (Ready) | Refined and sufficiently defined item that is ready for sprint selection. | Project Management |
| Sprint Selected | Item selected and committed for the current sprint. | Project Management |
| Development | Engineering has started implementation or remediation work. | Engineering |
| Ready for Review | Engineering has completed implementation and marked the issue ready for code review. | Engineering |
| Code Review | Engineering is actively reviewing the implementation. | Engineering |
| Review Approved? | Decision point indicating whether code review passed or requires rework. | Engineering |
| Ready for Development Deployment | Review-approved work is ready to be deployed to the development environment. | Engineering |
| Deployed to Development | Work has been deployed to the development environment and is ready for QA. | Operations |
| QA (Development) | QA is validating the work in the development environment. | Quality Assurance |
| Dev QA Approved? | Decision point indicating whether development-environment QA passed or requires rework. | Quality Assurance |
| Ready for Production Deployment | QA-approved work is ready to be deployed to production. | Quality Assurance |
| Deployed to Production | Work has been deployed to the production environment. | Operations |
| QA (Production) | QA is validating the work in production after deployment. | Quality Assurance |
| Prod QA Approved? | Decision point indicating whether production validation passed or requires rework. | Quality Assurance |
| Closed | Work is complete, validated, and no further action is required. | Quality Assurance |
Priority Rubric
The Priority field on the Ayode Academy Global project board ranges from
P0 (Critical) to P4 (Trivial). Because a live production incident always
outranks any development-only issue, the two environments do not share a
symmetric scale: P0 is reserved exclusively for production, so the most
severe a development-only issue can ever be rated is P1.
| Priority | Description | Development | Production |
|---|---|---|---|
| P0 (Critical) | Blocks essential functionality; requires immediate resolution (e.g., system crash, data loss). | Not used. No development-only issue is ever more urgent than a live production issue — the ceiling for a development issue is P1. | Live outage or active data loss/corruption hitting real students/instructors right now — a 5xx storm, an auth bypass crossing realms, a billing double-charge. Bypasses the sprint queue: hotfix path, notify the operator immediately. |
| P1 (High) | Major impact but has a workaround; needs a quick fix (e.g., payment processing failure). | The worst a development issue can be: breaks the build/deploy pipeline, corrupts development data, or blocks the promotion train entirely. Must resolve before production promotion can proceed, but has zero live impact. | Major impact but a workaround exists, or the blast radius is partial (one endpoint, one realm/partition). Expedited into the current or next release, not a stop-the-world hotfix. |
| P2 (Medium) | Affects functionality but is not urgent; scheduled for an upcoming release (e.g., incorrect UI alignment). | A core feature is broken in development/blue-green testing, but a workaround lets QA/api-check keep validating. Must land before the next promotion; does not block today’s development deploy. | A known incorrect behavior live in production affecting a minority of requests, with no data-integrity or security implication. Scheduled into a normal sprint. |
| P3 (Low) | Minor impact, non-breaking issue; may be deferred (e.g., typos, minor UI glitches). | A functional bug caught in development testing that must be fixed before its own PR/train ships, but risks no other in-flight work. | Minor, non-breaking, low-visibility issue live in production — cosmetic text, minor UI misalignment. Backlog, fixed opportunistically. |
| P4 (Trivial) | Cosmetic or non-impactful issue; may be addressed if time allows (e.g., preference setting improvements). | Cosmetic or non-blocking issue visible only on an internal/development-only surface. Never blocks any gate. | Cosmetic-only in production with zero functional impact. Backlog indefinitely, picked up only if convenient. |
Development-column severity is judged by whether the issue blocks promotion to production; production-column severity is judged by live blast radius to real users and data. The scale is intentionally asymmetric — production spans the full P0–P4 range, development only ever spans P1–P4 — as the direct expression of that principle.
Label Taxonomy
The following table documents the canonical synchronized label set used across the academy repositories. Each category has a dedicated color family, and each label below is shown with the same color currently used in GitHub.
| Category | Explanation | Automation | Labels |
|---|---|---|---|
| Workflow | Workflow labels indicate deployment state for completed work as it moves through environments. | None. |
deploy-DEVIndicates the work has been deployed to development.
deploy-PRDIndicates the work has been deployed to production.
|
| Process | Process labels capture workflow exceptions, administrative handling, or special issue-management treatment. | None. |
proc-AnalyzedAnalysis is complete and the issue contains the applicable executable plan: an RCA and ERP for a bug or production incident, or an EIP for a new feature. No additional preparatory work is required before execution begins.
proc-BlockedWork is blocked and cannot proceed yet.
proc-HumanRequiredAutomated analysis or RCA cannot proceed independently and requires human information, judgment, authorization, or action. The label remains until the required human assistance is provided.
proc-OmitAssignmentBookkeeping-only item not intended for individual assignment.
proc-OmitQAQA is intentionally omitted because no user-visible behavior requires validation.
proc-UseCaseIdentifies use-case definition or use-case tracking work.
|
| Help | Help labels flag that an issue needs input, review, or hands-on assistance from another team. | None. |
help-BackendNeeds input or assistance from the Backend team.
help-FrontendNeeds input or assistance from the Frontend team.
help-UIUXNeeds input or assistance from the UI/UX team.
|
| Feature Set | Feature-set labels group work by major product surface instead of finer-grained subfeatures. | None. |
fset-CurriculaLibraryTracks work for the Curricula Library feature set.
fset-FlightPathTracks work for the FlightPath feature set.
fset-InstructorHelmTracks work for the Instructor Helm feature set.
fset-InstructorStudioTracks work for the Instructor Studio feature set.
fset-StudentHelmTracks work for the Student Helm feature set.
fset-StudentLabTracks work for the Student Lab feature set.
|
| Release | Release labels group work by the targeted named release. The current release is purple, the next release is lilac, and later releases use pale purple. | Adding or removing canonical rel-* labels updates the issue milestone to the resolved release, and parent issue release-label changes propagate matching release labels and milestones through all descendant sub-issues in the same repository. rel-LATER is ignored. |
rel-FateshadeTracks work for the current release.
rel-GlimmerenTracks work for the next scheduled release.
rel-HexwynTracks work for the Hexwyn release.
rel-IridaneTracks work for the Iridane release.
rel-JynthisTracks work for the Jynthis release.
rel-KelspireTracks work for the Kelspire release.
rel-LuminethTracks work for the Lumineth release.
rel-MythrylTracks work for the Mythryl release.
rel-NetherilTracks work for the Netheril release.
rel-OmbricTracks work for the Ombric release.
rel-PyreluneTracks work for the Pyrelune release.
rel-QuenlorTracks work for the Quenlor release.
rel-RuneborneTracks work for the Runeborne release.
rel-SylvarisTracks work for the Sylvaris release.
rel-ThrymereTracks work for the Thrymere release.
rel-UmbrithTracks work for the Umbrith release.
rel-VexalonTracks work for the Vexalon release.
rel-WyrmrestTracks work for the Wyrmrest release.
rel-XaltheonTracks work for the Xaltheon release.
rel-YsiluneTracks work for the Ysilune release.
rel-ZephirynTracks work for the Zephiryn release.
|
| Initiator | Initiator labels show which automation, signal, or trigger originated the work item. | None. |
init-ApiCheckWork initiated by api-check automation.
init-CVEWork initiated by CVE discovery.
init-deprecationWork initiated by a deprecation notice or deprecation tracking event.
init-VulnScanWork initiated by vulnerability scanning.
|
| Impact | Impact labels describe the primary business or technical consequence the work is intended to address. | None. |
imp-costWork with cost impact or cost-optimization impact.
imp-legalWork with legal or compliance impact.
imp-performanceWork with performance impact.
imp-responsivenessWork with responsiveness or latency impact.
imp-securityWork with security impact.
imp-security-vulnWork with security impact tied to a specific vulnerability.
|
Canonical release labels begin at rel-Fateshade. The passed release rel-Embernox is no longer part of the synchronized label set.