--- title: DAOhaus Docs Master Document --- # DAOhaus Docs Master Document > Document Structure > * Section A. TODOs: This section tracks our to-dos and implementation progress (For > most up-to-date progress tracking, refer here) > * Section 1-4s: This section tracks the thought processes and frameworks which > underpin the implementation (For thought process, strategy & iterations, refer here) > * FigJam diagrams: https://www.figma.com/file/6Db3ougaCloXPyYkBhraj8/DAOHaus-Docs-Scratchpad --- ## A. TODOs ### ✏️ Current Focus - Week of XX - [ ] Bau - **Contributor Guide: Create a [tutorial guide](https://hackmd.io/gWf_XR4KTBypmzewH5zglA?both)** - [ ] ____ - **Add bots section to Discord section** - [ ] Travis - Complete rest of Github issues - [ ] ____ - Work on "Who We Are" section - [ ] Amos - Improve documentation on [Bootstrapping Other Networks](https://hackmd.io/Wl1dXv07QE-4zVa_ccgLKA) ### 🔎 Next to Pick Up (After Dogfooding) - [ ] ____ - Incentives for DAOhaus contributors - [ ] Recruit more community members to start knocking issues off - [ ] Pilot Clickup workflows (triage & sorting) - [ ] Improve documentation on Boosts - [ ] Improve documentation on Minions ### 💡 Longer-term tasks - [ ] Add search functionality - [ ] Set up a test DAO - [ ] Preview for Staging branch (Check with JonathanP) - [ ] Revisit future overlaps between Summoners' Handbook & Summoners-related tutorials & FAQ in user docs - Currently, all FAQs & howTos should go into Users. Handbook only holds Summon a DAO tutorial & UberHaus-related questions. Once overlap is more unclear, we'll revisit the organisation of information - [ ] Create a Clickup form on DAOhaus website that add issues to Github Issues (Ready for Triage) - [ ] v2: "This document is outdated" button to indicate documentation gaps - [ ] v2: Discord bot to raise or manage Github issues within Discord - [ ] v2: Netlify CMS for non-tech contributors ### ✅ DONE - [x] Amos - Update Members, Proposals FAQ from Discord - [x] Amos - Update Bank, Minion & Boosts - [x] Amos - Add other Discord issues to Github Issues - [x] Commence dog-fooding by clearing existing Github issues! - [x] Update process / Contributor Guide from [Travis' feedback](https://hackmd.io/PWY2L0tVS4mhbxldlsEbUg) - [x] *Pre Get Started: Why are these docs important? Tooling? Process? - [x] *Contributor Guide: Add daohaus-website link to "daohaus-website repo" - [x] **Contributor Guide: Add steps to sync changes / clone forked repository / add tutorials to contribute** -> Added FreeCodeCamp tutorial instead - [x] Contributor Guide: Commit guide - [x] Contributor Guide: Changes to branch naming convention & how to contribute to docs - [x] *Contributor Guide: Where to make changes? - [x] GH Issue: Add next steps (+ share on Discord) within the Issue - [x] GH Issue: Contributors to comment on the issue they're taking - [x] GH Issue: Change naming convention to edit/feature-19 - [x] GH Issue: Add more explanation on steps & help required - [x] GH Issue: Remove relevant flows unless it's screenshots / tutorials - [x] Make the Get Started for Contributors more general - [x] *Move the writing stuff to Contributors Guide - [x] *Add in different ways Contributors can help out - [x] Re: Code conflicts, each Github issue should be a batched set of 5 Q&As on 1 page - [x] Remove subsection & document from Github issues format to reduce information overload - [x] Move conversation over to DAOhaus - [x] Jonathanp: Organise branches based on features (e.g. feature/add-modal) - [X] Update Contributor's Guide on: - [X] New documentation structure - [X] Branching convention: feature/ID - [X] PR sizes: 5 issues per PR (via issues batching; milestones KIV) - [x] Bau: Provide more hackmd guides on Contributor's Guide - [ ] --- - [X] Add Contributor Guide to Docusaurus - [x] Split "HowTo"s into a Handbook section for tutorials - [x] Create another DAO persona within the documentation framework - [x] Create FAQ section for DAOhaus docs - [x] Finalise feature set taxonomy for documentation & handbook - [x] Create first 10 tasks for FAQs section - [x] Create Github Project - [x] Kanban board on Github Projects to reflect the actual steps in the process - [x] Complete Contributor Guide / Style Guide (can send to Jeremy to test it out) --- ## 1. Overview & Context | Cause | Implication | Objective / Action | | -------- | -------- | -------- | | **Discord support channel exports** | As we kickstart the new initiative to export & extract data from Discord, we have new insights on: (1) Who are our users? (2) What questions / issues they face? (3) **How do we improve our documentation / product?** | **A. Improve our documentation, so all DAOhaus users can find help in the shortest time** | | **Discord Reboot** | As we work towards greater community participation & decentralisation, we should have **more potential contributors** that can help out in DAOhaus| **B. Create a straightforward & decentralised system for contributions to documentation**| ## 2. Objectives (Why?) **A. Improve our documentation, so all DAOhaus users can find help in the shortest time** This is important because current documentation framework works for a simple product, and a small internal team maintaining it but might not work given DAOhaus' increasing complexity and desire for community support / decentralisation. As a result, we rarely see the documentation being referred to in the support channel, relying on the Devs to do most of the support. If we were to improve the documentation, this would help: | Persona | Benefit | | ------------------------ | -------------------------------------------------------------------------------------------------------------------- | | New / existing summoners | **Get help quickly for more DAO activity** by self-serve on docs, or by non-dev community support | | DAOhaus devs | **Minimise time spent on basic questions** that could be answered by self-serve on docs, or by non-dev community support | | Contributors | **Enable contributors to easily do community support for basic questions** if we have a scalable documentation framework | **B. Create a straightforward & decentralised system for contributions to documentation** To support the Discord reboot and commnuity participation, we'll need to help potential contributors know how and what they can contribute. This would require clear documentation framework as well as a task management flow / process. --- ## 2. Intiatives (What & How?) In order to achieve both objectives above, I propose the following items: 1. Documentation **framework refresh** - clearer structure on what information should go where 2. Task management **process** - after establishing structure, we create a process for people to make changes in adherence to it 3. Task management **software** - after establishing process, we use software to enforce & improve the process ### 3.1 Documentation framework refresh The current documentation for users is organised into the four following section: 1. Intro 2. Basics 3. HowTo 4. Uberhaus While informative, there are some overlaps in the content involved in each section, causing some difficulties in trying to associate questions to sections within the documentation. A clear documentation framework (what goes where?) would enable users to self-serve and find help quickly, support contributors to supplement their Discord support with docs, and documentation contributors to edit and update docs easily. As such, to reduce the overlaps in the documentation, I would organise the framework based on the user persona and subject matter in the documentation. After a deeper look, I realised that tat information can be organised in the following ways: 1. **Dev / Non-dev** 2. **Intent** (e.g. general explainer? how-to/tutorials?) 3. **Persona** (e.g. various product features) 4. **Content** (i.e. Explainer / tutorial sorted by feature sets) From the above, I created the following framework <!--![](https://i.imgur.com/eZLE5vW.png)--> ![](https://i.imgur.com/t63VXTL.png) **Handbook vs Documentation** For the non-Dev documentation, we first split the content into general documentation vs handbook as users who are looking to solve a problem (looking for tutorials & FAQ) will be different from those who are here to learn generally (looking for explainers or general docs). Hence, the documentation will consist of general feature explainers for each DAOhaus feature set, whereas the handbook will consist of tutorials and FAQs. For better organisation, the taxonomy / way feature sets are organised in documentation should be used in the Handbooks as well. **2 Handbooks - Summoner vs Member** Within the Handbook, we have 2 personas (Summoners & Members) because the depth of expertise and queries would be very different. **Within Handbook - HowTos, Getting Started & FAQs** Within each Handbook (regardless of personas), there will be HowTos and FAQs (sorted based on the taxonomy used in documentation). Within the HowTos, we will have one unique HowTo which is the "Getting Started", as a catch-all to ultimate beginners. With the above structure, it should be clearer for DAOhaus community members and users to self-serve and find what they need in the relevant sections. Also, it will be clearer what information goes where, so that contributors can start contributing. | Persona | DAOhaus User | Relevant Section | Sub-section | | ------------------- | ------------ | ---------------- | ----------- | | General "Scholar" | No | Documentation | General | | New "Summoner" | Yes | Summoner Handbook | Getting Started | | Existing "Summoner" | Yes | Summoner Handbook | HowTos/FAQ | | General DAOMember | Yes | Member Handbook | HowTos/FAQ | <!-- Archived Diagram v1 ![](https://i.imgur.com/iDa1DHW.png) For clearer comparison from current documentation, | Factor | Changes | Rationale | | ------ | ------------ | --------- | | User Persona | **No change** (user / dev docs) | Good split of content & questions (dev vs non-dev) | | Experience level | **3 sections (Getting Started, Product Features, FAQ) for pre-summon beginner, post-beginner and miscellaneous / advanced** | Easier to know which section to add / update which content or query | | Subject matter | **Only Product features & FAQ section is organised by product features** | Getting Started section should be rather static, focused on helping users summon a DAO| | Content Type | **Getting Started & Product features section to have 2 sub-sections (About & HowTo)** | Split content into general explanation as well as tutorials, so users can dive in where necessary. FAQs section doesn't need this as it is more Q&A | This way the documentation should have 3 main sections, cascading into the further sub-sections: 1. Getting Started * What is DAOhaus? (i.e. about feature) * Summon a DAO (i.e. tutorial / HowTo) 3. Product Features * Feature 1 (e.g. Proposal Types) * About Proposal Types (i.e. about feature) * Start a Funding Proposal (i.e. tutorial / HowTo) * Feature 2 ... 5. FAQs * Feature 1 * FAQ 1 Each section corresponds to a different experience level and complexity of features. This creates interesting implications to the frequency and nature of updates, as well as who should contribute to these sections (cutting into process a little bit) | Section | Experience Level | Frequency of Updates | Contributor Persona | | ------- | ---------------- | -------------------- | --- | | Getting Started | Pre-Summon | Lowest (every few months~) | Contributors | | Product Features | Broad range | With every major product feature release (every 2 weeks~) | DAOhaus internal (Since we have the most details on how features work) | | FAQs | Broad range | Highest (adhoc to 2 weeks~) | Contributors (Simple Q&A tasks that can start from GSheet) | --> With that out of the way, the next uncertainty we need to solve is how to coordinate and get them started. ### 3.2 Task management process To get them started, we will need to create a few things: **1. Process: How to contribute?** ![](https://i.imgur.com/jjGCM0O.png) For contributor-facing purposes, I am thinking we just use 1 platform to manage these issues. For now, it seems like Github issues is the one, since we can approve / update the docs directly and show open tasks for community members. **For documentation mods, our role would be to:** * Create tasks on Github as we see fit (general feedback / support channel) * Check new documentation improvements on accuracy & adherence to style guide * Approve for contributors to submit PRs * Approve PRs * Perform monthly / quarterly QC checks to ensure the documentation is not getting out of shape **For contributors, their role would be to:** * Find issues on Github Issues * Comment their proposal * Submit PR when approved **2. Style Guide & Documentation Manual: Dos & Don'ts** The idea here is to have a document to explain to new contributors * Style guide * General process for documentation **3. Quality Control: How to uphold quality & shape the future of our documentation?** The idea here is to have a monthly / quarterly grooming session to ensure the structure and content of the documentation still fits the stage where DAOhaus is at. ### 3.3 Task management software To start off something simple, since Github can control the approval of documentation updates, as well as a provide a public issues list, **I would suggest we use Github first.** As we onboard new contributors and understand what works or doesn't, then we can look at whether we need another software for this. <!--Process optimisation ideas Option A: Do triage, grouping, specs and display issues within Github Issues Option B: Do triage, grouping and specs within ClickUp and only display issues in Github Issues Option A is a simple process that allows the triage, grouping of requests, specs and display of issues within 1 tool. However, there are 2 downsides --> ## 4. Implementation Plan (How & When?) | Phase | Goal | Docs Framework | Process | Software | Timeline | | ----- | ----------------------------------------------------------------- | -------------------------------------------------------------------------------- | ---------------------------------------------- | ------------- | -------------------------- | | Current | NIL | Current | Done by Bau mostly | TBD | Current | | 1 | **Kickstart community contributions process** with Discord Reboot | Create FAQ section only | Start community contribution process on Github | Github Issues | Mid July - Mid August | | 2 | **Refresh documentation framework** | Revamp new documentation framework (with help of community, since process is up) | Improve process from feedback | Github Issues | Mid August - Mid September | Instead of pursuing everything at once, I suggest we **launch the community contribution process first and get public contributions on the FAQ page first**. The FAQ page should be relatively independent of how the future documentation might change, so we can do a test run with contributors for a month. For the above to happen, we also need to get the Style Guide & Documentation Manual up. During that one month, we can **finalise how the documentation framework** should look like. Once the contribution process is more stable, we can then **enlist the help of community to ensure the refresh is completed on time by mid September**. From here on, the process and framework should help DAOhaus scale our documentations in a decentralised and quality-controlled manner.