# Engineering Team Syncs

## 6/20/23

- decision: **financial tipping**
- T2C
- **autoattribute (yes)**
- autoverification (high lift; can't do with tipping; heavier backend lift than frontend lift)
- frontend lift is higher (?)
- redis cache integration is the unknown (backend)
- this is the main consideration: how frontend would interact with redis cache
- hashtag management (not a huge impact)
- and **copy sweep**

JP order of ops
- validate sdk
- programmatically creating a split from frontend (1/2 of enable tip functionality)
- testing out send tip button
- allow listing certain coins to make sure they show up in the split
-

## 6/something


**Proposed Order**

**MVP Goals:**
1. enable tipping toggle on profile settings
2. **tip button on contribution details view**
3. total amount received (per user) shown somewhere
4. tip feed on contribution details view
5. surfacing total amount received per contribution (in contribution feed - or personal profile?)

**Value Add Stretch Goals:**
- anonymous tipping
- public personal profile
- As a user, I can share my public profile link to others and they can see my total tips received and given.
- Would I also be able to receive tips associated w my person not my contributions?
- dao leaderboard
- crosschain considerations

**Outstanding questions:**
- what is the withdrawal UX of OxSplits?
- currently any coin is able to be sent?
- when people enable tipping, we need to put a disclaimer modal
- crosschain questions
- currently only supporting gnosis
- we could potentially support polygon on someone's profile (not their contribution)
- swapping
- xdai, wxdai, weth ?

June 13:
- prod release schedule
- today + then follow up with the rest soon
- VF update for my contributions
- open ticket questions
- tipping

notes:
- our contribution table is getting busy
- how to show total amount across coins
- public v private

Priority Decisions:
## Bugs
- Eng-1128
- ask Stefen to do this with a different address
- Eng-1130
- contract sync job
- Flip added another bug

## Medium:

Contribution Details:
- Eng-1127 in PR review
- directionally aligned

Tweet to Contribute:
- test now with users handles

Account Creation:
- Eng-1119

Sharable links:
- request to attest (lower lift)
- directionally aligned
- account creation unblock
- invite to DAO (higher lift)
- this would require tech speccing
- current flow:
- admin sends someone link to dao dashboard
- prompt account login/creation
- questions:
- would ppl join as recruits or members?
- possible for admin to deprecate link?
- does the new flow streamline enough -- check after 1030 and 1119 are in

## No capacity for

integrations
- verification onchain
- which had implications for hats, dao masons
- disco
- v0 of crosschain
- daostar
- lol
- invite/join to dao link
- only makes sense if we want to prioritize dao level features

tipping & onchain verification -- biggest lift

- do we want to make it easier for daos to hand out responsibility/roles OR help contributors in single player mode get paid?
- building for dao v contributor
- is it better to service individual contributors or an entire network?

JP:
- as a contributor where state of DAOs is uncertain, would love a single place where my contributions are aggregated and get some sort of income
- less convinced that people will use our platform in the short term to help daos work

Stefen:
- would lean toward contributors

Aaron:
- the types of daos that exist now won't be the ones that exist in the future
- but it will be the same contributor
- 75% of online communities die

May 23:

- verification in more concrete terms
- to clarify: unblock programmatic issuances
- potentially relevant: daohaus, dao masons, hats,
- how to unblock integrations where people want to issue something based on verified contributions
- attestations are onchain; verified status is not
- do we need an onchain / ipfs indicator for verification?
- option 1: create a job to update status onchain
- big architecutral change
- private key associated w govrn
- whitelist the verifier to change contribution from unverified to verified
- get a signature / check from govrn verifier powered by our offchain framework
- moves the trust to govrn correctly evaluation verification status offchain
- attestation is onchain but computation and verifier is offchain and then gets updated onchain
- can expand this to different levels of verifiers with different levels of veracity
- could gradually move to more permissionless verifiers and are more transparent; could introduce onchain smart contract verifiers that evaluate the number of attestations a particular contribution has
- could have verification partners
- could get modular (smart contracts help with this + permisionless)
- we could incrementally move towards a fully onchain, permissionless approach
- questions:
- would we be able to update metadata?
- if you update the blob would need to update the uri?
- can't run onchain verification stuff with stuff that's on ipfs; can't access ipfs from a smart contract

- unblock amrro
- [ENG-1030](https://linear.app/govrn/issue/ENG-1030/improve-wallet-login-screen)
- eng coverage while JP is out
- out Wed-Fri
- won't have (much) service
- product release cadence?
- ideally would want to release Mon/Tues every other week (aka 2 days into a cycle)
- with ad hoc release in between if we have a high urgency bug fix in or several medium urgency fixes
- maybe revisit QA cadence
- doing a release this week?
- reassign or cancel keating's tickets
- [ENG-1045](https://linear.app/govrn/issue/ENG-1045/filter-out-system-logs-and-make-logs-more-readable#comment-953afaae)
- [ENG-695](https://linear.app/govrn/issue/ENG-695/csv-upload-consumer#comment-548877f2)

May 9:
- DAOStar
- discussing ENG-1068
- "do we want/need to access the database to get the other fields for the response, or do we only depend on ipfs"
- question:
- is it better to give them an api endpoint + or put everything on ipfs?
- does ipfs provide json-ld format?
- or is it because the ipfs data is incomplete?
- how would we update or migrate people who used the past schema?
- goal is to create a standard for generalized attestations for service providers
- we have an opionated approach about what is on/off chain so this format is a way to standardize how to publish data regardless of where it's stored
- If we want to create an open standard, going through our api seems antithetical https://discord.com/channels/837049837886767125/952687366303285348/1105544134980292740

- what to put on IPFS
- name, activity, proof
- Sync Jobs

May 2:
- PR scrum master
- notifications (is discord better) PR review channel in discord?
- re-approval cycle
- possibly making a thread in the protocol team for review
- decision:
- try rotating weekly role
- try PR thread or subchannel in protocol team
- QA schedule
- what we did before:
- thurs end of cycle wrap up
- merge to staging thurs/fri
- **Mon: staging QA**
- Wed/thurs: merge to prod (clear before next cycle)
- **Fri: QA on prod**
- QA times - updated
- Access to prod db?
- generate read/write keys
- NATS
- linear ticket for decision

decision log:

- Amrro working schedule
- M, T, W = 2.5 days
- and a 1/2 day for coverage responding/PR reviews on other days
- Flip started a discussion thread on NATS
- Flip, Amrro, JP, Christine to schedule engineering specific meeting
- Flip, Amrro, JP to share devops ownership and schedule a meeting w Keating on Thurs or Fri of next week
- Open question: Christine to ask team about pros/cons moving sprint planning to Wed

meeting notes:

- Amrro's working schedule starting May
- 3 days per week
- would prefer to work 3 full days, but does have some flexibility in terms of spreading time out
- might make sense for amrro to lead by a day for PR review
- proposing 2.5 days; + .5 days for responding
- meetings:
- engineering meeting
- any time after 9am pt
- sprint planning
- all hands
- Mon, Tues, Wed
- best form of communication
- @ in discord is good
- meet at least once a week
- Eng meeting structure
- would eng team want additional?
- move the standup time to be more compatible for amrro?
- Eng processes
- devops
- shared responsibility
- JP comfortable with all except migration piece
- next step: schedule a call with keating and prep documentation going forward
- Code review ownership & flow
- do we want to keep PR review standards
- QA and merging to prod cadence
- Who unblocks who
- NATS decision (if time, else push to next week)
- Keating recommending to shift toward a simpler solution, but to move ahead with anything in flight
- Use a db table instead of a NATS queue
- Pause and shift toward this as a short term solution
- Would open up Amrro's capacity
- Reworking this may take the same opportunity cost as becoming more familiar with NATS
- Prioririze whatever lets us ship as quickly as possible, if cost is the same we may want to stick with NATS
- Can summarize our progress and what is left to be completed. What's in flight:
- Guild import
- NATS server
- Requires more knowledge to secure this
- CSV uploads?
-