01
Study An Action Before You Use It
Do not use or call an action until you have taken time to study it and understand how it works.
Platform Discipline
Operate carefully, communicate clearly, and close the loop every week.
These are the working rules for the Platform workspace. They are here to keep delivery disciplined, make blockers visible, and ensure operational reporting happens consistently.
Reminder:
strong execution is not only about shipping work, it is also about documenting intent, blockers, and outcomes.
Core Rules
Follow the main platform rules across delivery, reporting, and team accountability.
Click this card to expand the rule breakdown for daily reporting, blockers, actions, timesheets, and weekly SRE expectations.
Follow the main platform rules across delivery, reporting, and team accountability.
Click this card to expand the rule breakdown for daily reporting, blockers, actions, timesheets, and weekly SRE expectations.
02
Explain Blocked Tickets Clearly
If you move a Taiga ticket to Blocked, you must describe why the ticket is blocked.
03
Send Your Daily Mattermost Report
It is mandatory to send your daily report on Mattermost.
04
Submit Your Weekly Timesheet
It is mandatory to submit your timesheet by the end of the week.
05
Send Your Weekly SRE Report
It is mandatory to send your SRE report by the end of the week.
06
Follow The Platform PR Routing Rules
Do not assign platform pull requests to an individual. Assign them to DEVOPSEASYLEARNING TEAM, add the PR link to the related ticket, post the PR link in the team channel with your POC lead tagged, do not tag Mr. Tia, Mr. Eric, Mr. Ikoyi, or Mr. Godwill for review, and make sure everyone reviews at least one PR each week.
Before Starting Work
Follow this pre-work flow before you start coding, changing pipelines, or touching infrastructure.
Click to reveal the smaller step cards for understanding the task, checking dependencies, planning, testing, and using AI at the right point.
Follow this pre-work flow before you start coding, changing pipelines, or touching infrastructure.
Click to reveal the smaller step cards for understanding the task, checking dependencies, planning, testing, and using AI at the right point.
Before Starting Work
Follow this flow before you touch code, pipelines, or infrastructure.
Use this sequence as the operating checklist for Platform work so the task is understood, the impact is clear, and AI is used only after the context is solid.
01
Understand The Problem
Know exactly what issue the ticket is solving before you begin.
02
Understand The Requirements
Be clear on what is expected and what the solution must do.
03
Understand The Deliverable
Identify what must be delivered, whether it is code, pipeline work, configuration, or something else.
04
Check Dependencies
Confirm whether the work impacts other services, pipelines, or infrastructure.
05
Be Able To Explain It
If you cannot clearly explain the task, do not start yet.
06
Clarify If Needed
Ask questions early instead of guessing.
07
Plan Your Approach
Think through the steps before you start implementing.
08
Follow Standards
Align with the existing architecture, naming, and team patterns.
09
Test Your Work
Make sure it works and does not break anything else.
10
Keep It Secure
Do not expose secrets and follow security best practices.
11. Then Use AI
Once everything is clear, ask AI the right question so you can get the right answer.
Pause And Reset
Use this realignment checklist before continuing ticket work that feels unclear or inconsistent.
Review the deployment and CI/CD validation questions that help you stop guesswork and reset the approach.
Use this realignment checklist before continuing ticket work that feels unclear or inconsistent.
Review the deployment and CI/CD validation questions that help you stop guesswork and reset the approach.
Pause And Reset
If you are working on any tickets, stop and realign first.
Before continuing, take a short break and validate the deployment picture end to end so the work stays structured, aligned, and grounded in the real CI/CD flow.
01
What exactly still needs to be done?
Be precise about the remaining work before touching the implementation again.
02
What has already been completed?
Confirm what is already done, especially CI work, so effort is not duplicated.
03
Do I clearly understand the CI pipeline?
Do not continue if the CI path is still vague or only partially understood.
04
Can I explain the CI flow simply?
If you cannot explain it clearly to someone else, study it again first.
05
Is the current CI achieving its purpose?
Check whether the pipeline is actually delivering the intended outcome.
06
What does the full deployment picture look like?
Understand CI, CD, and runtime together rather than treating them as separate pieces.
07
Are reusable jobs or actions already available?
Reuse proven jobs and actions instead of reinventing the pipeline path.
08
Is there a completed microservice to use as reference?
Look for an existing service that already solved the same delivery pattern.
09
Am I following established patterns?
Stay aligned with the standards already used across the platform and service repos.
10
Have I checked other Connect implementations?
Compare against other Connect services before inventing a new approach.
11
Have I discussed my approach with a teammate?
Do not stay isolated if the deployment path is uncertain or feels inconsistent.
12
Should I escalate to my POC?
Get guidance early if the right path is unclear or the ticket is drifting.
Warning
The process becomes risky when it is inconsistent and unstructured. Do not proceed blindly. If you ask AI unclear or incorrect questions, you do not just get a wrong answer, you risk getting misleading output that can break your implementation. Bring structure and alignment before continuing.
PR Review Rules
Apply these pull request review rules to keep reviews structured, traceable, and accountable.
Click to reveal the smaller cards covering Taiga linking, reviewer routing, notifications, and review responsibility.
Apply these pull request review rules to keep reviews structured, traceable, and accountable.
Click to reveal the smaller cards covering Taiga linking, reviewer routing, notifications, and review responsibility.
PR Review Rules
Pull request reviews must be structured, traceable, and accountable.
These review rules apply immediately across teams to improve traceability, reviewer accountability, and code quality.
01
PR And Taiga Ticket Linking
- The PR link must be attached to the Taiga ticket.
- The Taiga ticket number must appear in the PR title and description.
PR Title
TAIGA-145 Fix member balance calculation
PR Description
Related Ticket: TAIGA-145
02
POC Team Pull Requests
- The PR must first be reviewed by two members of the POC team.
- After that, it must be reviewed by Eric Kemvou, Godwill Ocheme, and Tia Leonard.
03
Pull Requests From Other Platform Teams
- The team POC must assign the PR to two members of the same team where the PR originated.
- The team POC must also assign one random member from another team for cross-team review.
04
Reviewer Notification
- The POC must notify reviewers by email and on Mattermost.
- The email must CC Eric, Tia, and Godwill for traceability and accountability.
05
Review Responsibility
Anyone assigned a PR review must complete it within a reasonable timeframe. Review delays block development and affect the whole team.
- Provide feedback.
- Approve or request changes.
- Maintain code quality and security standards.
Expectation
Review work is not optional overhead. It is part of delivery, part of accountability, and part of maintaining platform quality across teams.
Platform PR Guidelines
Use these platform pull request guidelines for assignment, tracking, sharing, and review routing.
Review the team assignment, ticket linking, channel posting, and weekly review participation rules here.
Use these platform pull request guidelines for assignment, tracking, sharing, and review routing.
Review the team assignment, ticket linking, channel posting, and weekly review participation rules here.
Platform PR Guidelines
Handle platform pull requests as a team, not as an individual queue.
These guidelines define how Platform pull requests should be assigned, tracked, shared, and reviewed across the team.
01
Assign To The Team
Do not assign the PR to an individual. Assign it to DEVOPSEASYLEARNING TEAM.
02
Link The PR To The Ticket
The PR link must be added to the related ticket for proper tracking.
03
Post The PR In The Team Channel
The PR link must also be posted in the team channel, and your POC lead must be tagged when you post it.
04
Do Not Escalate Reviews To Leadership
Do not tag Mr. Tia, Mr. Eric, Mr. Ikoyi, or Mr. Godwill to review your tickets or pull requests.
05
Review Among Yourselves As A Team
Everyone is encouraged to review tickets and pull requests collaboratively within the team.
06
Weekly Review Participation Is Mandatory
Every team member must review at least one pull request per week, or more if possible.
Support Path
If anything about the review process is unclear, contact your direct POC for guidance rather than escalating the review request blindly.
PR Review Workflow
Follow this pull request review process in the correct sequence from ticket linking to final approval.
Review the required steps for reviewer assignment, POC notification, feedback resolution, and final approval.
Follow this pull request review process in the correct sequence from ticket linking to final approval.
Review the required steps for reviewer assignment, POC notification, feedback resolution, and final approval.
PR Review Workflow
Follow this review sequence so pull requests are traceable, reviewed, and approved in the right order.
This workflow keeps ticket tracking, team review, and POC approval aligned before any pull request is considered complete.
01
Link PR To Ticket
Ensure the Pull Request link is added to the corresponding ticket.
02
Assign Reviewers
Assign the ticket to two team members and your POC (Point of Contact) for review.
03
Notify POC
Notify your POC on Mattermost once the Pull Request is ready for review.
04
Team Review First
Your assigned team members must review the Pull Request and provide feedback.
05
Resolve All Comments
Address all feedback and ensure there are no unresolved conversations in the Pull Request.
06
POC Final Review
Once all comments are resolved, the POC will perform the final review and approval.
Sequence Matters
The POC should not do the final approval until team reviews are completed and every unresolved conversation has been cleared.
Daily Stand-up Reports
Submit daily stand-up reports in the required Mattermost thread and reporting format.
Review the mandatory submission, reply format, centralized tracking, and status update expectations here.
Submit daily stand-up reports in the required Mattermost thread and reporting format.
Review the mandatory submission, reply format, centralized tracking, and status update expectations here.
Daily Stand-up Reports
Submit daily stand-up updates in the expected Mattermost thread so reporting stays visible and easy to track.
This rule keeps daily team reporting centralized, searchable, and consistent across every team member.
01
Submission Is Mandatory
All team members are required to submit their daily stand-up report.
02
Reply To The Bot Reminder
Send the report on Mattermost by replying directly to the reminder message published by the bot.
03
Keep Updates Centralized
Replying in the reminder thread ensures all stand-up updates are centralized and easy to track.
04
Respond Even If No Work Was Done
Even if no work was completed the previous day, you must still respond and provide a status update.
Consistency Matters
Daily stand-up reporting is not optional. The goal is to keep updates visible in one thread so blockers, progress, and follow-ups are easy to review.