There are multiple reasons for this:
1) Overall the program has got mature enough and actually usable;
2) Betas are not allowed to some software catalogs, most notably download.com;
3) Some people wrote to me asking to get rid of beta because betas are not allowed by their "nazi" sysadmins at work
But before we start picking features for the next release, I'd like to return to the issue of the priority scoring formula.
The last formula was suggested by Midas:
I came to realize that this formula exhibits some really strange behavior, look:Midas wrote: I summed the wheighted pro vote (asap*2+nice) and divided by the poll sommatory (total number of people voting on the issue); then, I did the same with the contrary vote (no need+don't do it*2).
score(asap = 1, nice = 0, noneed = 0, dont = 0) = (1 * 2) / 1 = 2.00
score(asap= 20, nice = 1, noneed = 0, dont = 0) = (20 * 2 + 1) / 21 = 1.95
Is it really fair that one (!) "asap" vote outweighs 20 "asap" votes and a "nice" vote?
I think a better formula would be to multiply the simple score (asap*2 + nice - dont*2 - noneed) by the percentage of pro votes relative to total number of votes, that is:
score = (asap*2 + nice - dont*2 - noneed) * (asap + nice) / (asap + nice +dont + noneed).
For the examples above is gives:
score(asap = 1, nice = 0, noneed = 0, dont = 0) = 2 * 1 / 1 = 2.00
score(asap= 20, nice = 1, noneed = 0, dont = 0) = 41 * 21 / 21 = 41.00
which I think far more accurately reflects the real priority. What do you think?
No, my suggestion is also not the best idea, since it actually reduces the negative effect of downvotes.
Actually the simple formula is ok, but we want to:
1) give more weight to unanimity so that (10, 1, 0, 0) scores more than (10, 3, 0, 1)
2) give more weight to "popular" features with many voters - I think we should just add something like (0.01 * total_voters) to the resulting formula to take care of this. Adjusting the constant will allow us to give this parameter more/less weight.