# Haus Improvement Protocol

### Main problem statement:

- Priotizing feature pipelines
- balance with maintenance
- weighing stakeholder (we have many) input

### Related problems statements
- Method needed for determining which features to prioritze.
- A new feature request is made how do we priritize and assign
- Incentivize the DIRTY WORK. Project managment/fixing bugs/being accountable for the app working
- The problem of incentivizing longer term quality (e.g. clean code / solid infrastructure) vs. deliverable-oriented payment.
- Infastructure is underrepresented in mindshare...
- How do we decide which external contributions to implement during other intensely focused work?
- Feature bloat adding features for every possible usecase. Do we need to be opinionated? Curation?
- How and when do we say NO to features?
- a company would like to build an integration

### Design Requirements

In order for a solution to be considered viable, it should adhere to the following conditions.

- The Protocol must allow for continued, meaningful improvements that accrue the most value for the app and community as a whole
- The Protocol must have a sound, transparent way of deciding which improvements deserve the highest priority
- Funding must ultimately be governed by UberHAUS
- The Protocol should account for the balance of maintenance required to continually deliver services to the community
- The Protocol presents maintenance alongside features when allocating budgets and priorities (HIPs)
- The Protocol should assist with community development
- The Protocol should assume that development of the product, features, and even maintenance will become more decentralized, and eventually completely autonomous.

## Written Storyboard Solutions

### Balancing Maintenance with features

**Story 1**: Solving the tragedy of Maintenance from the outset.

- Before Proposals are collected, voted on, and prioritized, UberHaus will be see a presentation on the app, it's current challenges, and what it needs in terms of maintenance.
- Each delegate will be made aware that the speed of development, UX, and overall adoption relies on the product infastructure.
- Examples of other companies/DAOs will be presented as sources.
- Delegates decide on an overall ratio of funding and labour with a vote.
- For features and new development, the delegates decide how much will be funded by directly Uberhaus and how much will given in grants to Boost Foundry and Daostillery (DaoStillery should be its own entity).
- For maintenance, they will create a general ratio of how much funding is allocated to each aspect of maintenance
- preventative maintenance (refactoring sections of the app, creating new systems, removing dependencies)
- corrective maintenance (Having someone available to fix bugs)
- adaptive maintenance (adapting to new changes)
- perfective maintenance (redesigns and development of existing features for better UX and app focus)

### Pipeline Solutions:

**Story 2:** Syncing UberHaus with HIPs

Before this process is implemented, there are a lot of feature and maintenance requests 'laying around', either in people's minds or in certain repos.

- Uberhaus votes on a fair deadline to recieve proposals
- Paladins create a repo and system for recieving proposals
- Rangers put out an open call for proposals to the community. They provide detailed instructions on how to create one.
- After the deadline, token holders vote to signal which proposals should be prioritized
- Over time, UberHaus decides if these requests will be funded.

**Story 3:** Adding and prioritizing a proposal.

Community member (outside of UberHaus) has an idea that they wish to be implemented.

- They arrive at Discord with their idea and dump it in one of the channels.
- A moderator or war camp member thanks for them for their contribution, but informs them that they'll need to fill out a HIP if they want to see it get funding.
- They're directed to GitHub (or something that's better for non-dev members) to fill out a Haus Improvement Proposal
- They recieve a template and work from that. The template requires them to explain clearly what this change is, and why it needs to be made.
- It's put into a queue, the order of which will be continuously voted on by Haus holders to decide priority

**Story 4:** Voting on a proposal. Lifecycle of a HIP in UberHaus

- Meeting delegates choose the next *n* proposals to be disucussed based on the amount of time in the meeting
- Proposals are pulled from the queue in order of votes to ensure fair representation.
- Delegates weigh costs and benefits of proposed change.
- They can vote to fund the proposal or not. They also have the option of sending the proposal back to the queue for discussion later on.
- If the proposal does not pass, it is committed to another repository with a reason that it did not pass.
- If the proposal does pass, it is assigned to a department of the DaoHaus team (magesmiths, rangers, paladins, etc) for implementation.

**Story 5:** Slating a proposal for development.

UberHaus decides on a proposal they want to see implemented. They hand it off to a team lead.

- The team lead either decides on their own or consults with a member of the team about a general solution, and a rough idea of how long it would take.
- The lead makes a spec outlining a plan of action (can also delegate this), and is sent back to UberHaus for approval.
- Once approved, the Team lead has a public calendar marked with deadlines of all the work the team is expected to fulfill.
- Gauging available labor available and the current queue of features that are slated for production, the lead adds the proposal to the calendar.
- The lead returns to UberHaus a rough estimate of how long the change will take to be implemented.

Features are effectively placed in a pipeline. New features must come in at the end of the queue. If the demand for features outpaces the overall output, then UberHaus will have to wait longer for them to be implemented.

**Story 6:** UberHaus emergency priority override.

An UberHaus delegate feels a certain feature or maintenance request is a lot more important than the ones currently being worked on. They need it to either jump the queue or move ahead in the production calendar.

- As an opertional principle of UberHaus, the delegates each already understand that switching priorities comes at a heavy productivity cost.
- They also understand that switching priorites undermines the community voting, and the overall value of the token. Which means that it should be transparent and used only in case of emergencies.
- The delegate proposing the change also proposes which item should be higher priority and which should be a lower priority. If these items are already in the calendar, then they must have equal weight in terms of time to implement and costs.
- The delegates debate whether this change is important enough to justify the productivity and confidence loss
- Of course, the team lead whose calendar could potentially be rearranged is there to voice their opinion.
- If the new proposal is important enough to jump the line, the calendar is rearranged, and more time is added to account for the productivity loss.
- A memo is sent to the community explaining why this change was necessary.

**Story 7**: You figure it out.

A member of the DaoHaus community has a complaint or notices a problem with either a process or the product. However, they don't have a solution in mind.

- They submit a proposal as per usual.
- Token holders signal interest with voting.
- UberHaus members vote to pass or not pass the proposal as per usual
- They also have input on the solution
- They choose the team responsible for coming up with a solution and consult with the team lead.
- After this, the process is the same as a regular proposal. The team lead is responsible for submitting a spec to UberHaus for approval.

### Boost Foundry Stories

**Story 8**: Creating a community boost.

A member whose boost idea didn't recieve a lot traction with token holders feels that their idea didn't get a fair shake. They decide to make it on their own.

- A member expresses their desire to make their own boost.
- A WarCamper directs them to Boost Foundry, a dao repsonsible for community built boosts.
- They build their product in boost foundry. Perhaps they recieve a grant, or guidance from other members. Perhaps the member chooses to not receive anything and instead work for spec and reap the rewards accrued by the boost themself.
- DaoHaus, UberHaus, and Boost factory have a model for distribution of revenues from boosts. It is distributed accordingly.
- UberHaus has also allocated some time to the product team for integration of community boosts. They decide which community boosts are integrated first.

**Story 9**: Boosting community development.

Community development has picked up a lot of traction. DaoHaus members along with the community believe that development is ready to become community driven
- The member or members draft a proposal to:
- divert funding of features to be made by the core DaoHaus team to Boost Factory
- build infastructure to more efficiently integrate community boosts
- build a marketplace to automate and streamline the process of monetizing boosts.

### Boost Foundry

Decentralized DaoHaus development.

Boost foundry should eventually overtake the creation of new features from both DaoHaus core team and DaoStillery. As the development becomes more decentralized, it will become more advantagous to marketize the development of boosts. Of course, this will only happen if Boost Foundry works and there is an active community of creators.

Which means that the core DaoHaus team will focus on providing the platform and ensuring functionality. They will ensure that boosts aren't malicious, bug-ridden. They provide the protocol and standards by which boosts are submitted. DaoStillery will commission labour from Boost Foundry or issue bounties.

UberHaus's focus will turn from managing a single product to guiding a community with market incentives. Similar to the ETH foundation.

### Empowering DaoStillery

In order to prevent priority collisions with UberHaus, the community, and big-players looking to join the platform, Daostillery should become its own DAO.

- Features and maintenance required by big players should be funded by the players in question.
- UberHaus can 'colab' with other big daos and chip on funding.
- UberHaus can invest seed funding to help promote services to large daos
- Additional revenues from DaoStillery should help fund infastructure upgrades (in a way that helps onboard more large communities)
- Time commitments to DaoStillery should be accounted separately than DaoHaus core team commitments, as DaoHaus team leads need to know how much time they can allocate to tasks given to them by UberHaus, not new customers.
- Core DaoHaus team members looking to work on DaoStillery projects are doing so in addition to their time commitments to DaoHaus (which can always be adjusted accordingly).
- They're paid on a project basis instead of a regular monthly basis.