# v0 Verification Framework ### aka Github Accept | Project Plan ###### tags: `Project plan` [toc] ##### Related Links <!-- *add link to one pager (if one pager was done)* --> - [govrn.app](https://govrn.app/) ## 💡 Idea <!-- *The idea space is the bare minimum needed to communicate an idea and allow the submittor to present the idea during project planning.* --> ### Meme ![](https://hackmd.io/_uploads/B1e6pkB4o.png) ### tl;dr DAOs are going through progressive decentralization. They're not ready for automated contribution acceptances based on attestations. This would be to build a DAO Admin like functionality that allows DAO admins to "accept" contribution PRs to a DAO tree (like github). Attestations would operate like reviews given on a PR ## 🧭 Spec <!-- *The spec should provide a meeting space for all information needed for project kick off.* --> ### Goal <!-- *1-2 lines on What problem are you solving and a proposed solution. Bullet points are fine* Example: - Problem: It's hard to understand context on what to give attestations too. - Solution: Make the experience of going through contributions for attestations fun. - Objectve Alignment: What company objective does this project align with? --> - Problem: There is no UX flow to accept attestations from DAO members (at an admin level) - Contributors worry about giving attestations, this helps reduce pressure/friction. - Solution: Build an admin function, matching process, and an accept screen for bringing those in. - Objective Alignment: ### Scope Projected work: - Brainstorming: Creating our "ideal" process flow on how this would work - Design: Either an additional screen or module within the attestation feed - Additionally, if we're making changes to the Attestation and Contribution Screens, then we could roll in some general clean ups as well. - Engineer: Mainly focused on building the fontend components. Idealy we wouldn't need any primitive levele addtions, although somee backend relationships might have to be built. - Need to show the specific screen or flow based on the address membership. The attestaton is the same, but the specfic UX for this functionality is built around the membership flag - This also adds a status to a contribution of "request" for when someone pushes a contribution but it's not yet accepted. There are the following components: - Attributing contributions to a DAO (as an individual). - Providing reviews (attestations from non admins/non verification framework listed) - Accepting it to a DAO (Attestations given from the DAO Admin/Verification Framework) () ### Completion Criteria <!-- *What will the end result be?* Example: 1. Come up with 4 design options for a new attestation feed. 2. Implement them on the web app --> 1. A clickable Prototype to test out the new user flow 2. User Stories 3. Clarified Dependences on DAO Admin and DAO Membership Functionalty 4. A very rough MVP to test out the minimum flow into staging (or experimental version)(Feature flag for testing) Note: We're abiding by the ideas of *Progressive Decentralization* thesis. We are reaslistic about the current state of DAOs using Govrn for the first time and needing admins, but in our ideal state, the UX would be that **everyone** see themselves as admins. ### Timeline Brainstorm / UX Exploration: 1 week or less Design- prettifying: TBD Diana User Story Writing: onehour or less Total Time: 2 Weeks (Assuming no staging build) Process: - Async updates in the channel ## 📖 Bible <!-- *This is a general section to put any supporting meeting notes, documentation, etc that accumlates as the project goes on. Adding potential sections for illustrative purposes* --> ### Meeting Notes #### 11/2/2022 Sync - Contributions <> DAO should be bi-directional - When pushing a contribution to a DAO, DAOs would want to likely make this automatically accepted via a threshold, such as x attestations - From feedback, getting here is tricky so there is an admin functionality requested - Being able to “accept” user contributions - Can also reduce risk in the attestations - Won’t change much on the backend, but we’d be building a user flow and UI for a DAO to manage incoming contributions that are being attributed to them - **What problem are we solving with this?** - Based on feedback, mechanistic acceptance of contributions is more intimidating than we'd thought - Folks are wanting there to be more control as they gradually adopt Govrn (even in addition to setting up the acceptance framework) - Teams may likely be wanting more admin dashboard functionality such as this - There isn't currently a view that's the equivalent to the "Pull Requests" view in GitHub - Users unsure about what happens when they hit the attestation button -- not knowing what happens and want to know what the impact of the action is - Since verification frameworks aren't in place, we've been discussing the feature and this is the feedback we've received - Very much related to folks who are working through progressive decentralization - GitHub wraps git and adds Pull Requests idea -- this makes the concept much more straight forward: - Govrn protocol doesn't have concept of PRs, but the app can (similar to Git: GitHub) - Attestations from *non-verification wallet addresses* can be framed similarly to GitHub PR reviews - Whoever has the permission to 'merge' is the DAO Admin - This can relate to a future idea of a "Request Attestation" - Create a Contribution -> send to folks for review (Attestation) #### 11-15 UX chat Simple concentric circles of attribution 0. First Attribution 1. Verification 2. Second Side Attribution 3. Valuation ### Considerations - **Dependency** --> DAO Admin Functionality <-- - **Dependency** --> DAO Admin Value Framework <-- - Design audit and DAO membership pages give us a chance to add this feature in or slot before rolling them out. - Has to be staggered with DAO pages, we'll assume those will launch before. From that frame/page then we slate this in on parallel. #### Depedencies **DAO Membership** - The depedency is less on DAO Membership and more on a DAO Admin Flow - We need to be able to: - List addresses that are the whitelisted for the verification framework - Build a separate UI/UX for them - This might be related to DAO membership as far as "listing" DAO admins is. ### Open Concerns - Accept becomes part of contributions tree? - We don't have an accept module or flow or model or idea other than mental model of github. - Contribution feeds to dash, admin approves those contributions - in the app currently anyone in the DAO can do Cont <> attest they auto feed into attestations. - the concept is to give repo admin like functions. but we don't have DAO's set up like repos. - It makes sense at a reward level (verificaiton > rewards) - **could work like another table of accepted ones that are highlighted on a table.** - We need to vote on the impact of this feature, we missed the opportunity to break down from higher level down to the implementation pieces. - Implementation is tricky with framing attenstations framework: - Attestations verification is clear, attribution (adding contribution to a dao permissionlessly) needs framing a little bit more. - Framework of verified work becomes a mechanistic acceptance, like several github reviewers. - At an architecture level it hinges on the value of contribution. - Cannibalizes attestations a bit and distracts from that experience. Core problem is organic attestations not so much the control of them. - Maybe explore an Elevated attribution flow? ### 1-26 rough technical eval open concerns - how does member status fit in with this? - do we need notifications instead? ### Decisions Log Gonna go ahead and call this "verification framework." Admin addresses will go into a variant of a verification framework. simple version is 0.1; the other one is select number of addresses have admin flag. later they will have a multiplier in the verification flow/framework. this is a type of verification framework. We want to guide them towards control or no control, power users or not. - v0.0 a toggle or button on attestation itself that indicates "approve as admin" - show "admin voted on" this sticker on the contributions/attestations feed [DAO dashboard]. - Db entry would be ... - v0.1 (n) number of attestations for inclusion (core member set to start, but core is accepted for verification) - A module. - Multiplier for strength of attestations in the future (admins would have this) - Threshold would start at zero, but we could encourage using (1). - v 0.2 a module for admins that allows for approving contributions into DAO. this has more curation to it.