Commit e2d789f2 authored by Bogdan Vacaliuc's avatar Bogdan Vacaliuc
Browse files

prompt 1.4 and 1.5, for the weekend

parent 617c4a40
Loading
Loading
Loading
Loading
+51 −0
Original line number Diff line number Diff line
@@ -88,3 +88,54 @@ Regarding LR_reduction_workflow_config_parameters.xlsx, I have downloaded it to

Please read ~/Desktop/Hack-A-Thon-2026/2026-04-24-Files.md. Please use that information to summarise the Day 3 events and write them to tasking/Hack-A-Thon-2026-Day3-Summary.md for me to review. If there is any other information that you would like to have, please ask me.

### Prompt 1.4

I went ahead and made edits on commit 617c4a40. Thanks, alot! Erik attended when he could - I may not have captured his comments complete in the hand notes. There were also several discussions running concurrently at times. Anyway, what do you propose to do for '4. "Claude estiamte?". You have the git log from the quicknxs and mr_reduction repositories - that represents actual developer effort and progress. What is missing is when the developer actually started paying attention to the task; they may have taken a branch and unless they were dilligent it creating a development branch at the start of attention, the creation of the branch may represent a fairly noisy starting point. I have a spreadsheet, however, that extracts data from the work management system (the EWM system). You may inspect it at ~/Desktop/Hack-A-Thon-2026/Focus-REF-Work-2026-04-25.xlsx, in case it provides some clarify. I apologize for the circular reference warning - it has been troubling me for some time.

```
Quick read of the EWM file: the Resolved-REF-Work-2026-04-25 tab has 1,076 completed work items with Estimate, Corrected Estimate,
  Time Spent, Creation Date, and Resolution Date for each, and the Focus tab even has placeholder per-developer time-budget tasks      
  ("Glass Time / Kevin Time / Marie Time") that read off available capacity per cycle. That's enough to do this empirically rather than
   by gut.
                                                                                                                                       
  Here's what I propose, in three phases — pick the depth you want:

  Phase 1 — empirical baseline (≈30 min, no commitment).
  Aggregate the 1,076 Resolved items by Type (Task / Story / Defect / Release) and by a coarse work-class derived from Summary keywords
   (refactor, cleanup, test, new-feature, review, release), and produce three numbers per class: median Time Spent, p80 Time Spent, and
   the median Time Spent / Estimate ratio (the "estimation honesty" factor — how much developers under-quote). Output: a one-page table
   you can sanity-check.

  Phase 2 — map the Day-3 backlog onto Phase-1 distributions (≈1–2 hrs).
  Take the 14 tech-debt bullets (Day 3 Consensus #6) and the 14-row migration table (Consensus #7), classify each into one of the
  Phase-1 work-classes by hand (with a note for each), multiply by median + p80. Roll up to a total-hours figure with a band, and
  divide by the per-developer weekly capacity I can read off the Focus sheet → calendar-time band. Output: a per-item ledger plus a
  summary chart.

  Phase 3 — cross-validate against git (≈1–2 hrs).
  For each Resolved item that names a PR (the Summary often does — e.g. "Review QuickNXS PR 229"), check the actual PR merge date
  against the EWM Resolution Date in quicknxs and mr_reduction. The gap between EWM Creation Date → first commit on the relevant branch
   is the attention-lag you flagged; the gap between first commit → PR merge is the focused work. Empirical attention-lag ratio
  multiplies our calendar bands. Output: a one-paragraph calibration of how much git-derived calendar time over- or under-counts
  focused effort, applied back to the Phase 2 numbers.

  Two things I'd want before kicking off Phase 1:

  1. Local clones of the two repos (or paths to them on disk) for Phase 3. The summaries reference them by name but I haven't seen them
   locally.
  2. Confirmation that I should write Phase 1's output as tasking/Hack-A-Thon-2026-EWM-Estimation-Baseline.md (or wherever you want it
  to live). I assume not as a committed deliverable until you've reviewed.

  The circular-reference warning in the spreadsheet is not load-bearing for this analysis — I'm reading raw cells, not the summary
  formulas. I see the Excel iterative-calc flag set, but Phase 1 would extract data with Python and not touch the formulas, so the
  circular won't bite us.

  If you'd rather, I can run Phase 1 immediately as a fixed-scope demo (the empirical baseline) and let you decide on Phases 2 and 3
  afterwards. Or, if you want a single-pass deliverable, I can do all three in one go and ask you about the repo paths first.
```

### Prompt 1.5

Ok, Regarding 1. I cloned them in the parent at quicknxsv2/ and mr_reduction/ respectively. Re: 2. Yes, you may write into          
  tasking/Hack-A-Thon-2026-EWM-Estimation-Baseline.md. Go ahead and work on all three phases. I'll leave the computer at my office     
  and head home for the weekend. Having something to review Monday morning would be lovely! Thank you so much!!