# R & D considerations for verification framework

## Clarified Compromise Proposal

### Feedback Loop
`taxonomy` = contributor guidelines (proactive)
`verification` = merge a PR/ DAO publicly accept a contribution (retrospective)
--> we can leverage both parts of this loop in parallel

### What is acceptance: private v public association

#### What
While any recruit or member can `privately` associate a contribution with a DAO, verification/acceptance unlocks `public` association of a contribution with a DAO

#### How
Implementation
- private association means a contribution makes it into the DAO's contribution feed
- public association means a contribution makes it into a specific (public?) view of the dashboard

#### Why

Acceptance/verification signals something

Hypothesis:
`Acceptance/Verification` signals that a DAO found a contribution `meaningful`.

Acceptance gives contributors feedback and props for their contributions and signals that they are a valuable contributor to their DAO.

This is the R & D hypothesis of criteria that verification/acceptance would be based on.
happened ✅ + accurately self-reported ✅ + relevant/valuable to the DAO ✅ = github accept
However, we want to see what users actually do!

### Proposal

1. Take a flexible interpretation of the `attestation` product feature
2. Gather insight on how users are deciding whether to attest to something or not
3. Improve proactive contributor guideline (taxonomy) features
4. (FUTURE) Leverage the feedback loop between taxonomy and verification/acceptance

#### Flexible interpretation of attestation
`attestation`: flexible interpretation
* the attestation function is already out in the wild, regardless of how our team wants to define the primitive
* hypotheses:
* flexible definition may allow for different contextual needs
* with pre-defined contribution types, attestations may focus more on truth and accuracy
* with emergent/new contribution types, attestations may focus more on relevance in addition to truth

#### Gather insight on how attestations are used
- [Consider enabling comments on attestation or where most appropriate](https://linear.app/govrn/issue/PRD-97/comment-on-attestation-screen) to learn how users are using attestations
- User testing
- Data analysis: see which contributions are attested to vs not
- Goal is to learn how thorough attestors are being: are they vetting every angle of an attestation, or just one? Would an accepted contribution be vetted robustly enough to be ready for value assignment?

#### Improve proactive contributor guideline (taxonomy) features
- [Organize drop down contribution type menu by DAO](https://linear.app/govrn/issue/ENG-546/organize-taxonomy-dropdown-by-dao-on-the-reporting-form)
- hypothesis: improved UX will shed light on what contribution types are meaningful to your DAO
- Help admins seed clear contribution types
- streamline DAO admin set up of initial taxonomy, perhaps leveraging `createDAO` flow or `DAO admin settings`
- (Future) [consider providing in-app contribution type templates for different types of DAOs](https://discord.com/channels/837049837886767125/841548547648389131/1073920977198653471)

### Leverage the feedback loop between taxonomy and verification/acceptance

Future potential: verification feedback can dynamically update canonical taxonomy
- If a new contribution type is verified/accepted a minimum number of times, perhaps it can be included in the canonical DAO taxonomy.
- And vice versa, if contribution types of a certain type keep getting rejected, perhaps that type can be removed from the canonical taxonomy.

### Next Steps

- [ ] verify consensus on the proposal (wrap up discovery)
- [ ] go to product development
- [ ] user experience
- [ ] product definition
- [ ] product design

Scratch pad notes on how we got here ⬇️

---

open question (future problem)
if a contribution reached acceptance, is it ready for reward
- my concern is that the flexible approach to attestation won't be robust enough to be ready for quantiative value assignment (reward)
- we can be receptive and keep an eye on this
- (truth) + (accuracy)= attestation
- (relevance) + (min quality) = accept

key with acceptance is eligibility
acceptance can make a contribution eligible for value

contributor burden of attestations
flexible approach is first line of defense

why do care about accept?
- "active/core contributors" if you've reached a minimum rate of verified contributions (binary reward) (v0)
- dao experiment --> weights --> (scalar reward) v1

- verification unlocks public association of a contribution with a DAO (github accept-- like the public repo page)
- DAO's public repo page is a specific view on the dashboard

taxonomy == contributor guidelines
verification == merge a PR (publicly accept the contribution)

There is a dependency between taxonomy (proactive contributor feedback) and verification (retroactive contributor feedback).

- proposal:
- take a flexible approach to how users will want to use the attestation function
- consider allowing comments on to capture insight on they're using attestation
- combine this with taxonomy features (proactive contributor guidelines)
- allowing admins to seed clear contribution types as part of the create dao flow
- fixing the activity type dropdown to show types for your specific DAO
- Future iterations: hover - DAO's explanation of the type

next touchpoint:
- verify concensus on the proposal (wrap up discovery)
- go to product definition (product development)
- user experience
- product definition
- product design

----

- dependencies
- would it make sense to tighten the taxonomy stuff first?
- create a dao
- empty default
- dao admins set predetermined types v1 of contributions
- taxonomy == contributor guidelines
- verification == merge a PR
- attestation
- not the primitive, the function in the product: usage will depend on if the contribution type was
- [ability to leave comments as a feature idea](https://linear.app/govrn/issue/PRD-97/comment-on-attestation-screen) could allow us to see how people are using attestation (user testing)
- wrong typology
- low quality
- not relevant
- false

taxonomy as contributor guidelines
- how DAO admins seed contribution types when setting up a DAO
- recommend common types
- make DAO's [contributor guidelines](https://linear.app/govrn/issue/ENG-546/make-a-taxonomy-filter-by-dao-on-the-reporting-form) more clear with the taxonomy filtered by DAO
- in the dropdown show common types in that DAO; have the order in the drop down menu mean something

### Fleshing out Different Options [WIP]

Soft concensus (??) on:
- happened ✅ + accurately self-reported ✅ + relevant/valuable to the DAO ✅ = github accept
- where github accept is a binary v0 of value assignment
- and accepted contributions are allowed to be shown in the public dashboard view

Note on taxonomy:
I've been thinking through how taxonomy plays into all of this, and think different options will be more relevant depending on how robust the DAO's taxonomy is. From a user standpoint, taxonomy and verification are both ways to help the user understand how to contribute to the DAO in a way the DAO will publicly accept and reward.

~~~
like if the DAO says "these contribution types are important" --> if you do that contribution type, it should be github accepted UNLESS you didn't actually do it accurately or truthfully

but if you're doing contributions that are emergent and not a type formally requested by the dao in the taxonomy, that's where relevance/value judgment is more important than the above scenario
~~~

For a DAO that has a clear taxonomy of requested contribution types, I would expect to get a github accept if I do that contribution type UNLESS

**Option 1:**
- verification = accuracy + truth + relevance
- verification = github accept
- implications:
- attestation function in the product would be used for all 3 at once

**Option 2:**
- verification = relevance (only)
- verification = github accept (but skipping the accuracy/truth check)
- implications:
- attestation function in the product would actually be used for value

**Option 3:**
- verification = accuracy + truth (only)
- verification in this case is the first step of github accept, so verification + value/relevance = github accept
- implications:
- verification would not complete github accept on it's own

**Option 4:**
- filter criteria set by admins to determine public view of contributions
- implications:
- may involve having an admin feed and a member feed
- may require public and wallet accessed Dashboard page

### Keating <> Aaron <> Christine sync 2/8/23

R & D Agenda

Meeting Goal: reach alignment on the definitions of `accept` `verification` and `attestation`

GitHub accept
- [ ] Accept / publicly associate with a DAO has to be based on some criteria
- Is this based on value, relevance, or meaning? (value allocation) OR accuracy/truth (attestation)?
- Potentially hot take: value allocation = github accept. Why not let attestation + value allocation run its course? Do we need a separate accept process, or can github accept be a binary v0 of value allocation?

keating:
- doesn't necessarily have strong opinions; understanding from one page history was that verification allows public association with a dao
- main reason to do that is based on the idea of github accept - merging a branch into a repo
- indicates that this was a contribution that relates to the dao (relevance)
- as a user, I want to publicly show "correct" contributions (based on attestation)

Aaron:
- can see "accepting to repo" being value assignment
- being able to dynamically accept what is in our repo
- being able to rank what is a real contribution or not

Attestation
- [ ] Verification was framed as receiving a minimum number of attestations.
- Are these attestations referring to our attestation primitives of: accuracy/truth?
- If actually about value, would still recommend incorporating attestation sof accuracy/truth

verification == min threshold attestations where attestation means validity (accuracy & truth & relevance & correctness)

make contribution to govrn
verified = accepted :
- need 3 attestations
- shows up in feed but isn't in dao dashboard

skip validity (attestation)

verification == meets attestation requirements
acceptance == value allocation (binary value indication)

dashboard -- filter what shows
- how many attestations
- if it was valuable

attribute -- any recruit or member
daos can filter what shows in their dashboard

Govrn has a dao dashboard
- aaron makes a contribution
- anyone is able to attribute/privately associate with the dao (report form --> contribution feed --> can get attestation primitives)

private associate w a dao v public one

github could mean filters on dao dashboard

v0

verified means -- accurate/true or valued/relevant

happened ✅ + accurately self-reported ✅ + relevant/valuable to the DAO ✅ = github accept is a binary of value assignment

scott and I are aligned on sequence
must assess truth/accuracy prior to assigning value

v0 - roll all 3 into one thing?

Aaron take on attestation: all 3

Keating take:
- filter criteria set by admins to determine public view of contributions
- potentially having two different feeds

verification mean relevance
later -- add a way to incorporate accuracy and truth

consistent with our use of language

### Conflating attestation and value allocation

Does verification mean:
- [ ] My contribution happened OR
- [ ] My contribution was valuable to the DAO?

The former is what R & D has been referring to as `attestation`: the idea that we want to gate against contributions that are `maliciously false` or `benignly inaccurate`.

The latter is what R & D has been referring to as value allocation. From what I can tell from the tech spec, a `verified checkmark` would indicate binary value. Yes it was valuable to the DAO, or no it wasn't.

If verification frameworks is trying to address value, then it is actually a v0 of `value allocation` which means
- [ ] R & D and product need to align on v0 value proposal, incorporating R & D's current proposal to partner with DAOs on value experimentation
- [ ] We still need to address if and how to verify that a contribution happened and was accurately reported

### What I would propose from an R & D standpoint

I strongly recommend that `verification` simply indicate that
- [ ] The contribution happened.
- Most relevant for malicious fake contributions.
- [ ] The contribution was accurately self-reported.
- Most relevant for benign confusion or oversight.
- e.g. wrong date, misleading activity type

Once a contribution has been verified, it can now be eligible for value allocation.

### Other clarifying questions

Setting aside the points about conflating attestation and value, some separate clarification questions:

- How is the team defining:
- "associating a contribution with a DAO"
- Are we proposing gating contributions from showing up in the DAO contribution feed? If so, isn't this a chicken and the egg problem?
- "accepting" a contribution into the DAO
- the dao approves for going into value assignment?
- the dao approves it showing in the feed for all members to see?
- What types of spam should verification frameworks address?
- contributions that are false?
- contributions that are not valuable?

### Notes from sync with Tim & Scott 2/7/23
- potential things that are soft value allocation are tagged in the tech spec doc

verified that it happened

"accepted to dao" is confusing language

github
- min # reviewers - verification framework
- accepted --> merged canonical
- accept the contribution to where?
- the feed?
- to the contribution graph?
- to the dashboard?
- to the value assignment eligibility ethers?

timing??

verification --> attestations --> can only be given to minted contributions --> verification can only happen on minted contributions?

accepted means "the dao said the contribution happened/was accurately reported"

stage contribution --> receive attestation --> edit contribution

attestations can only be given to minted contributions (currently - but there are other solutions)

potentially not allowing someone to attribute a contribution to a DAO until they receive verification (minimum )

--> shows in dao's feed

redundancy of gating

contributions need to show up in the feed in order to receive attestation and value assignment

report a contribution --> attribute to a dao --> it shows up in the dao's feed --> dao members can attest --> once a min number of attestations are reach it is verified --> once verified it is eligible for val assignment

is there a reason we might want to gate contributions being assigned to a dao?
- we may want to allow admins to prevent contributions from showing up in the feed
- we could see a use case for leveraging recruit v member -- maybe a dao only lets members attribute contributions but recruits are lower trust

two feeds? seems complicated
- admin feed
- dao attest members

It can't be valuable if it wasn't verified. But just because it was verified, doesn't mean it was valuable.

- any recruit or member can associate a contribution with a dao
- it goes to the feed
- dao has a framework to verify that the contribution happened and was accurately reported (attestation)
- if verified, it can be eligible for value allocation

if individual members are spamming, restrict their access

"not being accepted" just means "minimum of attestations was not reached" (which can be updated)

---
## Output of Tim/Scott/Christine sync 2/7/23

Verification means:
- [ ] The contribution happened.
- Most relevant for malicious fake contributions.
- [ ] The contribution was accurately self-reported.
- Most relevant for benign confusion or oversight.
- e.g. wrong date, misleading activity type

Once a contribution is verified, it is eligible for val assignment. But just because a contribution was verified, does not mean it will be deemed valuable.