On Tue, May 3, 2016 3:03 PM, Arne Babenhauserheide arne_...@web.de wrote:The intro shows values from 1 to 100, the later description uses 1 to
1000. Oops, fixed. I do not think 1000 points are useful in terms of limited volunteer time resources. How about making it 20? This then requires explicitly *not* putting any value on certain tasks, which is the most important decision to take here: What do we *not* need to do right now? Well, one important component of the allocation process is to start with an even allocation of points between all tasks, which discourages people from just picking one or two favorite tasks and putting all of their points in those tasks. Depending on how many tasks we have, 20 points might not be sufficient for this. But perhaps 100 is a better number, we can decide once we see how many tasks we get. As cost-metric I would suggest using full-time person-weeks. The problem is that some things we could allocate resources to might be, say, paying $600 for 99designs to come up with a new web design (just an example). Unless we have a common measure of cost for everything we won't be able to compare them. Currency is a good lowest-common-denominator, everything else should be expressible in terms of currency with some reasonable assumptions. - We have money for ~20 of these. That’s a number we can easily handle. - Cost is very different from salary (by roughly factor 2). Time isn’t. - Any feature which looks like it could be implemented in one day is likely implementable within one week. - $5000 sounds like a lot. But it’s just 4 full-time person-weeks for the people who already know about Freenet — others would have to get into the code first, so the price per feature would be similar. - There is no task which is worth the time to describe it here which can be finished in less than a week. If it can be done in less than a week, we should just do it right away instead of discussing how much time it requires. I agree that we can't be too granular with these tasks, if there are too many then people will have trouble allocating intelligently between them. However, I don't agree that if a task is less than a week's work that we should automatically do it, we might have $25k worth of tasks like that! Part of the solution is to have a “catch-all” for small “technical debt” tasks, where they might not individually have a user-visible benefit, but where the benefit is that they accelerate our development process over time, in part by reducing the likelihood of bugs. We could then have a fixed resource allocation for these, I've seen people use 25% in the past. Finally: The text is far too long. A description for the method needs to fit on a 14pt A5 page. This wasn't just a description of the method, it was an argument in favor of using the method, and some background on how I came up with the method. A simple description of the method would be much shorter. 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
