Add daily logs and templates for project fidelity
- Created daily log entries for May 13, 14, 18, 19, 20, and 21, capturing work done, findings, and next steps. - Established a daily logs index for easy navigation of daily notes. - Developed templates for daily logs, decisions, meeting notes, people, systems, and work items to standardize documentation. - Introduced base files for filtering and displaying various types of project knowledge, including daily notes, decisions, people, systems, work items, and workstreams. - Added maps for current work, fidelity apps, and fidelity domain to enhance project navigation and context.
This commit is contained in:
@@ -0,0 +1,78 @@
|
||||
---
|
||||
type: person
|
||||
project: fidelity
|
||||
role: manager
|
||||
status: active
|
||||
updated: 2026-04-17
|
||||
tags:
|
||||
- person
|
||||
- fidelity
|
||||
---
|
||||
# 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
|
||||
|
||||
1. Context
|
||||
2. Observation
|
||||
3. 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
|
||||
- When direct access is missing, Jeff may push for progress through adjacent evidence sources and support contacts instead of waiting on missing permissions
|
||||
- Jeff explicitly suggested using the Fidelity-approved AI tool with detailed local context, plus outreach to Aylwing / Tauf / Jeffrey O'Leary, during the April 20, 2026 REST / LaunchDarkly investigation
|
||||
Reference in New Issue
Block a user