---
# System prepended metadata

title: 'Sam, JP, Jord'

---

# Sam, JP, Jord

## Onboarding

- How do we go through the process of onboarding folks?
- If we can get tickets ready, can we provide tickets to folks?
- Set the pattern in the library and then work directly with them to get onboarded and go from there

## Summoner App

- Start with our high level macros and break down from there
- Starting with the form and the user stories and go from there
- These would then point to components
- From the macros, we can identify the components
    - These forms are more difficult than what we've done before, so need to be more flexible
    - Need to improve the Form Builder to support more complex forms
    - Rebuld the form builder
    - Does this include the transaction builder? 
    - Can build on here -- would be a good test 
    - New formbuilder: pass in any sort of callback
    - Get to transaction builder when we get to Sage proposal form
    - Standardized process that included modals -- working on this for v3 would inform how we want to work on this in the future in our UI
- Start with the Summoner App
    - Break out the core components into this larger HausUI package
    - Extract the bigger components

### Components

- Accordion
    - Renderer inside that'll render the inputs inside
- Subform
- Double Column
- Toasts
- Connect Wallet
- Haus web3UI
    - Leverages our component library but contains more opinionated choices


## Notes and Next Steps

- Tickets for all inputs
- Tickets for macros: 
    - Accordion
    - Form Columns
- FormBuilder Rework Rage
    - Identify where things can go wrong?
    - Anticipate problems early on
- What are the names and uses of our patterns?
- As we're making the cards, we can outline our questions and then work with the design team to answer these questions
- Have alignment meetings at the onset
- Let's start naming things and use that as a starting point
- Here's the list of things, what are things we need?
    - Does this make sense?
- Our workflow and system needs to be established -- Sage is symbolic but this makes sense here
- Define from the card, and then ask questions
- Have them point to us in the pattern library, and if it doesn't exist they may need to rework a few things
- Do we want a second board for component library related things?

## Rage Report Templates

- Add in a *Future Notes*
- Keep open at first

- As a TypeScript type with fields on the object, what would be optional 
- This is then the first step in the Raging

- Required Fields:
    - Goals
    - Experiment Design
- Going through the Rage Report as the starting point for the actual experiment
    - Jord did this for the Polling Rage and found this helpful
    - Helps set the scope and planning for the Rage
    - Expected Results / Actual Results
        - Conditional?
            - Retrospective / Post Mortem
                - Doing an examination of these and outlining the challenges
        - Thoughts on why? Thoughts on why this is different as it makes sense
        - What did I have happen that was different, and why?
        - Ex: Read The Graph docs wrong, and then it was a different system they were recommending
    - Similar to a scientific study w/o all the rigor -- low quality study with actionable next steps
    - Next Steps / Conclusion
- Better to have a tighter format for retros and post mortems
    - Intentions are different
    - Retrospective / Post Mortem 
- Key Observations
    - if skimming the document
- We have trouble scoping our experiments, so this would be helpful to have the scope and include others in the journey
- One more test we should do is to say if something is extendable beyond developers?
    - Community Design Experiments
    - Sync up with the UX folks
    - Organizing and making use of things we make a public knowledge share