sanity/FreenetFundingAllocationProposalv0.1.md Secret

## FreenetFundingAllocationProposalv0.1.md

      
    Raw
  

              FreenetFundingAllocationProposalv0.1.md
            
          
    Funding allocation

By Ian Clarke, May 3rd, 2016
While this extremely generous donation of $25,000 by DuckDuckGo is hugely beneficial to the project, it also presents us with a challenge — how do we allocate these funds to most benefit the project?
I believe this funding should be sufficient to get Freenet to the point where it is ripe for mainstream adoption, but this will require making significant progress in a number of areas including (in no particular order):

Speed
User friendliness
Security
Technical debt
Outreach

There is particular risk here for us due to the decentralized and democratic way the project operates.  They say a camel is a horse designed by committee.  We need to avoid falling into that trap, but without resorting to a more autocratic style of project management.
Over my 15 year career I have managed a number of software projects, predominantly in a commercial environment.  Over this time I’ve gained quite a bit of experience in the problem of resource allocation, and formed some strong opinions on the subject.  In fact, I’ve actually considered writing a book on the subject some day!
I’d like to propose an approach for democratically determining an order of priorities for the project.
Firstly, how should resources be allocated to work on tasks in an ideal world?
Let’s imagine that, in this ideal world, we can assign a numerical value to every task, perhaps a value between 1 and 1000, where a task with value 10 brings exactly twice the value of a task with value 5.
You might say that we should sort the tasks in descending order of priority, and start at the top.
But this is missing half the picture.  In this ideal world we can also predict the exact cost of delivering on any task.
So imagine a task with value 5 which would require $10 of work, versus a task of value 15 that would require $1000 of work.  Which should be worked on first?
I believe the actual metric we should prioritize by is value per unit of effort.  That way, something that might not be very valuable but which can be achieved easily will be worked on first.
So, in our ideal world, problem solved!  Of course we don’t live in that world, so what do we do?
Both value and effort are notoriously difficult to estimate, even for experienced engineers.  My proposal for solving this is to exploit the wisdom of the crowd.
In machine learning it has long been known that if you combine a bunch of inaccurate predictions, provided that those predictions are inaccurate in different ways, you can combine them to get an accurate prediction.  It’s called the “ensemble method,” also known as “democracy”.
My Proposal

Broad task areas

Firstly we need to come up with a list of the broad areas where we can spend resources, I would propose the following as a starting point:

Speed
User friendliness
Security
Outreach
Technical debt (a catch-all for all the stuff in our bug tracker that doesn’t fall into another category)


Specific tasks

Then, within each of these areas (except technical debt), people should propose specific non-overlapping things that would provide value towards that broad goal.
I don’t think we can simply take what’s currently in the bug tracker, these things are too specific, and there is probably a lot of noise in there.
Each task should include a clear explanation of the value, and as much as we can say about what it will take to achieve it.
At this stage we don’t need to debate the importance or difficulty of any of these tasks, but we will need to work to ensure that they aren’t too specific, are clearly defined, and that they don’t overlap.

Estimate value

For the next stage, every participant gets 1000 units of “value” to allocate between the different tasks, starting from an equal distribution of units between the tasks.
A few important things here to ensure we get the true benefit of “wisdom of the crowd”:

Don’t be strategic (eg. don’t over-allocate to one area because you assume others might under-allocate to it)
Don’t collude
Don’t consider difficulty in your value allocation
If you aren’t sure, leave stuff at an even allocation, don’t assign 0 value

Once everyone has allocated, we take the average for each task to be our group estimate for that task.

Estimate cost

For simplicity we will use currency to represent cost, but can agree on how this translates to man-hours.
We invite participants to choose a cost for each task, but limit the choices to a set of values like this: $10, $20, $50, $100, $500, $1000, $2000, $5000.
You pick whichever you think is closest to the actual value.  This way people don’t get too hung up on whether it is $20, or $23.
Again, we take the average estimate for each to be the actual cost.

Putting it all together

Now we have our value estimates, our cost estimates, we can calculate a cost-per-unit-value for each task, and get our priorities.
Of course, there will be dependencies, and not everyone can work on every task, but if from now we follow the general principle that you pick the highest priority thing to work on that you’re capable of working on, we should be good.

How to do this in practice

I have further ideas on which online tools we can use to implement this, I’m thinking Google Docs, but let’s agree on the principles before we get too much into the mechanism.