Soil 🌱 - Budget Update - NOT OFFICIAL

[BluePanda]

Addressing the comment posted by @luan

@luan

it’s just occurred to me — but I’d actually suggest increasing the budget to include rewards for non-team members who contribute towards its development. the weekly sync meetings are less of a one-way communication by the team, but more of an engagement session with potential users. I’d wager that these sessions are quite important for the project, as its targeted users are being brought into the innovation process. and it’s more than giving feedback over the call, but going through interactive exercises via Miro.

I’d benchmark participation by:

• attending the audio call — 15 $CODE

• work done in Miro during the call — $15 CODE

• work done outside of the call, on Miro — $15 CODE

and the comment posted by @pbillingsby.eth

@pbillingsby.eth

19 contributors * 13 hours a week * 15 $CODE/hour * 12 weeks + 3000 $ CODE bounty budget = $CODE 47,460

Doesn’t s1 consist of 16 weeks?

---

Thank you so much @luan and @pbillingsby.eth, this is a great idea! It’s unfortunate that we didn’t think of it earlier in order to include it on the original proposal before the vote.

For now, let’s launch an unofficial vote and see what the community thinks and if people agree budget for this initiative should exist. IT’S NOT AN OFFICIAL VOTE.

We’ve thought through the comments very deeply and decided the only fair way around this would be to compensate those, who spend a minimum of 1hour contributing to Soil . It can be anything from going over UX with the design team, advising on the looks of UI, researching web3 technologies, diving deeper into smart contracts and protocols, giving advice, or having a hands-on session with one of the core contributors, etc. We decided to refrain from rewarding people based on call attendance. It is important for us to preserve natural interest around Soil weekly syncs. After all, Soil platform will be used by the community. That being said, we are actively looking for outside help. On our weekly sync call on Tuesdays, we will be announcing tasks that need help from our community and each task will be compensated. Here’s our proposed budget breakdown:

---

19 contributors * 13 hours a week * 15 $CODE/hour * 16 weeks = 59,280 $CODE

(3000 $CODE bounty budget)

((15 $CODE) ) * (2 hour) * (16 weeks ) * (7 people average) = 3,360 $CODE

= $CODE 65,640

---

Please if anyone can help us on what is the correct way to approach this subject DM me at BluePanda#5982 we will be happy to take this post down and replace it with the correct approach

Thank you D_D for understanding

NOT OFFICIAL VOTE

• Update Budget with both suggestions
• Update Budget only with community contributors (task completion)
• Update Budget only with 16 weeks instead of 12-week suggestion
• Don’t update Budget

[luan]

@BluePanda

We decided to refrain from rewarding people based on call attendance. It is important for us to preserve natural interest around Soil weekly syncs.

That’s a fair point. I agree

[vorcigernix]

Sorry, but I have to disagree. There is no way to compensate for the time of people attending these activities. This is pandora’s box and I strongly believe that only people driving the project forward should be rewarded. If we do this proposal, why don’t we reward mentees attending mentoring?
I think that we always distinguish between the project members and people helping the project voluntarily.
Another option would be to present a project plan with some rough estimation and ask for a budget not attached to the team members but to the plan itself. In other words, it should be “people and material” or “fixed price+scope”. I generally prefer prior, but this looks to me like presenting this type of budget to the client and involving incentives to the client employees for participating.

[BluePanda]

thank you so much for taking the time to voice your opinion! This is really helpful

So you agree to update the budget for the mistake that happen on the original calculations “we thought that the season is 3 months and after all, is 4 months” (@pbillingsby.eth found this mistake)

but you don’t agree with rewarding community contribution via task completion,

correct?

[vorcigernix]

yea, marked wrong answer, sorry

[Erik_Knobl]

I’m on the side of this. I understand the reasoning behind the idea of rewarding everyone, but I would dislike creating a level of people getting CODE just for showing up.
Soil has a genuine level of engagement with the community, and that’s awesome, but giving incentives may only distort it.

[luan]

@vorcigernix

This is pandora’s box and I strongly believe that only people driving the project forward should be rewarded.

unless I’ve misunderstood something, that is exactly what’s being proposed, here. correct me if I’m wrong, please @BluePanda

@vorcigernix

If we do this proposal, why don’t we reward mentees attending mentoring?

mentees are obtaining a benefit from the mentorship dynamic. or at least, there’s an expectation around a benefit being derived from it. some of the attendees during the Soil weekly meetings, participate in activities and discussions which inform the innovation process; thus helping to drive the project forward. that is value being contributed. there’s little similarity between them and a mentee — where the former receives value, and the latter contributes value.

[vorcigernix]

@luan

mentees are obtaining a benefit from the mentorship dynamic. or at least, there’s an expectation around a benefit being derived from it. some of the attendees during the Soil weekly meetings, participate in activities and discussions which inform the innovation process; thus helping to drive the project forward. that is value being contributed. there’s little similarity between them and a mentee — where the former receives value, and the latter contributes value.

True. That was an unfair example to pick.

[luan]

another thing I’ll say, is that one of the things web3 allows for, is re-contextualizing how value is ascribed to things.

in a traditional corporation, you can contribute value to different teams across the organization but you’re still only paid and tangibly recognized for what work you do within the role you’ve been hired for. it is very vertical in nature; meaning that you must move up into certain roles if you want to be recognized for your contributions to them.

whereas web3 has ways to reward value, irrespective of where you reside in an org. so contrast to the former, it is more horizontal in nature. i.e. you can move across the org and add value and be tangibly recognized for that.

when we’re speaking of public goods, and decentralized structures; it is helpful to learn from (the well-over-a-century-worth of) lessons that have been set by solidarity communities and other ‘decentralized’ structures. I’ve mentioned this a few times in the past week alone, but they’ve laid the groundwork. and I’d encourage people to learn about them. historically, the philosophy around decentralized structures, co-operatives, solidarity communities/networks etc has been about equity. specifically: how to make a community more equitable for its members?

if value is being created, then that constitutes a contribution. equitable remuneration has to factor in both: time spent, and value contributed as a bare minimum. yes there’s organic interest from Developer DAO members in the prospects of Soil but rewarding people who actually provide value by participating in exercises that drive the project forward, does not undermine the integrity of what’s being done. at least, not in my opinion. the way I view it, is that you can’t fake value; either you’re contributing it, or you’re not.

and so the belief that genuine interest should somehow be predicated on free labour by ‘early users’ is both arbitrary and ethically questionable. it also runs contrary to how a lot of solidarity/decentralized structures have operated, historically. from my own experience and observations, it is more of an ideology that’s been popularised within the startup space over the last decade and a half or so.

[Milo.io]

Thank you for taking time to reply @vorcigernix & @Erik_Knobl!

I’m with you on the fact that we shouldn’t pay people to attend the call because it will create an unhealthy ‘interest’ around it and we want to preserve genuine engagement around the project. Taking into consideration the fact that Soil🌱 is a community project and we need a lot of outside help to keep it real we’ve proposed an additional budget for the quick tasks that competent people can complete and be rewarded for. These tasks will be posted in DeWork and announced on a weekly sync calls.

Does it make sense to reward those, who occasionally contribute for 1-2h, but not a permanent member of the Soil team?

[Erik_Knobl]

Totally. Bounties are excellent starting points for new members, and also interested builders unable to commit for extended periods. Fully support them.

[Milo.io]

that’s what we were going for in this unofficial proposal. Wondering if we should highlight it even more, so people know what we’re voting for:)

[luan]

@Milo.io

Wondering if we should highlight it even more, so people know what we’re voting for:)

yeah, it’s probably a good idea to do so

[julo.eth]

It is a difficult situation because it can sometimes be hard to define ‘value’ in the context of some of these tasks, but is undeniable that value is given to the project through them. There is on the one hand the possibility that someone may ‘game’ the system to receive a CODE allocation, but you do not wish to miss out on valuable information and input from the community.

From reading through some of the tasks, there seems to be two types of input - ‘community’ input ie user sessions through audio calls and Miro, and ‘expertise’ sessions with UI, web3 tech, smart contracts, hands-on sessions etc. it may make sense to grade these differently.

Instead of defining by hours, you could maybe allocate a CODE pot for the week that is available to meet the needs of these type of tasks. The ‘Community’ pot or something to that effect.

1. Community inputs may receive smaller CODE allocations initially and could potentially multiply by time spent on this type of work, or the number of sessions participated in. The longer someone spends helping out, testing, discussing and getting involved that way, they are rewarded higher.

It may filter out people looking for a reward by making ‘quick wins’ not worth their time whilst incentivising those who are really interested in the direction of the project long term.

2. Expertise inputs could follow a bounty route, or increase / decrease depending on the perceived value of the advice or service provided as judged by the core team. How do you quantify a half hour call around smart contracts that changes the course of the project for example? It’s really the core team that can place the value on that.

I suppose what I’m getting at here is that there are tasks that involve the communities time, and tasks that involve the communities knowledge. Both are equally as valuable to the progression of any project and its great to utilise the different skills and people the DAO has. Maybe you won’t use the whole Community Pot over the course of the week, you could roll it over to the next week or reward individuals further with it.

[vorcigernix]

Absolutely. That wasn’t clear to me.

[BluePanda]

Really insightful and rich information response thank you!

@julo.eth

Community inputs may receive smaller CODE allocations initially and could potentially multiply by time spent on this type of work, or the number of sessions participated in. The longer someone spends helping out, testing, discussing and getting involved that way, they are rewarded higher.

This is really smart not only because it make sense financially but because practically the more someone spent helping the more valuable he will be because he will understand deeper our values, goals code base, etc.

We are planning to solve that throw the new Role system that DeWork provide and showed to us personally the creators of the platform

@julo.eth

Expertise inputs could follow a bounty route, or increase / decrease depending on the perceived value of the advice or service provided as judged by the core team. How do you quantify a half hour call around smart contracts that changes the course of the project for example? It’s really the core team that can place the value on that.

Yes this is also a really good point, and it reminds me Coordinape that we start using as a team in order to be able to extract this type of value mechanism, of course, it cant be used here directly but we can definitely find a way to account for that in the near future