Conflict Resolution Framework

As progress is made towards using a Decentralized Autonomous Organization to manage the treasury and potential projects there will inevitably be conflicts where work has been done with good intentions but ultimately fails due to some other reason.

I am proposing a framework on how to handle situations where a proposal in good faith was made and the DAO agreed to it, only to reverse course later because of reasonable causes.

For example:

Proposal:
In the future silos will include a 1st step requirements doc to be created before the whole proposal is approved. This will give voters a better understanding of the scope and benefits. If the silo were to be denied after requirements doc was completed in good faith, there should be some compensation and that should be based on the time spent and also the scope of the original project with a maximum limit.

Proposed options:

  1. 2% of silo’s requested grant amount with a maximum of $2000
  2. A pro-rata amount based on requested grant amount and the amount of time spent creating requirements doc with a maximum of $2000.

Why should there be a maximum?
If there is a scope of work where the requirements doc (exact specifications being developed by @ross and @designer) requires an amount of work greater than $2000, it would require a grant to create requirements docs.

This framework could be used to resolve the issue with Yambassador’s silo.
Feel free to add thoughts.

Thanks for Posting this @feddas. I agree that this is important and we need to have a system in place to make sure we limit misunderstandings and conflicts. The model that you describe is very similar to what I have been sketching out, with the following characteristics:

Flow

  1. An applicant who wants to come develop a project for YAM will create a Silo (project) application, very similar to what we have been filing out so far. But this document is not also to ask for a full fledged grant for the full scope of work. It is to present the idea to Token holders to decide whether they wish to fund a requirements/specification document for the project.

  2. Upon creation of the Silo and approval to produce a requirements document (via snapshot), the applicant will then create the document and work with DAO members (probably the gov ops council or similar) to make sure that the document meets the standards of quality that is expected.

  3. Upon completion and review of the requirements document, it is published for review, and at this time the applicant will submit a grant proposal for some or all of the work laid out in the document. This proposal, along with the requirements document will have an open review process in which someone can object to the scope or terms, and other parties can submit counterbids for the DAO to choose between.

  4. The DAO votes on whether it wants to fund the grant.

    • If the original applicant’s grant is approved, great! they will begin work and will get paid for the requirements doc in the next on-chain transaction.
    • The the original applicant’s grant is not approved and there are no other bidders, they are still entitled to compensation for the requirements doc, but will need to re-apply for the work.
    • if the original applicant’s grant is not approved and another bidder is selected, the original applicant is entitled to the compensation for the requirements doc, but the selected bidder will begin doing the work.
  5. Work begins and the silo contributors are paid based on the scope and terms of their grant application.

Payment Amount

I was skeptical of the percentage for a payout before because I didn’t think that there would be a verifiable cost, but if payment happens after the grant proposals are voted on then we will know the grant proposal amount. There is a chance that an applicant inflates their bid with the hope of getting a higher requirements document grant, but this would limit their chances of winning the full project. This could be gamed if the applicant had no interest in building the project anyway. If we expect some people to create “RFP” style requirements docs without bidding then we need to deal with that situation since they would have no requested grant amount. Maybe, if a requirements doc writer has no intent to submit for a full grant then should negotiate the rate beforehand.

Yambassadors application

@Snake 's vote to request funding for the work he did on the requirements for Yambassadors did not meet quorum. His request was for $6800 dollars.

If we applied the rough framework above to his original proposal, then we would get the following numbers:
2% of $80,000 = $1,600 for work done

If we were to apply the percentage amount to the winning bid instead, it would be:
2% of $5,000 dollars = $100 for work done

If we were to apply the latter example, then the amount to pay out is not reasonable so we should probably have a lower bound as well as a high one. Maybe $1,000 for a decently developed document?

Picking numbers is hard so maybe we should have a snapshot vote with a few options and see what comes out ahead?

The overall flow makes sense. It will require a significant amount more time to get proposals passed and grants approved, but this is how many RFP systems work. It’s good to plan out what you want to do, get the feedback / approval then do the work. In the past Yam has done it more backwards and there was a significant amount of wasted time when things had to be redone when the final product wasn’t acceptable.

It would be good to find an acceptable amount for Snake’s work. If we were to apply my proposed solutions

  1. My thinking would be something like this:

In his request, he calculated that he spent 2 weeks of work on the proposal and subsequent discussions. His proposal budgeted 6 months worth of work @ $80000
$80000 / 24 weeks = $3333.33 per week * 2 weeks = 6666.66 which would be capped at $2000.

This would be a good solution for @Snake proposal since these guidelines are being created after his original proposal but I would like to know what he thinks.

I want to highlight this point and again not sure if you did update or not the “flow” you suggested, and @feddas we can also include this into your post for later clarification about “working with the individual”, so as we have discussed:

A user comes with an idea, he proposes it with intentions to work on building it, once thats done our role is to work with the user prior/post proposition and help push forward his idea, and again as i told you, nor we (nor anyone), is to sabotage a proposed idea as it is unethical and that is not the intention behind what we or yam wants to gets towards for builders.

A builder is supporting yam, yam supports the builder, very important.

So lets make this very clear in the documents.

Thank you.

I agree with utilizing this process but the requirements doc and expectations should be formalized. Right now every requirements doc looks different and it is quite subjective.

I think it makes sense to come up with a limit but I think it should just be an amount that is set and changed from time to time based on the number of proposals that are being considered. It might also matter if the proposal is of a product vs marketing nature and factor in returns on investment.

In the counter put forward by @ross, 12 out of 40 hours were for scope/research work which amounts to about 30%. That probably shouldn’t be standard, but between 1000 - 2000 sounds like a good range though.

I spent much longer dealing with my silo/grant because these rules weren’t in place and it is harder to hit a moving target. As this process becomes more solid and there is more precedent, it should be easier for those that follow and perhaps the rates can come down if there is already a bunch of work underway.

As for reimbursement, I was asking to be reimbursed for my time working with you all on this not just the requirements doc so it feels like apples and oranges. I proposed what I thought was fair for an amount of time that I think everyone finds reasonable. I don’t think anyone is proposing that we go through this process in the same way in the future.