On Sun, Aug 28, 2016 2:05 PM, Matthew Toseland mj...@cam.ac.uk wrote:It doesn't always work. Sometimes it is necessary to make a start on the
big-ticket items, even though they're costly. If their value justifies their cost, and each is estimated with some degree of accuracy, then this approach will prioritize big-ticket items. The classic example of this is market failure in carbon credits: Carbon trading finds the "easy wins" very quickly, but it's very poor at things like encouraging building new wind farms rather than coal plants. In fact it's so bad at this that an entirely separate mechanism is needed in the electricity sector. Not to get offtopic, but carbon credits are an entirely artificial market, so any failure is probably a failure in how the market was set up, rather than in the concept of a market itself. But this is offtopic. Does this reasoning apply to Freenet? Well, there are some fundamental problems that should bear a high priority even though their immediate visible impact to users may not be that spectacular. Security improvements are an example (e.g. deploying Arne's darknet security fix). Although here, darknet usability/performance enhancements are the big one. Not only do they improve security, they may actually help to get us some viral growth. Winning all around... Really that sort of thing just means you've under-estimated the value of a big task. Which is bound to happen, but I'm not sure how to avoid it... This just assumes that participants will make bad value decisions when they provide their estimates. Seems unnecessarily pessimistic. Ian. Ian Clarke Founder, The Freenet Project Email: i...@freenetproject.org On Sun, Aug 28, 2016 2:05 PM, Matthew Toseland mj...@cam.ac.uk wrote: On 28/08/16 19:48, Ian Clarke wrote:
On Sun, Aug 28, 2016 1:32 PM, Matthew Toseland mj...@cam.ac.uk wrote:
On 28/08/16 19:29, Ian wrote:
On Sun, Aug 28, 2016 at 1:23 PM, Matthew Toseland <mj...@cam.ac.uk>
wrote:> That's not what was asked. My prioritization proposal
separates the
estimation of the value of completing a task from the estimation of the
task's cost. These can then be combined later to come up with a
prioritization.
Which will inherently prefer "easy wins". Which is probably a good
thing.
I agree. The principle is very simple, maximize value relative to
cost. Then all
you need is a way to estimate value and cost, these are hard problems
in the
general case but I think our approaches will work well.
So, if anyone disagrees with the approach, either they disagree that
we must
maximize value relative to cost (I'd love to hear that argument), or
they need
to propose a better approach to estimating value and cost.
It doesn't always work. Sometimes it is necessary to make a start on the big-ticket items, even though they're costly. The classic example of this is market failure in carbon credits: Carbon trading finds the "easy wins" very quickly, but it's very poor at things like encouraging building new wind farms rather than coal plants. In fact it's so bad at this that an entirely separate mechanism is needed in the electricity sector. Does this reasoning apply to Freenet? Well, there are some fundamental problems that should bear a high priority even though their immediate visible impact to users may not be that spectacular. Security improvements are an example (e.g. deploying Arne's darknet security fix). Although here, darknet usability/performance enhancements are the big one. Not only do they improve security, they may actually help to get us some viral growth. Winning all around... Really that sort of thing just means you've under-estimated the value of a big task. Which is bound to happen, but I'm not sure how to avoid it...
Ian.
Ian Clarke
Founder, The Freenet Project
Email: i...@freenetproject.org
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl -- Ian Clarke Stacks - The AI CFO for your personal finances http://trystacks.com/ _______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
