completely agree this could be the ideal situation but we do not have the treasury funds to make this a reality at the moment. i hope that after S1 or maybe S2 we are in a position where we have the funds to support people to work on these FT but i don’t think that is possible now.
think 50/50 might be a good starting point for the split but don’t think we should enforce this it should be guideline and what projects decide needs to be justified in their budget application process which the community can then weigh in on during the process.
I also share in the intuition that these ‘DAO-level’ projects’ revenue should primarily go towards the treasury. In the case of the pallet (jobs board), the contributors (we) were just unlocking latent value in the community so feels like that is where that value should go.
Though, given the service to the DAO that a ‘DAO-level’ contributor has provided, perhaps (in jobs board case at least) they should be rewarded via a one-time (retroactive) $CODE bonus that’s voted on by the community? However, this assumes that the contribution has not been priced in via early contributor rewards, which is questionable!
suggested $CODE hourly rate is now $20 and increased the default % added to guild and projects budgets for adhoc contributions to 50% as per conversations in Governance call last week. this leaves 176.666.67 $CODE available for other initiatives.
ultimately the guild should be able to define their own roles. that said, some standardisation and consistency could make things easier across the DAO on at least a couple of levels:
onboarding people across multiple guilds/projects (much easier if the structure is similar)
budget applications are easier to calculate and also for members to understand as they’re not trying to parse lots of totally different structures to figure out if it makes sense
broadly speaking i think how you’re thinking is aligned with this proposal though. regardless of what terminology is used initiatives/projects, operational/contributors. Guild roles are to make the guild function, project roles are to drive against outcome driven initiatives, however that plays out for MBD guild in theory should be fine in this model
my personal reservations about this are that if we do this for one project we’re may need to do it for all projects and it is not clear to me how most projects would calculate their budget retrospectively. i suspect we’d end up with wildly different budgets and that would cause a huge debate and stagnation in moving forward with rewards generally.
appreciate this means that some contributors may not be fairly rewards for their contributions to date, best advice would be to follow @willblackburn advice on how to allocate code during the Early Contributors rewards process:
Start with your immediate team and those you have collaborated with directly since the beginning of Developer DAO. These members should receive the majority of your votes (as long as that makes sense).
Think about contributors who have made a DAO-wide impact.
Look for contributors whose contributions are undervalued by the current GIVE distribution (see the Map tab in Coordinape for a visualization of the current distribution).
Distribute some of your GIVE immediately and then distribute the remaining amount towards the end of the Epoch to help those that are not opted-in at first!
I’m going to draft an example budget proposal for the Operations Teams to be used alongside this proposal to provide more context as to how this process should work. Will also be looking at the hourly rate calculations again and considering in more detail how revenue of “DAO Level” projects might be handled. Would still love feedback here for anyone else with further thoughts.
some questions added to the doc by (i think) @aabugosh which I’ll copy in here and reply too:
@aabugosh question
This seems to cause many issues later on, prefer to have a way to measure using some app or API if something like that is available
definitely imperfect but we need a solution that works to get things going. whilst some things maybe able to be tracked like this (i.e. a Github PR) how do we then calculate the value of that work item? whilst on the surface this kind of approach seems to be cleaner there are lots of unanswered questions that come up we’d need to invest a lot of time in answering.
@aabugosh
What happens at the end of the 4-Year period? Do we mint more $CODE tokens?
this is a really good questions. this proposal doesn’t attempt to answer this question but it was noted at the bottom it would be good to get debate on this exact topic so thanks for raising. there has to be some kind of vesting schedule and 4 years felt about right after the calculations.
as for what we do when the $CODE runs out. there is a mint function in the contract so in theory we could mint more, i’d personally like to figure out a way to get $CODE back into the treasury but not clear how we’d do that.
I think self certifying time is prone to abuse and wide variance due to people being at different points in experience.
Personally I think that the related guild leader & project champion should evaluate tasks that need doing and assign values to them - effectively turning hourly $CODE rates into bounties. Tradeoff is that you then want to make sure people have the chance to take things on and not get crowded out of paying work by someone who can snap up the best bounties upon release - but you also want to make sure things get done and that we can effectively pay people who are putting in fulltime-equivalent task accomplishment.
completely agree with these points however we don’t currently have a better approach that is properly scoped. tightly linking $CODE rewards to value produced is the ideal but we don’t have any answer for this fundamental question to work using that model:
How do we calculate the reward value of a task?
this is particularly challenging when there are lots of different tasks that are “worthy” of reward. i.e. someone might commit code to a project, another person might design something for a project and someone else might be part of a team that help with onboarding. i don’t currently see a way of “fairly” rewarding people for these tasks and i expect if we tried this approach off the bat we’d likely find ourselves stuck in Governance debating project budgets for far too long.
the above proposal suggests using the hourly calculation as a baseline for budget applications and then doubling this, leaving it up to guilds and project to experiment with how they allocated the second half via maybe bounties or coorindape rounds.
would love to see an attempt to answer the above question though! ultimately as we mature i think we’ll probably move away from this hourly model but doesn’t feel like we’ll be able to “fairly” do that anytime soon.
caveat that i understand the hourly rate isn’t fair as value produced per time is not flat however it is even and provides us a clear framework on which to move forward.
So I just recently stumbled across Orange Protocol. I am not really a technical guy, but their promise on introducing reputation metrics on blockchain and based voting on that seems very promising. Snapshot wants to partner with them.
I will be looking into it further this week, but I am leaving the link to their docs here as I know there are much more talented people in D_D that could really extrapolate the value that this protocol might give us.
I am posting this, because it seems like it solves the main problem on how to fairly distribute tokens.
Btw I also think that every task before doing it, should be assigned a price bounty in $CODE. There should be a document with tiers of different tasks and how much $CODE such activity should reward. Such document should be accepted by on-chain voting by the community. It could later on be updated next seasons if need be.
Based on that document rewards in $CODE might be attributed in reverse, but one person would have to divide them into tiers and later show community for acceptance.
update figures to reflect this