david.delagneau
dbc1894e27
- Introduced new maps for navigating project knowledge, including "Current Work," "Fidelity Domain," "Fidelity Apps," "Work Items," and "People." - Created base files for daily notes, decisions, people, systems, work items, and workstreams with defined properties and views. - Developed templates for daily notes, decisions, meeting notes, persons, systems, work items, and workstreams to standardize documentation. - Updated scripts and prompts to reflect the new project-knowledge directory structure. - Removed outdated onboarding and start-here documents, consolidating relevant information into the new maps. - Ensured all references in workflows and scripts point to the new project-knowledge paths.
66 lines
2.8 KiB
Markdown
66 lines
2.8 KiB
Markdown
---
|
|
type: process
|
|
project: fidelity
|
|
status: active
|
|
updated: 2026-04-16
|
|
tags: [process, communication]
|
|
---
|
|
|
|
# Communication Rules
|
|
|
|
## Purpose
|
|
|
|
These rules keep standups, Jira notes, and Mattermost messages aligned with the actual state of the work.
|
|
|
|
---
|
|
|
|
## Rules
|
|
|
|
- Prefer explicit scope over short vague statements
|
|
- Always mention auth state when it changes reproducibility
|
|
- Separate external report from regression
|
|
- Say whether behavior was confirmed in main when that comparison exists
|
|
- End with the next action when writing status updates
|
|
- Distinguish clearly between the current issue, unrelated preexisting bugs, workarounds, and follow-up work
|
|
- Prefer evidence-backed statements over intuition when communicating status
|
|
- Include branch, build, environment, account, flow, or entry-point details when they materially affect reproduction or ownership
|
|
- When reporting several updates for the same Jira item, group them under one top-level `JIRA-ID - Title` bullet with indented markdown sub-bullets
|
|
- Use real flow identifiers and page names when shorthand could be ambiguous
|
|
- Route ownership explicitly when the issue belongs to a consumer app, service/configuration, or another framework instead of XFlow
|
|
- Do not present a fix as ready if it introduces a new bug or unresolved regression
|
|
- Administrative/project-tracking updates should be prompt when others are visibly waiting on them
|
|
|
|
---
|
|
|
|
## English Quality Rules
|
|
|
|
- Write in natural, professional US English that sounds like a fluent engineer wrote it
|
|
- Prefer direct phrasing over literal or translated-sounding wording
|
|
- Avoid unnecessary softeners or filler such as "actually," "I think" or "for now" unless they add real scope or uncertainty
|
|
- If the message was originally rough or written by a non-native speaker, rewrite it fully instead of preserving awkward phrasing
|
|
- If a sentence can be misunderstood by a manager, stakeholder, or consumer team, rewrite it before sending
|
|
|
|
---
|
|
|
|
## Repeated Senior Communication Lessons
|
|
|
|
- Test in the closest real consumer environment first when consumer-specific behavior is under investigation, but use the sample app to rule ownership in or out quickly
|
|
- Before escalating or concluding root cause, reduce uncertainty with available evidence: screenshots, videos, logs, code comparison, version checks, and parity checks across web/UIKit/SwiftUI/Fid4
|
|
- Keep one issue per update unless a second issue is explicitly called out as separate scope
|
|
- If blocked, communicate what was tried, what was ruled out, and the exact remaining question
|
|
- Use Context, Observation, Action framing when possible so status is easy to forward without rewriting
|
|
|
|
---
|
|
|
|
## Avoid
|
|
|
|
- "same behavior"
|
|
- "looks good"
|
|
- "seems fixed"
|
|
- "working now"
|
|
- "it should be fine"
|
|
- "for some reason"
|
|
- "I think it's fixed" when evidence exists or is needed
|
|
|
|
Use concrete statements instead.
|