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.
3.4 KiB
3.4 KiB
type, project, role, status, updated, tags
| type | project | role | status | updated | tags | ||
|---|---|---|---|---|---|---|---|
| person | fidelity | manager | active | 2026-04-17 |
|
Jeff DeWitte
Role
Current direct manager for the active Fidelity project.
Historical Collaboration Pattern
- Repeatedly acted as reporting manager, reviewer, and communication gatekeeper across multi-year XFlow work
- Frequently rewrote PR descriptions, Jira updates, and cross-team messages before they were sent
- Regularly redirected work based on release risk, consumer pressure, or manager/stakeholder expectations
- Often pushed for explicit distinction between framework bugs, consumer bugs, service issues, and scope creep
- Acts as the main communication bridge into the Fidelity-side Teams context while David works from the All-Win Software side
Communication Requirements
- Native US English
- Prefers clear, concise updates
- Needs accurate scope, not vague reassurance
- Frequently asks for precise reproducibility, auth context, and regression scope
What Good Updates Include
- Context
- Observation
- Action
Good updates usually clarify:
- what issue or task is being discussed
- whether the behavior is reproducible
- whether auth state matters
- whether this looks like an external issue or a regression
- what the next step is
Influence On Work
- Story titles, points, and scope discussions with Jeff are often worth remembering
- Jeff approvals can change what belongs in current state or work-item memory
- Jeff feedback is often a signal to tighten wording before communicating externally
- Jeff often asks for evidence, reproduction detail, and exact next action before approving external communication
- If a draft is still ambiguous, Jeff may prefer to rewrite it directly so the external version is unambiguous and does not generate avoidable follow-up
- Jeff is often the person who reports progress or status into the Fidelity-facing context after David advances the implementation or investigation work
Repeated Coaching / Expectations
- Test in the closest real consumer environment first when the issue is consumer-specific; use sample app mainly to rule ownership in or out
- Do not open or socialize a PR as "ready" until the issue is fully resolved and no obvious follow-up bug has been introduced
- Separate current-ticket scope from unrelated preexisting bugs; do not blur them in standups or status updates
- Be explicit about environment, branch/build/version, account, flow entry point, and repro steps before concluding where a bug belongs
- When blocked, keep reducing uncertainty with other available evidence sources instead of waiting passively
- Fast admin/process actions matter: update Jira/status/comments promptly when others are visibly waiting on them
- Prefer evidence-heavy communication: screenshots, videos, exact error text, branch/version, and direct comparisons to main/web/UIKit/Fid4 when relevant
- Use polished native-sounding English for external-facing comments; avoid sending rough wording when a cleaner version is easy to produce
- When a consumer issue may actually belong to another team/framework, document the finding clearly and route ownership instead of carrying it indefinitely in XFlow
- For cross-team status messages, make the sequence of events extremely explicit so the reader can tell what was the original issue, what changed, what XFlow changed, and what remains a separate service-side issue