P-15: DAO Operators

I would love to standardize on the following language for requirements for roles.

i think we should add some more specifics around the $CODE bonus allocations for the operators specifically around: what’s the minimum an operator will get (is it actually zero or do they get a “signing bonus”) and consider adding some restrictions for those with an already large allocation of $CODE. For the last bit in particular, if a core member or budget steward gets hired for an operator role they already have a large allocation of $CODE and we should think ahead to the possible future implications of that (i.e centralization, sybil resistance, etc…).

Also, have we considered adding any verbiage around how many repeating terms a given person can have as an operator? With how the document reads now, a given person can be continuously nominated/hired for the same role. Not saying that’s a bad thing or anything (eventually these roles might transition to permanent gigs) but if the goal is for the roles to be temporary then we should consider capping the number of repeated seasons.

1 Like

Regarding the significant time commitment by others. There are currently on-going budget proposals for all other guilds and projects. If you feel unrewarded please check under which project do you fit and raise that issue!

Important thing to note is the the fund raising role doesn’t not raise money for the DAOs operations, but grants for public good projects which are built under the DAO. The money used for DAOs operations comes currently from sponsorships acquired by MBD guild.

For example:
On-boarding team will be paid through money received from sponsors.
Public good project (like school of code) could apply for a grant and get paid via the money pool raised for that.

This proposal will create the budget stewards and give them control over the DAO treasury, but that’s not in the summary. At the very least the actual outcome of the vote should be in the summary.
You already have a ‘Budget Steward’ official title on the forum, right now. That means you’re acting as though this has already passed? What’s the point of putting it to a vote, if the power is already assumed?
The names of these people don’t appear here. The names of appointed operator candidates don’t appear here. The numbers are chosen mysteriously, and are subject to redefinition by the un-named group this proposal will enshrine.

Other than making comments here, is there any way to hit the big red button and sound the alarm about this process? It seems like there’s very little anyone can do to prevent the existing group from taking control.

This proposal is called ‘DAO Operators’, but it actually asserts control over all budgets! It gives this ‘budget stewards’ group veto control over every proposed use of tokens and money! This is more power than any board of directors would have at any traditional organization.

Sneaking this power into a proposal like this is very smelly.

1 Like

So let’s move on.

The DAO does not and seemingly cannot be a DAO yet. Let the powerful exercise their power and organize the farming. It’s too late to change any of it.

Help the decentralization effort for next seasons. It will likely be derailed by conflicting interests, but that’s the best you can do. You can find my general opposition to these linked proposal here: P-13: Developer DAO Improvement Proposal Formalization - #16 by p_b

Congrats for unlocking governance anon. (why anon?)

1 Like

This is something we haven’t tackled yet, and I feel we need to start doing that: Who handles the treasury? A new position? Governance Guild? A new Guild?

i think we should add some more specifics around the $CODE bonus allocations for the operators specifically around: what’s the minimum an operator will get (is it actually zero or do they get a “signing bonus”)

Yes. This should be clear. Thanks.

consider adding some restrictions for those with an already large allocation of $CODE.

This is a good point, and one we haven’t started discussing. Specially now when all budgets are being delivered. Should we have a cap, for example?

Also, have we considered adding any verbiage around how many repeating terms a given person can have as an operator? With how the document reads now, a given person can be continuously nominated/hired for the same role.

We can add them, but not sure where to draw the line, without being arbitrary.

1 Like

The names of these people don’t appear here.

Agreed. The names should have appeared in the proposal. One of the key learnings has been how complicated is for a regular member to get information related to proposals, when it’s scattered in multiple channels.

The names of appointed operator candidates don’t appear here. The numbers are chosen mysteriously, and are subject to redefinition by the un-named group this proposal will enshrine.

A reiteration of the above comment, the nominations are taking place here: https://discord.com/channels/883478451850473483/989565728778776577/990388896552587344. But again, I accept we have a problem to make all the information available to all members.

Other than making comments here, is there any way to hit the big red button and sound the alarm about this process? It seems like there’s very little anyone can do to prevent the existing group from taking control.

The red button is intended to be the Stewards. Right now, they are arbitrary appointments, correct. Thanks to @p_b comments, we have started working on a proposal to make them elected positions, and define their attributes: Stewards - Google Docs

Heya Erik sorry for the delay in getting back to you

For the $CODE restriction, I think a cap would make sense to have for someone who already posses a large amount of token. How large is large? That’s probably a debate in of itself; however, perhaps a good starting point as a threshold is 20k $CODE? For someone in that situation i propose that person be capped to receiving 50% of the total 5k eligible code (again probs a starting point for a healthy discussion)

With respect to the repeated terms, i suppose it’s not super important at this stage as we want the most active folks to keep their momentum going. I suspect these roles will eventually turn into full time gigs so maybe no point exerting energy on this at the moment.

consider adding some restrictions for those with an already large allocation of $CODE.

For the $CODE restriction, I think a cap would make sense to have for someone who already posses a large amount of token. How large is large? That’s probably a debate in of itself; however, perhaps a good starting point as a threshold is 20k $CODE? For someone in that situation i propose that person be capped to receiving 50% of the total 5k eligible code (again probs a starting point for a healthy discussion)

I disagree here. People shouldn’t be punished for contributing more than others, right? Otherwise, we might discourage the best contributors from continuing to contribute. that feels like a bad path to me. If we’re going to limit the impact of CODE allocations IMHO it should be via some kind of reducing the curve of voting power. That seems much fairer. If anything imo we should be trying to identify the people making the biggest impact and figure out how to recognise them more for it over time.

Also, have we considered adding any verbiage around how many repeating terms a given person can have as an operator? With how the document reads now, a given person can be continuously nominated/hired for the same role.

With respect to the repeated terms, I suppose it’s not super important at this stage as we want the most active folks to keep their momentum going. I suspect these roles will eventually turn into full time gigs so maybe no point exerting energy on this at the moment.

Agree strongly here. We shouldn’t set arbitrary limits on how long someone can perform a role. If folks are doing a really good job it was be c-r-a-z-y to remove them. Stability and consistency can be powerful benefits for not doing this. We still have the ability to remove people who are not performing, and a regular election cycle probably also makes sense at least in current iteration

cc @Erik_Knobl @Narb

1 Like

Thank you all for taking the time to put this together. I will be voting FOR, but I want to know how we can continue to address the comments made that I think have credence. I appreciate and agree with the direction that this proposal intends to go and understand that we need to begin somewhere - iterating as needed.

1 Like

That’s a fantastic idea! The point about reducing the voting power was basically what I was after here assuming we build something like that out for our governance. The intent was never to punish but more so attempt to maintain decentralization during governance.

:100:

Delayed removals (not immediately) may be worthy of consideration

yeah, potentially the idea of a cooling-off period as well. sometimes in the heat of the moment, quick decisions can be made from an emotional place we come to regret later

I know ENS added this after the brantly situation and have seem other DAOs with something similar to ensure there is time for folks to calm down and consider the facts

Connecting a dot here for posterity:

The Fundraising Operator role definition was a good-faith effort, but written with limited expertise in the performing of that role. Following a nomination, then a snapshot vote election, Chuck and Wikist have reset expectations for the role in Season 1 here.

@Erik_Knobl we need to update the language this to reflect the nature of the relationships between Operators and the Foundation/DAO.

They are not employees which means they do not receive base salaries. They receive payment of services provided and Governance rewards for hitting targets. Please can we update this asap.

I can edit your post if you’re happy for this with this, did not want to do it without stating here publicly and transparently. Once the changes are made we should include a comment that highlights those changes explicitly so folks can see.

1 Like

Update on Coordination Deliverables

TLDR

Weekly coordination calls have been consistent and improving recently with everyone’s help. Lots more work to do than anticipated (@Erik_Knobl told me this :joy:) and some harder than expected blockers related to finance infrastructure. This post is a good summary of where I believe things are at currently and some changes we should think about making - Can we build a better game?

Task Summary

  • Improve internal coordination and champion process improvements accordingly. :hourglass:
  • POC for legal representation in the Caymans (and anywhere else) and liaison between them and the DAO, and keep an open record of all processes. :white_check_mark:
  • Creating processes required for KYC/AML (such as ensuring grants to the DAO itself are correctly accounted for under Cayman Law), and owning these. :white_check_mark:
  • Host weekly Initiative Leads meetings, and ensure records are accessible to everyone. :white_check_mark:
  • Set cadence and structure for hosting monthly DAO wide town halls in coordination with the Community Guild. - community guild did this :handshake: :white_check_mark:
  • Oversee the Seasonal Budget application process and tracking of how budgets are finalized, allocated and distributed, as well as any incoming revenue. :white_check_mark:
  • Define and maintain access permissions across DAO tooling (discord, discourse etc.) to ensure organizational security. Work with any team looking to implement change to DAO tooling or structure to ensure it doesn’t harm coordination as a whole (at the DAO > Guild level). :hourglass:
  • Creating a process for issuing, fulfilling and tracking finances for The Developer DAO Foundation and any other entity created to support the DAO functioning (this may include hiring external partners given compliance risk in maintaining accounts correctly). :white_check_mark:
  • Establish a $CODE buyback mechanism in partnership with the Governance Guild. - :stop_sign: not started yet

Milestone summery

  • 80% of active projects/initiatives submit applications to receive $CODE funding :white_check_mark:
  • Foundation successfully receives S1 sponsorship funds and pays all S1 financial obligations based on approved proposals :white_check_mark:
  • First $CODE buyback successfully completed ($CODE returned to treasury) :stop_sign: not started yet
  • Agreements executed with at least one subsidiary initiative (e.g. pixeldevs, web3con) and one affiliate initiative (e.g. p3rks, DAO Agency) :hourglass: going with Sub-DAO and D_D labs conversations.

Other outputs

3 Likes

Update on Fundraising Operators Deliverables

FO (Fundraising Operators) had went through discovery phase inside of the DAO and put rails for fundraising infrastructure of which basic components are already in place and are being curated on a daily basis with additional updates. Database of grantfunders had been created - 24 connections had been established so far. Database of D_D projects had been updated and expanded. Two educational workshops are already behind us and FO are starting to connect D_D Founders with right grantfunding entities.

Update on role deliverables

Month 1

  1. Better understand DAO members’ challenges, problems, and needs as they relate to fundraising. What we discover will inform the rest of our work and could cause us to reprioritize the rest of the work on this list.

KPI/Deliverable: Memo outlining the most common & acute pain points we uncover.

Effects:
The whole discovery process was completed in the first 3 weeks of our operations. The memo outlining our findings and the synthesis of the results are available in Fundraising Operators’ Public Resources.

Status: Done :white_check_mark:

Deliverables:

  1. D_D Discovery Memo
  2. Synthesis of D_D Discovery Form

  1. Create the legal infrastructure for projects looking to apply for external grants.

KPI/Deliverable: Memo detailing the rights and responsibilities for D_D projects, subsidiaries and affiliates seeking outside funding.

Effects:
In the process of discovery it had been found that memo might not be enough for what DAO actually needs. A whole FAQ-like Notion page had been created about fundraising aspects in D_D.

Status: Done :white_check_mark:

Deliverables:

  1. D_D Fundraising Guide

  1. Develop a standard agreement between the DAO and projects which receive DAO funding or other resources.

KPI/Deliverable: Standard agreement drafted, shared, revised, and finalized

Effects:
Efforts related to this deliverable had lasted for six weeks time. FO had went through the research stage, gained information about standard practices in the space and template agreements to be used. Afterwards FO created the Steering Committee - an entity composed of DAO leaders that could decide on behalf of the DAO about details regarding the agreement for D_D’s spin-off projects. Four meetings were held (with the committee and spin-off projects representatives). On D_D Coordination Call on 20th of October it had been decided by the DAO leaders that work should be paused due to lingering uncertainty surrounding this work. After talks with D_D projects’ representatives it turned out that the DAO still lacks structures that could support the process of incubating or accelerating such projects and as such creating such agreement was premature. D_D still needs to develop better support infrastructure, detail benefits and conditions that it brings and only after these things are established there should be agreement put in place.

Status: Halted :no_entry:

Deliverables:

  1. Partnership Agreement Resources for D_D Spin-off Projects Notion page that details the whole process taken by FO behind agreements drafting. The existence of this page will make it easier for future actors to work on this task, when the time will be right to do so. Whenever D_D wishes to start this work again, then resources provided here will get a hot start on the project (whether it will be a task for Fundraising Operators or not).

Month 2

  1. Establish a documented process for qualifying projects for grant applications under the Developer DAO banner.

KPI/Deliverable: Flowchart drafted, shared, revised, and finalized

Effects:
With the help from Coordination Operator FO had prepared the necessary flowchart.

Status: Done :white_check_mark:

Deliverables:

  1. Notion page detailing the process
  2. Process flowchart for qualifying projects for grant applications under the Developer DAO banner

  1. Establish a documented pipeline of grant sources and build relationships with those granting entities.

KPI/Deliverable: Airtable CRM created and populated with all D_D funder relationships.

Effects:
The D_D Airtable database had been expanded by “Funders” tab. “Grant Programs” tab had been updated and new granting sources had been added. All the connections made by FO with grantfunders are being recorded in this base on a daily basis and available to be seen by every D_D member through D_D Relations with Grants Funders Notion page. Every week D_D’s Friendly Funders Report is being updated for D_D members to stay up to date on new relationships being made. They are also presented weekly in D_D’s newsletter.

Status: Done :white_check_mark: + updates

Deliverables:

  1. D_D Relations with Grants Funders Notion page
  2. D_D’s Friendly Funders Report
  3. D_D’s Funders Airtable base

  1. Establish an internal database of the projects and initiatives that will allow organizational visibility and better coordination.

KPI/Deliverable: Airtable database created and populated with all D_D projects and initiatives.

Effects:
The tab “D_D Projects” from D_D’s Airtable had been updated and expanded. All projects in the whole DAO had been included. FO had decided to expand on this database more than stated in the deliverable and started to record independent projects led by D_D’s members who are also founders in this base. This will allow D_D to keep record of all the connections that it has and better target its activities.

Status: Done :white_check_mark: + updates

Deliverables:

  1. D_D Projects Airtable base

Months 3-4

  1. Create guides and info resources that support internal projects who are looking to stand up their own infrastructure (i.e. multi-sigs) and entities (i.e. legal structures).

KPI/Deliverable: 5 guides/info resources created for internal projects

Effects:
With every workshop FO are creating educational presentations for D_D members to learn from. Two such files are already created. Additionally the D_D Fundraising Guide is providing additional information on mentioned topics. The work on this deliverable is not yet done and will be expanded before the end of season 1.

Status: Ongoing :arrows_counterclockwise:

Deliverables:

  1. The Requirements for a web3 Grant Application
  2. Writing a Compelling Narrative for Your Project

  1. Strengthen D_D member competencies for fundraising, including research, cultivating funder relationships, requesting funding, writing grant proposals, budgeting, and reporting.

KPI/Deliverable: 10 workshops/AMAs/office hours facilitated in S1

Effects:
Two educational workshops have already been done live on D_D’s YouTube channel. They are part of the first planned series on a topic of applying for web3 grants. More are on the way. Besides that FO from the very beginning of the season 1 are hosting regular Office Hours every Monday and Friday.

Status: Ongoing :arrows_counterclockwise:

Deliverables:

  1. D_D Fundraising Workshop #:1 The components of a great grant application
  2. D_D Fundraising Workshop #2: Write a Compelling Narrative for Your Project

  1. If time and capacity allow, actively support DAO members in fundraising.

KPI/Deliverable: TBD

Effects:
Connecting D_D’s founders with relevant fundraising entities had just started. First steps are being made between Eden & P3RKS with Push. First steps are being made between D_D Academy and ETH Foundation. FO are exploring possible cooperation with Gitcoin and the Graph regarding fundraising opportunities for D_D members.

Status: Ongoing :arrows_counterclockwise:


Other outputs

  1. Separate section for Fundraising in Developer DAO had been created in the D_D’s wiki.
  2. The Fundraising Operator Role description Notion page had been created.
  3. FO started hosting regular Office Hours on D_D’s Discord server every Monday and Friday.
  4. Every daily meeting of FO, Office Hours meetings, meetings with grantfunders and meetings with D_D members are being documented with relevant notes on (see below).

Notes:

  1. Google Doc with all minutes from integral Daily meetings of Fundraising Operators (also on Notion):
    FO Internal Meeting Minutes

  2. Google Doc with all minutes from Fundraising Operators Office Hours meetings (also on Notion):
    FO Office Hours Meeting Minutes

  3. Google Doc with all minutes from Fundraising Operators <> D_D members meetings:
    FO <> DAO Members Meeting Minutes

  4. Google Doc with all minutes from Fundraising Operators <> External Projects Teams meetings:
    Fundraising Operator <> External Projects Teams Meeting Minutes

  5. Google Doc with all minutes from The Steering Committee meetings:
    The Steering Committee Meetings Minutes

  6. Google Drive folder with Fundraising Operators’ Public Resources:
    Fundraising Operators’ Public Resources

1 Like

Allocation Revisions (Optional)

Fundraising Operators (FO) request 2000 $CODE to be spent on DeWork bounties incentivizing making connections between grantmaking organizations and FO. This budget assumes that max 20 connections can be achieved this way before the end of season 1.

The idea is that people that already have connections in different organizations can get rewarded for introducing FO into these organizations.

Specifications:
For one connection a person can gain 100 $CODE. This connection needs to be new which means that is not part of the D_D’s Friendly Funders Report and have grant or funding programs. The task will be considered delivered when the intro meeting with FO will be done and the organization has in fact active grant or funding programs. This condition means that an applying person needs to make sure first if the organization has those programs running before contacting FO.

After bringing this idea forward on the Discord few members supported its implementation and hence it was presented at the DAO Coordination Call on which everyone agreed with its implementation.

CC: @kempsterrrr