On Mon, Oct 7, 2013 at 7:56 AM, Rob Weir <robw...@apache.org> wrote:
> On Mon, Oct 7, 2013 at 10:43 AM, Herbert Duerr <h...@apache.org> wrote:
> > On 07.10.2013 16:20, FR web forum wrote:
> >>
> >> Some issue seems to be without possibility of vote.
> >> Like: https://issues.apache.org/ooo/show_bug.cgi?id=99429
> >> Why?
> >
> >
> > I guess this has to do with the product specific settings. For the "App
> Dev"
> > product the "Maximum votes per person" has been set to zero. I don't know
> > whether the creator of that product category intended it that way or
> whether
> > it was an oversight.
> >
> > Almost all other products categories allow 5 votes per person and a
> maximum
> > of two per bug in that category. Other products with no votes allowed are
> > "Native-Lang", "qa" and "marketing". I guess for all of them voting
> should
> > be enabled. Unless someone disagrees I'll assume lazy consensus in 72h.
> >
>
> There are three settings related to voting for each product:
>
> Max number of votes a user can make for bugs in that product
> Max number of votes a user can make for any one bug
> Number of votes needed to auto confirm a bug
>
> Most products have these values set to 5/2/5.
>
> Some have it set to 0, as Herbert mentions.
>
> But Base, for some reason, has these values set to 5/2/10.
>
> So two questions from me:
>
> 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.
>
no...no "auto-confirm". As some of these bugs may be very old...we need to
(re)confirm them including the version of the confirmation IMO.
>
> 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.
>
This sounds good. We have MANY users on MANY different hardware setups. We
should allow for a reasonable number to participate in the decision making.
I think these new suggested values are good.
>
> -Rob
>
> > Herbert
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > For additional commands, e-mail: dev-h...@openoffice.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>
--
-------------------------------------------------------------------------------------------------
MzK
"Truth is stranger than fiction, but it is because Fiction is obliged
to stick to possibilities. Truth isn't."
-- "Following the Equator", Mark Twain
