General RFC Framework for Proposal <> Guild Coordination

General
1

I’ve been thinking a lot about how we can coordinate effectively between proposals and the work needed from guilds to accomplish them, especially when treasury funding is involved.

Particularly, when creating large proposals, we cannot and should not assume the roles and budget required to meet the needs of the project without consulting those doing the work.

(this precludes small, in-guild proposals)

Let’s just use an example:

A marketing campaign proposal includes the need to build a landing page.

A basic assumption on who might be involved in landing page creation yields us the following guilds:

  1. Writers
  2. Designers
  3. Developers
  4. Translators

It would be premature at this stage to presume:

  1. The roles required from those guilds to perform work
  2. The budget for each of these guilds to do the work

So, it is this initial proposal that we should consider calling an RFC instead.

RFC > Guilds > Proposal

RFC (request for comment) is a common methodology for getting feedback on initiatives. (see also RFP - request for proposal).

An RFC framework for us would start with the intent of the work that should be delivered and then asks guilds to comment on the roles & budget that would make sense for that work.

“We want to building a landing page, what do you guilds think it would take?”

Once the guilds review and coordinate (TBD), they would each return some formal comment on the RFC document.

Once all guilds have commented, we have our first iteration of a Proposal.

Now, our Proposal would look a little more fleshed out:

  1. Writers
  • 1 copywriter
  • 2500 BANK
  1. Designers
  • 1 web designer
  • 1 graphic designer
  • 5000 BANK
  1. Developers
  • 1 frontend dev
  • 1 web3 dev
  • 5000 BANK
  1. Translators
  • 1 french translator
  • 1 russian translator
  • (etc)
  • 5000 BANK

It might be at this time that scope is adjusted or guilds challenged on their demands / roles. A negotiation and editing phase where the Proposal goes through multiple named Versions (official V1, V2, etc).

(At some point, a “Landing Page” proposal might be specifically streamlined and have a fast track if we’ve been through it enough times)

Through Soft Consensus (including signoff from each guild) it would be put to Snapshot vote (or otherwise) and be funded.

Once funded, the roles are published to Bounty Boards or otherwise filled through Guild tactics.

Ultimately, I believe this promotes transparency, coordination, and fairness.

7 Likes
2

This is a great post.

In this scenario, it would make sense for Guilds to have a coordinator that can give RFCs that answers they need.

1 Like
3

I also love this.

What makes sense to me is once the snapshot is approved the proposal becomes a project.

So it would look like:
RFC > Guilds > Proposal > (soft consensus) > Snapshot > Project

1 Like
4

It might also be a good idea to have a price list so you can consult prices. Instead of asking for prices all the time.

1 Like
5

So if I get this proposal right, the purpose to get approval from DAO for funding when the project involves a budget from the treasury. And also make sure that this budget when used accomplishes its intended purpose, the work is done. One of my readings of this proposal.

How will we measure if the RFC accomplishes its goals? How do we know if the project is a success, or when requesting additional funding the project did what it promised? Would not this involve a DAO process at the end of each project of deciding if the initiative missed key features, delivered a different than expected but amazing work, etc? Also, project learnings at the end. What these initiatives taught us… Is this something that we should put into the RFC or somewhere else?

Some more questions when doing RFC, that comes to mind about the pipes of doing too much at the same time:

  • Do we want this project?
  • Do we want this project for the X price?
  • Do we want this project if this takes X amount of time and resources? (Resource can be project planning, proposal writeup, etc)
  • Do we want it now? If not now, how should we approach it?
6

I’ve been working on a proposal of a finance structure for the DAO. However, we are waiting for the legal structure if any for the DAO. However this proposal also includes points about budgets for projects so this can be a proposal on its own. Please have a look and comment.

https://docs.google.com/document/d/1BW7uF7wg9vRpvckii2sV6vYUkVsG97rONTEQg8GQa4U/edit

The points regarding budgets for projects are:

Funding Proposals

If the proposal requires a budget, it should be included in the financial implications section of the template and can be voted on along with the proposal.

If proposal passes a snapshot vote, someone with access to the treasury converts BANK to a stablecoin (if required) and transfers stablecoins to a project wallet (this can be to send the BANK to the members that have performed the tasks, etc)

  • The person requesting budget uploads receipts for all expenses to a specified location (e.g., IPFS filestore that has a receipts folder for each project approved for budget).
  • The person requesting the budget is responsible for the budget management. So if the budget was granted for x amount and this amount is exceeded a new proposal needs to be put forward and voted upon.
  • The budget can only be used for what it is approved for.
  • If the budget is not spent for whatever reason (e.g., the project is cancelled), the budget is cancelled and funds remain in the treasury.
  • Budgets for each project should be kept public to the DAO in an itemised way and readily accessible. For example:

Marketing campaign

Capture
Capture785×211 17.2 KB

7

These are some really good points on the overall treatment of DAO projects and definitely have a place in the formation & vetting of proposals.

An RFC period is the perfect first interjection point for community members to say “hey, what if?” and I think guilds can play a special role in that process - making sure these things are really thought through.

“What are the OKRs and what happens if we miss them?” I think is a vital question for any project to think about at the start. Otherwise we might end up with “project part 2 - please give us just a little more BANK”.

8

Guild coordinators are going to be integral roles. For developers, a Product Manager would be someone who typically would sit in this function.

“Hey a new project came in, I need devs to scope it so I can get back to them with estimates”

Coordination games like “planning poker” are a great way for developers to judge projects and come to a consensus on labor value.

1 Like
9

This makes a lot of sense. The “build a landing page” example was really helpful to see how this plays out.

10

I think this is a great process to recommend to DAO members to build a successful proposal

I don’t think we should mandate any particular process in our DAOism, but maybe we can build some guides for the book that people can follow if they have an idea but aren’t sure how to tap into the DAOs talent.

1 Like
11

I think this is a great I idea to have some formalized process lie the one above. Even if it is treated more like guide lines rather than set in stone rules. Having a standardized process that everyone is familiar with with greatly improve coordination and minimize confusion.
For this to be effective we all members would need a go to place to get educated on these processes. I know the RaidGuild DOA has an awesome handbook for this. Dose anyone know if we are working on something similar somewhere?

12

Yes, @wolfehr an other are working on something like this.
Right now, this is what we have: https://bankless-dao.gitbook.io/

1 Like
13

I think a “Frameworks to build a proposal and get support” section would be a nice addition to the wiki/gitbook/whatever. The RPC would be one framework we can suggest. I can also add one I use at my job for launching strategic initiatives, which at a high level is stakeholder alignment → challenge/lean canvas → stakeholder feedback sessions and iterate on canvas → proposal.