# DAO IMPLEMENTATION IN RUST FOR NEAR

## Project Description
The goal is to implement the Rust version of LAOLAND so anyone using NEAR can use it to manage a DAO.

This is also an opportunity to write a standard interface for this architecture so anyone can upgrade their DAO on NEAR or Ethereum.

## Team Members
* David Roon
* James Young
* Craig Blake

## Team Code Repos
* David Roon: https://github.com/adridadou
* James Young : https://github.com/jamesyoung
* Craig Blake: https://github.com/craigwblake-openlaw

## Team LinkedIn Profiles
* David Roon: https://www.linkedin.com/in/davidroon/
* James Young : https://www.linkedin.com/in/jamessyoung/
* Craig Blake: https://www.linkedin.com/in/craigwblake

## Intended Language of Development

Rust, Solidity

## Development Roadmap

The challenge for us is that this is the first project any of us has ever done in NEAR.

That means that it can be hard to estimate the time we need to deliver any milestone. This is why we want to propose an approach that is compatible with the current setup and the know how of the team working on this project.

### Package
Each parts of work should be defined in package. Each package has the different elements:
* An exhaustive list of deliverables to implement
* A clear description on how those deliverables will be tested & validated
* A description of the value it brings, why are we doing this.
* How much will be granted once it is done
* Who is assigned to the package

Each package should take around 1 or 2 weeks to finish and should deliver something working or at least that is a net positive to the project. I.e. we should avoid splitting a package in several ones because we don't now how to make it smaller. But documentation and implementation can be a different package.

During the development of the packages, the PM and NEAR should be in a validation loop to make sure that:
* What we are implementing is really what they want
* Prioritise the next packages
* Define new packages

Once a package is done, a presentation to show the deliverbales and share experience with each party.

## Phase 1 - dev environment & team setup
We want to keep the project open and as collaborative as possible. That means that it should be quick and easy for someone to get up to speed and implement a package.

To get there, we need to have a team setup with a good documentation so that anyone can set it up locally and focus on the code, not configuring NEAR or any other part that might be needed to get to work.

The high levels deliverables here are:
* Setup so anyone can write the DAO TDD style similar to what has been done for the Solidity version
* Giving a tutorial / story about how to develop in NEAR for a solidity developer
* Giving feedback about the pain points to work with NEAR, with solutions if possible
* Giving a standard setup for anyone who wants to write smart contracts in NEAR

## Phase 2 - DAO translation
Once we're all set, it is time to actually develop the smart contracts.
We think that before trying to adapt the code to NEAR specificities and use the tools that NEAR give us, it makes sense to first translate naively the code from solidity to Rust. We think that this way we can have a working DAO more quickly, having a good base with tests and a better understanding of writing smart contracts in Rust, then we can start working on improving the existing code with the help of NEAR team and make it more NEAR specific.

## Phase 3 - NEARification of the DAO
We have now a working DAO, it is time to improve it so that it uses everything that NEAR has to offer.

## Phase 4 - standard definition

## Phase x - new needs, new adapters, new apps
Once we have it all working, it is time to work on new adapters if needed, maybe dApps (UI, maybe a js framework to write DAO dapps more quickly) etc ... Here sky is the limit on what we can do.