Gridcoin 2018 Budget v0.2 - Updated Feb, 5th #205
Comments
|
Rounded hours worked in 6 month period to 500 for clarification. Adding to Rationale and Execution: $90,000 USD spent on development over 6 months creates a goal of tripling rate of development. Instead of 500 hrs on development, we would expect 1,500 hours on development spread across more developers. Did not change version number for this edit. |
I may be crazy but I don't think that is 6 months. |
|
lol @ZigzagoonBalloon 8 months! Will fix. Fixed the errors -- to target the 3x increase in development hours, the proposed budget is 120k for development and to maintain the 15% outreach, 18k for outreach. 138k total. No version update for this fix. |
|
GRC should be a primary budget unit. I propose Gridcoin financial year to start in April each year. December is quite a holiday month and therefore not a good month to decide or add finishing touches to the planned budget, especially in a decentralized community project. 1,380,000 GRC proposed by @jring-o is extremely conservative and most likely will be not enough to implement solutions for several serious problems Gridcoin is currently coping with. I propose to use a general rule for a budget for the next year to be equal to 20% of the funds held by the treasury / foundation on 31 March. This will guarantee some level of long term sustainability. According to calculations, after 10 years treasury would still hold around 9 million GRC. I propose a conservative 7,200,000 GRC for the year April 2018 – March 2019 I have attached a spreadsheet simulation with the budget based on the following assumptions. Budget is divided between:
Where possible, payments would be carried in GRC. With the above assumptions total budget for this year would be as follows:
Development fund would allow for 4800 hours at hourly rate of $60. I have prepared a more detailed sub-budget only for science & BOINC fund:
|
|
Gridcoin Network Budget.xlsx - can download and edit EDIT: added online version |
|
Before I read all. |
|
@tomasbrod i agree and disagree. i love bounties. there are also time tested ways to determine what are "clockable" hours for a core dev and maintenance team. we will need this for years to come, and it might be of benefit to start working on it now. we talked a bit about this during the last hangout too, had some good ideas. they will be written down shortly we'll get there. |
|
We had an excellent discussion about the budget during the hangout on Saturday. Hesitation was expressed regarding the $18k for institutional outreach. I've kept it in for now, though it may be removed after further discussion. Support was expressed regarding the increase in developer reimbursement to 60$ hour and what that will do to bring more developers into the project while supporting the current core dev team. Here are the updates to the proposal: Gridcoin 2018 Budget v0.2AdditionsIntroductionIdeally, a budget will cover an entire year. As this is the first budget, it defines 8 months to allow for more rapid execution and a to simply get things rolling. As the proposal is developed, we may extend it to a year, as suggest by @hot-bit-git, with evaluation periods. For now, it remains 8 months with evaluation periods as defined below. If we extend the proposed time of the budget, the proposed funding will be appropriately adjusted. Evaluation PeriodWe propose putting in place a structure to continually evaluate community support for the budget. Let us break the budget into 2 three month periods and 1 two month period. No more than four weeks after the start of each period, a poll will be made in the following format:
The poll will last until the end of the budget period. A "no" result at the end of the period will close the budget's escrow wallets, at which point a new payment structure will be implemented. GRC Reimbursement PriceThe price of GRC/USD used to reimburse developers will be the average of the GRC/USD price of the previous 3 month period. EditsPriority 1 and 2 Escrow ManagementResponsibility for the release of funds from the development escrow wallet will be defined by @denravonska and @caraka. They can do it themselves, appoint people to manage the funds, or otherwise act in any way they deem appropriate. Questions Moving ForwardWhat happens if the evaluation poll results in "no"?Do we want to end the evaluation poll before the end of the period to give to implement the replacement payment structure? or do we want to have a backup payment structure? or do we want to say that we will fall back onto the previously approved payment structure -- which at this point would be the structure put in place by Rob. What constitutes work worthy of reimbursement?As @tomasbrod has pointed out, how are we going to determine what work to reimburse. Some companies do it one way, others do it another, some use a complete honor system. There are many options. What do we think will work best for us? Some ideas floating around:
|
jring-o
changed the title
|
What about making a tiered reimbursement structure: 30$/hr until X number of significant PR are accepted, at the escrow manager's discretion. This is for developers looking to become core devs and maintainers. Otherwise I like making bounties for specific issues and attracting "wandering devs" who want to complete these bounties |
|
i've been thinking about @tomasbrod's point: what if we use the budget to give the dev core team (however @denravonska and @caraka want to set it up) a chunk of GRC from the foundation to use for bounty building. For example, they get $20,000 USD for bounties and decide among themselves to direct $10,000 to a bounty for a new c++ NN, or something. |
ghost
mentioned this issue
|
I do consulting all the time, so to @tomasbrod 's question about what hours to bill... Any time you are working on it, touching it, and not able to do something else, should be billed. Typing? Yes. Solving a problem on paper while you're out? Yes. Randomly thinking while you're snowboarding? No. If you log time at 10am, noon, and 4pm, you leave gaps. Some rounding rule may be valid, such as 0.1H, or 5M, or anything around there. I personally like Toggl, since it lets me track things pretty easily, and then I just sum it all up at the end. EDIT: Just to be clear, there are always situations where you don't bill for certain things, and that varies by situation, task, and person. You have to go with your gut, but also enough respect for your own time to find the best balance. |
|
With regards to a tiered rate, my thought is, rate should depend on the skill, not the number of hours. The core dev skill does not become more or less valuable based on the number of hours they have worked. Also, if there is an increase of rate after a certain number of hours, it would encourage people in the future to try to reach that higher rate. (edited because I went on a tangent that was not relevant here.) |
|
This proposal is separate from the running poll on the wallet. Please keep that conversation on that CCT thread and keep the conversation here strictly related to the proposal posted here on Feb 1st. |
|
@jring-o , Apologies. I started with your suggestion herein about a tiered rate, but seemed to be stuck in another conversation. I edited my second comment above to remove the irrelevant info. |
|
Perhaps we need two dev buckets? Some of the work they do would be hard to set a bounty or fixed-price. Some would just be large numbers of hours refactoring code and squashing bugs. This is where I like Rob's current hourly bucket for ongoing maintenance, and a bounty system for specific additions. As to the above budget, I think setting a target of burning through 7.5M GRC is a bit ambitious. I worry that some of this seems premature. How much of the above is based on the 2017 expenditures, and outstanding plans? |
|
Many questions answered here: https://steemit.com/gridcoin/@jringo/let-s-talk-money-regarding-the-current-developer-poll Look in the comments for math. |
|
new version at #225 |
Based off of the treasury outline found in #202
Based off of the budget outline found here.
@hot-bit-git
We need a budget. This is a start. Everything in it is open to discussion. I am basing this process off of @G-UK's whitelist proposal. I will update this document as we discuss it.
A budget is one of the most crucial parts of any organization -- from a 3rd grade recycling club to Amazon Inc. A budget is, at the basic, a systematic method of allocating financial, physical, and human resources.
How the budget allocates these resources should represent the goals and needs of the organization for the time covered by the budget.
So let's start there and move through some introduction information before getting to the proposal.
Introduction
How long will this budget cover?
Let us assume we can build and pass a budget by the end of April. If we can do it sooner, awesome.
Let us then say that this budget will cover the remaining fiscal year of 2018, or May 1st - December 31st.
What do we need to do in this time?
We need a list of priorities and goals. This list can be informed by the following polls:
Current GRC Problems 1
Current GRC Problems 2
Roadmap Poll: Securing Superblocks
Roadmap Poll: Reward Payment Method
Roadmap Poll: PoR Blockchain
Roadmap Poll: Determining Magnitude
Roadmap Poll: Solving the Stake Weight Problem
Along with the sentiments of long standing community members.
I propose the following list of priorities:
Each of these priorities is then broken into sub-priorities defined by those who know the corresponding responsibilities the best.
For example, developers would create the priorities for development. That list might look something like this:
2018 Development
How much money do we have?
As the treasury system is going to take a fairly long time to develop, we have to operate under the assumption that we will be using Foundation funds for the 2018 budget.
The foundation has between 32 and 37 million GRC -- if anyone has an exact number, that would be appreciated and I will update this budget accordingly. For now, let us take the more conservative of these numbers and say that we have 32 million GRC.
At an average price of 0.10 USD/GRC, this is $3.2 million USD.
How much money have we spent so far?
As best as I can calculate from the expense reports, we have spent $14314.5 on 477.15 hours of work between July 1st 2017 and December 31st 2017.
Let us round the hours worked up to 500 hours in the 6 month period. That's 83.3 hrs/month.
If this trend continues, it can be said that we have development expenses of about
Monthly: $2,500
6 Month Period: $15,000
Yearly: $30,000
The Proposal
Introduction
Ideally, a budget will cover an entire year. As this is the first budget, it defines 8 months to allow for more rapid execution and a to simply get things rolling. As the proposal is developed, we may extend it to a year, as suggest by @hot-bit-git, with evaluation periods. For now, it remains 8 months with evaluation periods as defined below. If we extend the proposed time of the budget, the proposed funding will be appropriately adjusted.
Budget for May 1st 2018 - December 31st 2018 -- 8 months.
Priorities:
Total Funding: $138,000 USD
The price of GRC/USD used to reimburse developers will be the average of the GRC/USD price of the previous 3 month period.
Allocation: 85% to Development and Developer Outreach, 15% to Institutional Outreach.
Rationale and Execution
Priorities 1 and 2
To properly compensate current developers for their time and to help attract new high-level developers, let us increase the development budget to $120,000 for this 8 month period.
Let us use this increased budget to double the hourly compensation rate for developers to $60/hr. This creates an expected development expense of $40,000 for the next 8 months, or 666.67 development hours. Let us use the remaining $80,000 to pay for an expected increase in rate of development. Rate of development is the same as total hours spent on development.
This increase in development funding leaves $80,000 open to be claimed by additional development or developers. Instead of 83.3 development hours/month, we would expect a 3x increase to 250 hours of development a month.
These funds would be held in escrow and released at the discretion of the core development team led by @denravonska and @caraka and whomever they choose to place in positions of fiduciary responsibility.
The internal list of development priorities would be defined and published by the core development team led by @denravonska and @caraka and whomever they choose to place in positions of organizational responsibility.
Priority 3
To help attract reputable institutions, let us add an additional 15% of our development budget to institutional outreach. This amounts to $18,000. These funds would be held in escrow and released at the discretion of an outreach board to be formed upon the approval of this budget.
The internal priorities of the outreach board would be defined and published by the board members given the responsibility. They might be things like:
The process for forming this board needs to be defined.
As an initial proposal to work from:
I propose that the community vote on a board leader who then appoints additional board members who must then be approved by the community.
Evaluation Period
We propose putting in place a structure to continually evaluate community support for the budget.
Let us break the budget into 2 three month periods and 1 two month period.
No more than four weeks after the start of each period, a poll will be made in the following format:
The poll will last until the end of the budget period.
A "no" result at the end of the period will close the budget's escrow wallets, at which point a new payment structure will be implemented.
Change Log
v0.2 1/5/18
Added changes from #205 (comment)
The text was updated successfully, but these errors were encountered: