Where can I find this Initiative-Leads channel @Erik_Knobl
here goes the link:
Iâm blind typing this, sorry for typos. I disagree with the line dividing those two roles. The reason why you donât have CFO running the companies is that it would create a wrong incentive. He will guide the company to a great money saving process - immediate death for most of thecompanies. We donât need to copy how companies work, but if this is the jobs to do with a full time allocation, Iâd say that the fund raising person should have the financials (and the system needs to be transparent enough to avoid misuse).
2 Likes
I personally believe $8,000 + $5,000 in $code seems high and I understand the idea behind these roles creating new processes and infrastructures but I believe that a lot of contributors do engage in the creation of new processes and even core contributors are not receiving up to 5,000 in $code, just seems a bit unfair to many people who put in a significant time commitment to the DAO who may not fall under an operator title or initiative lead title.
3 Likes
With no nominations and the deadline passed, does this effectively mean all previous operators have been fired by governance failure?
Are we expecting current operators to keep working for free?
When did we vote to give control to these âbudget stewardsâ?
So much is wrong with this proposal and process.
VOTE NO
A close reading shows this proposal doesnât even make sense. It even gets our name wrong! Weâre âDeveloper DAOâ, NOT âDeveloper_DAOâ ! What is going on here?
1 Like
fired by governance failure
No, this means that their terms have come to an end as previously defined via governance. This was designed to require defining continued involvement and deliverables.
Are we expecting current operators to keep working for free?
This proposal has been created to compensate operators.
When did we vote to give control to these âbudget stewardsâ?
This is in the scope of the proposal itself and also defined in another ongoing proposal: [DRAFT 2] Rewarding Contributions in $CODE.
Thank you for putting this together, Erik.
I think some clarity around current and projected cash flow linked to this would make it easier to vote on the proposal.
Directionally, I support this proposal. My lack of clarity is more on the financial feasibility of the exact dollar amount being paid to 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.
