# 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