Transitioning the DAO to an RFP model

DAO-Wide Temp Check
1

A well known cliche is that committees are the worst way to get something done - “none of us is as bad as all of us” - but that is effectively how we and many other DAOs are attempting to operate. A review of recent threads demonstrates this; while some things end up making good progress, this is usually because one person or a small group “take charge” and go do the work independently, bringing it back for discussion and approval. Other ideas stall because nobody feels they have the authority to lead, and so while many good ideas are offered, none are executed on.

It seems plain that a better solution is needed, and so I would like to propose a significant change in how ENS DAO operations are structured. Rather than letting “the DAO” or even indivdual working groups do the work directly, we should focus on building a clear process for outsourcing work to community members or external contributors via a Request For Proposal (RFP) process.

Here is how it would work at a high level:

  1. Someone identifies a need, and proposes an RFP (yes, a request-for-proposal-proposal). At a minimum the RFP needs to specify:
    • the work to be done
    • the maximum compensation
    • criteria for acceptance
    • a working group to administer the proposal
  2. If the consensus is that this is a real need, the working group stewards agree to adopt the proposal. They can either agree to finance it from WG budget, or sponsor it for a DAO-wide social vote if it is too large to pay from the WG budget.
  3. If the RFP requires an onchain vote, it is put forward as an Executable proposal, approving the WG to spend up to the maximum amount of the DAO’s funds specified in the proposal.
  4. Once the RFP is ratified, the WG opens it for proposals. During this period anyone can submit a proposal to do the work.
  5. Once the RFP period is over, the WG stewards select a winner, and that party then starts work. The WG stewards are responsible for evaluating progress and disbursing funds as described in the RFP and the winning proposal.

In some cases, it’s possible that the person putting forward the RFP will also submit a proposal of their own; for example, when Element Finance proposed a strategy for managing some of the DAO’s funds, they could have formulated this as an RFP, and when approved, but forward their own bid on it.

At the small scale, this process can be very lightweight, but it scales up to even very large projects. Here are some examples:

DAO Docs

Someone identifies that our DAO documentation needs updating; we need more clarity around the proposal and voting process, templates for EPs and RFPs, and flow diagrams that visualise the progress. They put forward a short RFP describing the problem, a suggested maximum compensation of 2 ETH, and suggest the Meta-Governance WG adopt it.

The Meta-Gov WG adopts it at their next meeting, agreeing to pay it out of the WG budget, and several people submit proposals - each just a couple of paragraphs long. The WG selects one as a winner based on price and track record, and the person begins work. A week later they submit a PR with the changes, and the WG pays them in full.

Swag Store

ENS needs someone to run a swag store, including design of the merchandise, fulfillment and shipping, promotion etc. Someone writes up an RFP and the Community WG agrees to adopt it. Because the store will pay for itself out of sales, no funding is necessary, but the proposer and the WG agree on a maximum margin of 25% for the operator.

Several operators bid on the RFP, and the WG selects their preferred one. They begin operating with the official approval of the DAO, and send royalties back to the DAO wallet on a regular basis.

Endowment management

The DAO identifies the need for a fund manager to administer the DAO’s endowment fund. Someone writes up an RFP, specifying desired goals, amounts, risk tolerance etc, as well as maximum compensation for the fund manager. Because this affects the whole DAO, but does not require upfront funding, the Meta-Governance WG puts it to a DAO-wide social vote. The RFP is approved in a Snapshot vote.

Several managers put forward proposals, and the Meta-Governance WG selects the most attractive offer. Because the fund manager will require some level of access to funds, a second, executable vote is put to the DAO to approve access to those funds to the fund manager.

  • Agree
  • Disagree

0 voters

10 Likes
2

Funny you mentioned this, this was an answer to someone’s interview questions I gave recently:

The biggest issue seems to be coordination, and this is not unique to just the ENS DAO. The saying “herding cats” feels appropriate at times. Since nobody wants to “tell someone else what to do,” it is easy for projects to stall or lose direction. From what I have seen, a small few are self-motivated and do a majority of the work, while many are simply spectators, and even more aren’t interested in participating at all beyond a very briefly passing ambition.

I’ve also had a request for funding written for the newsletter for maybe a month now, and haven’t been sure if I should just post it publicly or what.
I like your idea. The stewards participation will be crucial though. They will determine what is actually worth moving forward and what probably won’t actually gain traction. I’ve noticed even with myself, if I’m not 100% behind something, I will just not reply so I can think about it longer. Often I end up not replying at all. I imagine I’m not the only one.

5 Likes
3

Absolutely. I think we will probably have to establish a process by which people can ask for something to be added to the next meeting agenda for each WG stewards meeting; for example, Ethereum Cat Herders do this via a GitHub issue for each meeting.

3 Likes
4

In favor.

This is similar to how the Community Working Group has intended to handle requests for subgroups, but with more depth and DAO-wide visibility. It gives contributors responsibility over of an idea and pushes it towards execution.

A simple, off-the-shelf RFP outline would likely meet our needs with minimum tailoring.

The discord/discourse stack is not providing the coordination tools to get off the ground.

For this RFP model to successfully scale, we will need to implement project management layer. Right now, there’s no clear way to coordinate cross-working groups or even see what projects are currently underway. This, in part, lends to good ideas stalling while in the ideation phase.

@nick.eth’s mention of Github in response to @daylon.eth could be lightweight solution by using issues and project boards.

@vegayp is already looking at using Github for the Community WG and I was going to mock up a DAO dashboard on a Notion account tomorrow. It’s a start. We’ll need to pick something we all can use. I’ll tap into the other WG’s and see if there is a preference.

9 Likes
5

I also think that we would need something to visualize these processes, a kind of kanban-style board.

2 Likes
6

This. Plus, a dashboard could be really useful. Perhaps the first RFPPs could be to a) hack Discourse build to include some custom features, and b) create a dashboard.

I can see how GitHub came to your mind as a place to coordinate even if it requires some work onboarding new users.

2 Likes
7

Perhaps we can put out an RFP for someone to implement and maintain DAO project management. :grin:

As a lightweight option, GitHub issues and project boards do work well; project boards are particularly good at getting an instant insight into the status of things.

4 Likes
8

How about forking GitLab and building our own (simpler UI-friendly) Git + Project Manager with additional features that you like? We could put it alongside Discourse build on the same server and probably also test crosstalk between Git and Discourse build. We use a custom build of GitLab at my web2 work, although it hasn’t been customised as much as it could be since we do not really need it (coordination is minimal in our workstreams, most people work standalone or within exclusive small clusters with minimal crosstalk). Cherry on the cake could be to make SIWE the standard Identity Provider across all custom builds of ENS DAO. This is a serious RFPP that I am kinda-sorta proposing here :stuck_out_tongue:

9

I would really rather not get distracted with building our own tooling except where absolutely necessary. There are definitely existing project-management tools we could use.

4 Likes
10

My A Dynamic Task Reward System for Workgroups idea was intended to solve this exact problem and does so more efficiently both from a cost-perspective and a speed of work-perspective.

It could be combined with an upper and lower bound to the dynamic scaling and final steward approval to achieve pretty much the same thing, but better.

From what I recall your hesitation was that it would be difficult to keep track of workers, that problem is shared both with this proposal and my idea and the same methods can be used to mitigate it.

2 Likes
11

Just a note on this: Tooling and processes are less effective without a cultural or social build. I will say sometimes we are focusing a lot on creating processes and which tools would be the best, but at the moment I only see it effectively on stewards or “people on the know” roles. The same effort that is put on the proposal side, and the tooling side should be implemented on the cultural side and raising awareness, I feel it’s counterintuitive to let a forum and snapshot be the only space to gather a community to be participant.

As a note, I don’t have all the answers (this is more like a rant). But I agree with this proposal in general terms. A coordination layer is needed not only to create a better organization but also to be visible and aware, so it’s not only about the “tool” to be implemented.

4 Likes
12

I think the issue with this is that it doesn’t give the stewards much control over who does a job, and it doesn’t give the people doing the work any assurance they’ll be paid. It’s difficult to see how you’d run a swag store, or manage an endowment, using a system like this.

2 Likes
13

The exact same mechanism used for this proposal can be used for mine to control this. Like I suggested:

Neither does yours.

My idea was actually created to ensure this, two months ago, and it does, more-so than this proposal. There aren’t any further assurances in your proposal to assure people getting paid, than there are in mine, in fact, there are fewer in yours due to my idea solving the expectation of compensation.

No. You’d use the same mechanisms for gating as you’d use here.

14

I’m not sure I understand your proposal, then. As I understand it, you would have an open bounty, anyone can do the work and then come to the stewards afterwards to be paid. How does this provide assurance they’ll get paid, or prevent multiple people doing the work?

Can you write up parallel examples to the ones I gave, showing how they’d operate under your proposal?

15

It’s a system intended for closed workgroups. As it stands now, those workgroups contains selected people and aren’t open to the public. I’d share your concerns if the bounties were open to the public.

The same gating mechanisms used for your proposal, would be applicable to my idea and final approval of accepting a task or approving work altogether before payment could easily be in the purview of stewards.

16

ENS doesn’t have “closed workgroups”. We have elected stewards of each WG, but WG membership is open to anyone.

In that case I don’t understand how your proposal differs from the RFP process.

Can you please provide examples of how it would work in practice, using the examples in my post?

17

They are ipso facto as closed or open as your proposal entails, neither more nor less.

I think that’s more clearly explained in my original post A Dynamic Task Reward System for Workgroups

18

I don’t understand what this is supposed to mean.

Your original post doesn’t provide any examples of the process in action either.

19

I’ll try to think of an intuitive way to explain it by tomorrow afternoon.

20

I think some worked examples mirroring the ones in my post would be simplest and most illustrative.