---
# System prepended metadata

title: TDP Internal Prod/UX/Dev Sync

---

# TDP Internal Prod/UX/Dev Sync

## August 7th, 2023
- **Tickets**
- **Onboarding**
- **Sprint 79 priorities**
    - SDP
    - Onboarding
    - Regional Staff Research
    - RFI research re: new data requirements



## June 26th, 2023
-    2559 copy / internal review
-    Onboarding
    -    Any further communication from CO / ND scenario?
        -    No response yet






## April 24th, 2023
Coverage discussion:
- 01 May - 05 May: Connor Out
- 05 May - 10 May: Miles Out

Sprint 71 Release:
-    Any updates to FAQs/KC we want to pull in?
-    Add as standing item in UX Sync, can be ~20 second discussion

Sprint 72:
-    Goals


## April 21st, 2023
- Talk through slicing developments on data submission emails
    - Likely two dev tickets we could spin out
    - https://app.mural.co/t/raft2792/m/raft2792/1670442812740/df177d3bb67bd1a9921614d0261a1abb15214bc5?wid=0-1682096681687

## April 17th, 2023
* Knowledge Center Videos
    * Requesting Access
    * Submitting Data
* Errors/transmission reports - automated solution, pull ahead or into v3.3
    * Alex brought up concern wrt mapping out Yun's workflow, data requirements and if we may be missing functionality - can we fit a user journey/requirements component into the research session?
* UX Sync agenda
* Delivery for this sprint / next sprint goals

## April 3rd, 2023
- CSV clarifications / errors messaging discussion with Andrew
    - ID (basically error #? in csv error list?)
        - Self reference for model object — backend
    - Row number (Row in flat file?)
        - Line # (in flat file)
    - Column number (Character in row in flat file?)
        - :heavy_check_mark: 
    - Item number (refers to primary item # in error description?)
        - :heavy_check_mark: 
    - Field name (plain language item number?)
        - :heavy_check_mark: 
    - Category (error category?)
        - :heavy_check_mark: 
    - Error Message (Description of error following style guide?)
        - :heavy_check_mark: 
    - Error Type (plain language error category?)
        - :heavy_check_mark: 
    - Case Number
    - Reporting Month
    - Object ID (?case number?)
        - ?????? Something but doesn't seem to be case # / month. 
        - Individual fields for Case # and Month still scoped but maybe not depicted in screenshot. Month may not be implemented yet in plain language (rather as integer)
        - Everything after this = backend
        - .................................
    - Created at (meaning data error was found at this time?)
        - 
    - Fields json (just a print of all this as json?)
    - File (File name? location?)
    - Content_type (varies by error category / error message?)
- Feasibility / scope of removing columns from the CSV users will ultimately receive? 
    - Feasibility / scope of producing an excel file instead and hiding the columns rather than removing the data from the file?

- High level research questions for transparency into what we're pursuing with "csv research"
    - Can folks open csv's? 
    - Does the information about errors get lost in the noise?
    - Is there a more minimalist version of the csv that puts the information users need front and center? #ABTest
    - Is the lack of a heading with information about which data you're viewing an error report for problematic?
        - 1122 implements this in file name
        - Including a description type column would be extra (but light lift)
    - Given the above, is the csv format of error report viable as a user-MVP?
* [1336 - Content, implementation (p/user to sys admin vs p/day roll up of all new requests to sys admin)](https://app.zenhub.com/workspaces/sprint-board-5f18ab06dfd91c000f7e682e/issues/gh/raft-tech/tanf-app/1336) - To be covered in Django sync later in week via UX
* Pilot Program participant tracker updates
* KC Video Status
* UX Sync agenda
* UX Roadmap, high level discussion