HYPERFLEET-913 - docs: add team working agreement#121
HYPERFLEET-913 - docs: add team working agreement#121ciaranRoche wants to merge 1 commit intoopenshift-hyperfleet:mainfrom
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughCreated a new living-draft document at hyperfleet/docs/working-agreement.md that codifies an end-to-end team operating workflow: a Jira Definition of Ready gate, standardized ticket-to-merge steps (branching, commit conventions, local lint/tests, mandatory local AI review via Sequence Diagram(s)sequenceDiagram
participant Jira as Jira
participant Engineer as Engineer
participant Git as Git/Branch
participant LocalAI as Local AI Review (/review-pr)
participant PR as Pull Request
participant Reviewer as Peer Reviewer
participant Slack as Slack
participant ArchRepo as Architecture Repo
Jira->>Engineer: Ticket assigned (meets Definition of Ready)
Engineer->>Git: Create branch, implement changes, run lint/tests
Engineer->>LocalAI: Run local AI review (/review-pr)
LocalAI-->>Engineer: AI review comments
Engineer->>PR: Open Pull Request with required description and Jira link
PR->>Slack: Post PR and tag reviewers
Reviewer->>PR: Review (blocking vs nit comments)
alt Approved
Reviewer->>PR: Approve
Engineer->>Git: Merge
Engineer->>Jira: Link PR and mark Done
Engineer->>ArchRepo: Update architecture repo if behavior changed
else Changes requested or escalation
Reviewer->>Engineer: Request changes or escalate to Technical Lead/Architecture review
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
hyperfleet/docs/working-agreement.md (1)
195-205: Reduce drift from hard-coded meeting cadence detailsThe fixed counts and alternating cadence here are likely to go stale quickly. Consider keeping this section principle-based and linking to the team calendar/source-of-truth for exact frequency.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@hyperfleet/docs/working-agreement.md` around lines 195 - 205, Replace the hard-coded meeting cadence in the "Office Hours" section (lines referencing "2 calls in NASA-friendly time zones, 3 in APAC-friendly time zones" and "Once a week, alternating between APAC-friendly and NASA-friendly weeks") with a principle-based statement: describe the purpose and encouragement for recurring office hours, remove specific counts and rigid alternation, and add a pointer to the team calendar/source-of-truth for the current schedule and exact frequency (e.g., "See team calendar for current cadence").
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@hyperfleet/docs/working-agreement.md`:
- Line 210: Unify the conflicting guidance by choosing one clear rule for retros
(either “held at each team lead's discretion” or “regular/recurring as part of
continuous improvement”) and apply it consistently: update the "Retrospectives"
bullet to state the chosen cadence and then edit the "continuous-improvement"
section (the paragraph that currently describes retrospectives as a regular
practice) to reference that same rule and, if desired, add a short
cross-reference like "See: Retrospectives" so both sections reflect a single
source of truth.
---
Nitpick comments:
In `@hyperfleet/docs/working-agreement.md`:
- Around line 195-205: Replace the hard-coded meeting cadence in the "Office
Hours" section (lines referencing "2 calls in NASA-friendly time zones, 3 in
APAC-friendly time zones" and "Once a week, alternating between APAC-friendly
and NASA-friendly weeks") with a principle-based statement: describe the purpose
and encouragement for recurring office hours, remove specific counts and rigid
alternation, and add a pointer to the team calendar/source-of-truth for the
current schedule and exact frequency (e.g., "See team calendar for current
cadence").
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 54f879f3-8464-4c6a-b049-43d6017f70c5
📒 Files selected for processing (1)
hyperfleet/docs/working-agreement.md
ciaranRoche
force-pushed
the
HYPERFLEET-913-working-agreement
branch
2 times, most recently
from
5491bd5 to
a680988
Compare
There was a problem hiding this comment.
🧹 Nitpick comments (1)
hyperfleet/docs/working-agreement.md (1)
213-213: Clarify sprint demo attendance expectation.All other meetings in this section specify attendance requirements (e.g., "Every engineer is required", "Not mandatory, but encouraged", "Mandatory for team leads only"), but the sprint demo line doesn't indicate whether attendance is required, encouraged, or optional. Adding a brief attendance guideline would improve clarity.
📝 Suggested addition
-- **Sprint demo**: Once per sprint, with NASA-friendly and APAC-friendly sessions +- **Sprint demo**: Once per sprint, with NASA-friendly and APAC-friendly sessions. Attendance encouraged to share progress and learn from other teams🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@hyperfleet/docs/working-agreement.md` at line 213, The sprint demo line ("**Sprint demo**: Once per sprint, with NASA-friendly and APAC-friendly sessions") lacks an attendance expectation; update that line to append a short attendance guideline (e.g., "Attendance: All engineers required", "Attendance: Not mandatory, but encouraged", or "Attendance: Mandatory for team leads only") to clarify who should attend; edit the sentence in working-agreement.md so the sprint demo entry matches the other meeting lines' format and tone.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@hyperfleet/docs/working-agreement.md`:
- Line 213: The sprint demo line ("**Sprint demo**: Once per sprint, with
NASA-friendly and APAC-friendly sessions") lacks an attendance expectation;
update that line to append a short attendance guideline (e.g., "Attendance: All
engineers required", "Attendance: Not mandatory, but encouraged", or
"Attendance: Mandatory for team leads only") to clarify who should attend; edit
the sentence in working-agreement.md so the sprint demo entry matches the other
meeting lines' format and tone.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: d4a531a9-49c4-489e-9c45-bdc81c80adda
📒 Files selected for processing (1)
hyperfleet/docs/working-agreement.md
ciaranRoche
force-pushed
the
HYPERFLEET-913-working-agreement
branch
from
a680988 to
62d42bc
Compare
There was a problem hiding this comment.
♻️ Duplicate comments (1)
hyperfleet/docs/working-agreement.md (1)
215-215:⚠️ Potential issue | 🟠 MajorResolve retrospective cadence inconsistency
Line 215 states retrospectives are "held at each team lead's discretion," while Line 290 references retrospectives as part of the continuous improvement process (implying regular occurrence). This creates conflicting expectations about whether retrospectives are optional/ad-hoc or required/recurring.
Please unify the guidance: choose one clear rule (either at team lead's discretion OR regular/recurring) and apply it consistently in both sections.
Also applies to: 290
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@hyperfleet/docs/working-agreement.md` at line 215, Unify the retrospective cadence by choosing one policy and applying it to both occurrences: update the "Retrospectives" sentence (the line starting "**Retrospectives**: Held at each team lead's discretion...") and the later reference under the "continuous improvement process" section (the paragraph that mentions retrospectives) so they match; either change both to say retrospectives are "held at each team lead's discretion" or change both to require "regular/recurring retrospectives (e.g., monthly or after each sprint)" and ensure the chosen wording and cadence are consistent across both places.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@hyperfleet/docs/working-agreement.md`:
- Line 215: Unify the retrospective cadence by choosing one policy and applying
it to both occurrences: update the "Retrospectives" sentence (the line starting
"**Retrospectives**: Held at each team lead's discretion...") and the later
reference under the "continuous improvement process" section (the paragraph that
mentions retrospectives) so they match; either change both to say retrospectives
are "held at each team lead's discretion" or change both to require
"regular/recurring retrospectives (e.g., monthly or after each sprint)" and
ensure the chosen wording and cadence are consistent across both places.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: e6b9e88d-7d8c-42bd-8594-ed8e060468ef
📒 Files selected for processing (1)
hyperfleet/docs/working-agreement.md
|
Awesome work @ciaranRoche !!! |
ciaranRoche
force-pushed
the
HYPERFLEET-913-working-agreement
branch
from
62d42bc to
11265b8
Compare
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
There was a problem hiding this comment.
♻️ Duplicate comments (1)
hyperfleet/docs/working-agreement.md (1)
216-216:⚠️ Potential issue | 🟠 MajorResolve conflicting retrospective cadence language.
Line 216 says retrospectives are discretionary, while Line 291 frames retrospectives as an expected continuous-improvement mechanism. Keep one explicit rule and reference it in both places to avoid ambiguous team expectations.
As per coding guidelines, "**: -Focus on major issues impacting performance, readability, maintainability and security. Avoid nitpicks and avoid verbosity."
Also applies to: 291-295
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@hyperfleet/docs/working-agreement.md` at line 216, There are two conflicting statements about retrospectives (the standalone "Retrospectives" line and the later continuous-improvement section); pick one canonical policy and make both references point to it — e.g., replace the discretionary phrasing in the first instance with a concise rule such as "Retrospectives: Conducted regularly as a continuous-improvement mechanism (e.g., after each sprint or bi‑weekly); team leads may convene additional sessions as needed" and in the later section reference that canonical rule by name ("See 'Retrospectives' policy above") so both places are explicit and consistent.
🧹 Nitpick comments (2)
hyperfleet/docs/working-agreement.md (2)
139-149: Avoid duplicating ADR trigger criteria; reference the ADR guide directly.The criteria here overlap with
hyperfleet/adrs/README.md“When to Write an ADR”. Prefer a short summary plus a direct pointer to that section so ADR policy is maintained in one place.As per coding guidelines, "**: -Focus on major issues impacting performance, readability, maintainability and security. Avoid nitpicks and avoid verbosity."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@hyperfleet/docs/working-agreement.md` around lines 139 - 149, Replace the duplicated ADR trigger criteria under the "### When to Document a Decision" heading with a concise one-line summary (e.g., "Document decisions with architectural impact, cross-team scope, or significant trade-offs") and add a direct pointer to the ADR guide (link/reference to ../adrs/README.md and its "When to Write an ADR" section); update or remove the bullet list so the authoritative criteria live only in the ADR README and this file simply references that section for details.
34-64: Reduce duplicated PR workflow and defer to CONTRIBUTING as the source of truth.This section restates most of
CONTRIBUTING.md(branching, PR content, Slack notification, 24-hour review rule), which creates drift risk. Keep only team-specific deltas here and link toCONTRIBUTING.mdfor the canonical flow.As per coding guidelines, "**: -Focus on major issues impacting performance, readability, maintainability and security. Avoid nitpicks and avoid verbosity."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@hyperfleet/docs/working-agreement.md` around lines 34 - 64, The Working Agreement duplicates PR/branching workflow from CONTRIBUTING.md (sections "Branch and Develop", "Open a PR", "Review and Merge"); remove or collapse that duplicated content and replace it with a short pointer to CONTRIBUTING.md plus only team-specific deltas (e.g., keep HYPERFLEET ticket naming convention and the 24-hour review expectation if that is team-specific). Specifically, edit hyperfleet/docs/working-agreement.md to: 1) remove redundant bullets under "Branch and Develop", "Open a PR", and "Review and Merge"; 2) add a single concise line linking to CONTRIBUTING.md for canonical process; and 3) retain and clearly call out any team-unique rules (like Jira project naming HYPERFLEET, branch naming HYPERFLEET-XXX-brief-description, and the requirement to tag `@hyperfleet-code-review`) so readers see only deltas from CONTRIBUTING.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@hyperfleet/docs/working-agreement.md`:
- Line 216: There are two conflicting statements about retrospectives (the
standalone "Retrospectives" line and the later continuous-improvement section);
pick one canonical policy and make both references point to it — e.g., replace
the discretionary phrasing in the first instance with a concise rule such as
"Retrospectives: Conducted regularly as a continuous-improvement mechanism
(e.g., after each sprint or bi‑weekly); team leads may convene additional
sessions as needed" and in the later section reference that canonical rule by
name ("See 'Retrospectives' policy above") so both places are explicit and
consistent.
---
Nitpick comments:
In `@hyperfleet/docs/working-agreement.md`:
- Around line 139-149: Replace the duplicated ADR trigger criteria under the
"### When to Document a Decision" heading with a concise one-line summary (e.g.,
"Document decisions with architectural impact, cross-team scope, or significant
trade-offs") and add a direct pointer to the ADR guide (link/reference to
../adrs/README.md and its "When to Write an ADR" section); update or remove the
bullet list so the authoritative criteria live only in the ADR README and this
file simply references that section for details.
- Around line 34-64: The Working Agreement duplicates PR/branching workflow from
CONTRIBUTING.md (sections "Branch and Develop", "Open a PR", "Review and
Merge"); remove or collapse that duplicated content and replace it with a short
pointer to CONTRIBUTING.md plus only team-specific deltas (e.g., keep HYPERFLEET
ticket naming convention and the 24-hour review expectation if that is
team-specific). Specifically, edit hyperfleet/docs/working-agreement.md to: 1)
remove redundant bullets under "Branch and Develop", "Open a PR", and "Review
and Merge"; 2) add a single concise line linking to CONTRIBUTING.md for
canonical process; and 3) retain and clearly call out any team-unique rules
(like Jira project naming HYPERFLEET, branch naming
HYPERFLEET-XXX-brief-description, and the requirement to tag
`@hyperfleet-code-review`) so readers see only deltas from CONTRIBUTING.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 678e51d7-ea0f-48bf-897c-ca45619196ba
📒 Files selected for processing (1)
hyperfleet/docs/working-agreement.md
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
ciaranRoche
force-pushed
the
HYPERFLEET-913-working-agreement
branch
from
11265b8 to
e9c3984
Compare
4 participants
Summary
hyperfleet/docs/working-agreement.mdthat supersedes the deprecated MVP working agreementTest plan
🤖 Generated with Claude Code
Summary by CodeRabbit