--- tags: Request For Proposal --- # RFP Negotiations Kick Off / Retrospective ![](https://i.imgur.com/GN2rzXC.jpg) [Link to the spreadsheet](https://docs.google.com/spreadsheets/d/1CDHo8oBSlDv72d4RFGHUbneiKB_yRMkZodvhriN3l1g/edit#gid=0) ### Intro / General Meeting Notes - Process was pretty quick - Skimmed a lot of details - Lots of interesting aspects to conviction voting - Higher token counts had more skin in the game, were more DAO-focused. Many focused self-interestedly. - Mixed feelings about the process - Can't rearrange or take away votes - A move in the right direction - Needs more time/space for RFPs to be visible - Would be great to gather multiple proposals - RFP vs the proposal response got a little messy - The RFPs became an excuse for someone to submit a proposal. They ended up being quite specific. Pros and cons: - Specific that the proposal was exactly rhe same as the RFP. We effectively didn't require the RFP - We had 3 layers of information: - Objective importance - Individually/collectively created RFPs that took signal from the objectives and turned them into specific actions - Proposals were even more specific - If we can merge the first two, we might approach a better place where the RFPs are more reflective of what we want to accomplish as a DAO - We might avoid RFP overlap, to clarify when proposals are overlapping, should be merged or divided, etc. - Perhaps more moving parts than necessary - Overall a very positive experience - We went into the exercise knowing what we wanted via the prioritization survey - Practically, could not edit the tokenlog after submission - Weighted/conviction voting felt like the appropriate style of voting for this process - Reiterating many of the sentiment already stated - Very uncertain about the results and how the RFPs will come together, but optimistic --- ### Overlaps *Where do we observe overlaps and potentials for collaboration? We want to manage redundant work and prioritize for efficiency. There is an opportunity to form collaborations and open communication.* #### DevRel + Core Strategy: - partnerships of CS - it may be difficult to tell how partnerships amounts to resources coming in to the DAO or an opportunity for others to build on our tools - some hand-off will take place between the workstreams - propose that those teams have a weekly meeting to sync and knowledge share - CS is focused on sense-making and aligning across work streams #### Content + Brand Awareness #### Webpage + DevRel docs + V3 Docs (of product team) - dev docs come out of the product sprint, plus the static webpage, docs in general seems like overlap - we're open source an dogfooding, so everything is public facing especially in relation to code - what is the purpose of keeping the docs team separate? seems to make sense to consolidate anything facing towards developers, especially v3 - we should slash the notion of internal vs. external docs, assuming product is internal facing and DevRel is public facing. Does this distinction exist? - migrate all docs to one hub: input of community developers mingles with core resulting in content - **Fishbowl**: do we need to balance/redistro budget or is there an opportunity for collab here? - Time allocation consists of preparation, meeting, presentation - If DevRel remains a big priority, we should continue to emphasize building in public - **Webpage**: who is going to build it? - Convo seems to be hung on a few key points of copy - Needs to be shipped ASAP, before next month - Should definitely include V3 updates - Probably needs more syncing to converge on scope - Might need to be restrategized - *When we define project scope so specifically into bucket we run the risk of initiatives becoming siloed.* In this initiative, pertaining to brand identity and carefully crafted copy, we need to decide how to intentionally created these interface points. - Should treat this content creation similairly to how we are developing the product - We need to be explicit with how this links up with other initiatives: docs, etc. - Copy needs to reflect target users #### AI Content Production + Brand Awareness + Rangers Ho! - good experiment to see what we can automate with docs, since AI is coming and this is inevitable - might stuggle with a product that hasn't yet been made, since it's indexed by google (everything on the internet) - there's a difference between polished articles with clarity and the scribled dev notes of active development - GPT-3 might be a good starting point for precise punchy copy, but needs to be tempered by a human agent (TW) - generally positive sentiment, but still some overlap concerns with other content writing initiatives #### Grants - good creative solution, but comp needs to be tweaked. percentage needs to be lowered --- ### Action Items / Opportunities - DevRel + Core Strategy should sync to clarify overlaps - DevRel + Product should sync - Product needs to articulate a roadmap - Webpage + Core Strategy should sync - Product + Core Strategy should sync - AI content + Rangers Ho! + Brand Awareness should sync on copy specs - Can this all happen in one large meeting? There's something to be said for multiple small meetings. Alternatively, we define an output for collaboration and leave it to the team to autonomously coordinate amongst each other --- ### HAUS Overage - We are currently at 7k HAUS over our budget. How do we want to handle this? - It's nice to get more HAUS into the hands of core contributors/Warcampers! - Why do we want to decrease HAUS ask? - Dumping a bunch of HAUS now will create selling pressure later - The current HAUS price that we are currently distributing is based on a low liquidity price. Any large purchase would massively increase this price, except we are receiving from UH not the LPDAO. We only have the one instrument (LPDAO) to gauge current HAUS value. If HAUS is undervalued due to liquidity and recent value, then what instrument do we turn to to gause value moving forward? - The HAUS budget is admittedly rather arbitrary ("magic numbers"). We should dedicate to being explicit on the reasons to reduce distribution. - Our survival is currently threatened. If we can help alleviate this threat by throwing HAUS at it, then that seems good. This is only successful if the people we give HAUS to continue to believe that HAUS will be valuable (not drop to zero) in the future, so it is appropriate to reward them with a relatively large amount of HAUS. However, the more HAUS we distribute, the greater the chance that the value will be low in the future. We need to balance these two forces. Also, the other way we could address our problems is to *sell HAUS for cash*. We should be dedicated to maintaining enough HAUS in the UH treasury to keep this option open, if we discover such an opportunity. - We are distributing **more** HAUS than contributors originally said they needed, with apprx the same amount of DAI. We should consider how much HAUS we are distributing if these initiatives continue for 6 months - 6 months = ~97k HAUS - just under 10% total supply - just under 25% supply remaining in treasury - The DAI/HAUS budget were the guidelines that people referenced to submit proposals. We might not need to keep to these limits in a strict manner. Changing the HAUS budget now is a separate discussion, not part of the process softly set out before.