Kyle Bateman <kyle@actarg.com> writes:
> [ lots of good thoughts snipped ]
> 2. Take bids from the development team in advance on each feature. In
> other words, how many dollars would they need to start on the
> enhancement today.
I don't think that's very practical; the "bids" will be changing
constantly. For one thing, many user-level features will change in
difficulty depending on what other things have been completed.
For another, a developer might unexpectedly find himself with spare time
on his hands ... or a sudden need for cash ;-) ... which might induce
him to pick up some feature request that he hadn't been excited about
doing before. In the terms you're using that'd correspond to an
unpredictable drop in the bid price.
Before I comment too much on this topic I should probably mention that
I have myself engaged in exactly this kind of transaction: a few months
ago, someone who need not be named here sent me a couple hundred bucks
in return for my dealing with a Postgres problem that they needed fixed
pronto (ie, within a week or two). It was something I would have fixed
anyway, eventually, but it was worth their cash to encourage me to deal
with that issue sooner rather than later. So I've certainly got no
moral objection to arrangements like this.
But I do have a practical concern, which is that bidding like this might
distort the development process, for example by tempting someone to put
in a quick-and-dirty hack that would provide the requested feature and
yet cause trouble down the line for future improvements. In the long
run that's not good for the health of the project.
I'm not sure how to answer that concern. One possible answer is to
put a cap on the amounts bid --- a person's judgment is less likely
to be swayed in the wrong direction by $$ than $$$$$$, no? But the
cap would probably have to vary depending on the difficulty of the
proposed feature. I don't think we want to get into spending a lot
of effort on cost-estimating everything that's on the TODO list,
so administering a bid cap might well be impractical.
Maybe there's a better answer. No good ideas at the moment...
regards, tom lane