You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by FR web forum <oo...@free.fr> on 2013/10/07 16:20:16 UTC
[Bugzilla] Vote and issue
Hello list,
Some issue seems to be without possibility of vote.
Like: https://issues.apache.org/ooo/show_bug.cgi?id=99429
Why?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [Bugzilla] Vote and issue
Posted by Herbert Duerr <hd...@apache.org>.
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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [Bugzilla] Vote and issue
Posted by Kay Schenk <ka...@gmail.com>.
On Mon, Oct 7, 2013 at 7:56 AM, Rob Weir <ro...@apache.org> wrote:
> On Mon, Oct 7, 2013 at 10:43 AM, Herbert Duerr <hd...@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-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@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
Re: [Bugzilla] Vote and issue
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 10/07/2013 04:56 PM, schrieb Rob Weir:
> On Mon, Oct 7, 2013 at 10:43 AM, Herbert Duerr<hd...@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.
+1
Confirming an issue only because of a specific number of votes was
reached doesn't sound correct, IMHO, as it doesn't take into account
technical details / dependencies / etc.
> 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.
Due to the high number of issues in Bugzilla, 5/2 is nowadays a bit too
low, IMHO.
So, 10/10 is OK but I would accept also other values - if they are
obviously not too high, like 100/100.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [Bugzilla] Vote and issue
Posted by Rob Weir <ro...@apache.org>.
On Mon, Oct 7, 2013 at 10:43 AM, Herbert Duerr <hd...@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.
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.
-Rob
> Herbert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [Bugzilla] Vote and issue
Posted by Herbert Duerr <hd...@apache.org>.
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.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org