> Sadly, voting is going to get less relevant, rather than more. As we move
> towards Mozilla 1.0, there will be fewer cycles for everyone's favourite
> unimplemented cool feature as engineers concentrate on less sexy things
> like crashers and dataloss bugs.
I'm not sure I completely understand this. If more work is being
done on crashers, etc. then there will end up being less (tending
towards, hopefully, 0) of them. The fewer number of crashers, the
GREATER amount of time that people will have to work on non-crash
related bugs. Some comments on this thinking:
1. Okay, if all development is forced to be only on crashers and
dataloss bugs I can see how people will not be able to work on
anything else until there are actually 0 of these. But, immediately
after that, since there is nothing else, voting should become
extremely important. So why not advertise that people's votes count?
2. Isn't there something wrong with the process when crashers and
dataloss bugs aren't ALWAYS the first priority in development? Why
should a completely arbitrary "1.0" release suddenly change
development priority? This is akin to saying that sloppy work is
perfectly acceptable up until the point when the boss walks by. If
there is no process in place to ensure that such things always have
top priority then there's something wrong.
Jason.
