On 07.10.2013 16:56, Rob Weir wrote:
[...]
1) Does auto-confirm make any sense for us? Remember, marking
something as "confirmed" takes it off the radar for QA. But if
something is in the unconfirmed state and many users are voting for
it, shouldn't that mean that QA should give more attention to it, to
try to confirm it? If we skip over QA entirely then we miss the
opportunity they have to do additional testing of other versions,
uploading sample documents, etc. So I'd be in favor of disabling the
auto-confirmation entirely. We shouldn't skip over QA.
Agreed, issue votes shouldn't auto-confirm. Confirming an issue should
mean that someone we can trust vouches that the issue status has a
reasonable quality.
2) What values should we set of the max number of votes per product
and per bug? In one sense it doesn't really matter, since we don't
really have a view of what the top vote issues are. But if the goal
is for users to express their preferences, why not set it to 10/10/0?
In other words, let them express the fact that a single bug matters to
them most of all if they want.
10 votes per product makes sense, but it devalues the existing votes a bit.
Limiting the number of votes a user can give to an issue to 1 or 2 would
have important benefits: it encourages the voter to take a broader view
of the situation and discourages radical positions.
If there were situations where an issue was so important that working on
anything else would be a waste of time then voting wouldn't cut it
anyway. Such a problem should then become the main focus on the
development list.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
