Internal CollabNet Issue SC90.

accepting for support.

This issue has two parts:
1) The help information about voting does not reflect the complexities
of voting (PCN4829)
2) Users are only permitted to vote in the jini component, although
many more components are set up for voting (PCN4830).

*** Issue 13969 has been marked as a duplicate of this issue. ***

Raising the priority on this issue.

part 1) above, the help portion of the issue, was fixed as part of our
maintenance process last month.

Changing the Summary line.

Re: Part 2) (assuming this is the revised issue), 
what is the detailed description and scope of the problem, 
as well as information regarding how to duplicate the problem?

Bill, see the internal issue (PCN4830).  Looking at this problem via
the "components" and "my votes" pages (for iz admins).

Status Summary: It may be a one-time problem with the "components"
page, as opposed to a problem with voting.  Yan, try changing the
voting parameters for a component on the the "components" page, to see
if it will fix the problem.

Sorry, Jan, for the typo in your name :(.

Jan, are you still having problems setting up voting?

I'm closing this issue.  Jan, if you are having further problems with
setting up voting, please reopen this issue.

Jan, please comment on whether voting is working for you now ?

So, I originally created this bug only as documentation bug (the
voting worked OK in the bug create time). I did not change the meaning
of the bug (to Voting does not work in many modules), but I will look
at it ASAP and reopen it if there will be problem.

OK, now I've done some research and I cannot see why this bug
was closed at all ?

As Taska stated there are 2 parts to this issue, and neither
are/were fixed!

1) The documentation URL that Jan lists still displays the 
(erroneous) text that Jan quotes;

2) Nothing at all was done about the voting issue itself !!

Why on earth was this closed ?!

Regarding issue 1) - this document should either be available to IZ
admins for editing, since they are the ones who determine how voting
works (ie 1 vote per issue or more); or it should be made generic,
saying something like "depending on how voting is set up, you might
be able to vote bla bla".

Regarding issue 2) - based on Taska's comment that the number of votes
might need to be *changed* to be noticed (even though they are 
set correctly anyway), I tried this and it seemed to work.  Marek and 
I have just gone through the process of changing each and every 
components "Votes/user" field.  Extremely frustrating and time 
consuming, considering there was nothing wrong with the already
set up values.

I think Marek and I have just fixed part 2 of the immediate problem
here, but I'm reopening as I'd like assurances that new modules will 
not need their votes/user updated even if it was set correctly when
created ?

Also we need a resolution to part 1.

This was a migration issue, a one-time problem.

In terms of the documentation, I don't see that Jan quotes anything. 
However, the reason Jan can only make one vote per issue, is that he
has it *set* that way.  If he wants to change it, he can- he's an
issuezilla admin.

To clarify, Jan has it set so that only one vote total can be voted
per issue, over all users.  Therefore, each user can only vote once
per issue.  This can be changed in the "components" page.

This is a strange subtle point (almost always, when people turn on
voting, they allow many more than 1 votes per issue) and I have
pointed it out to the documentation team.

As a first thing, I have to say "sorry" because I did not state it clear in 
original report. The only thing I wanted to achieve was to make 
consistency between reality and doc via changing the doc (because I 
believed that allowing only one vote/per user/per issue was "as wanted")).

For chaning the behaviour myself - OK, I maybe belong to some domain 
group, that can change it, but I do not think I have real right to do it (in 
real, I am sure that when the privileges will be corrected, I will not have 
right to change issuezilla itself). So, I can not change allowed number of 
votes per issue. And I do not want to, as I do not have any idea how is 
issuezilla working.

If new modules will have some reasonable voting set (I did understand 
Taska's comment this way), is possible to change the documentation to 
be consistent with voting (as it works now) and close this bug?

Jan: sorry, I was confused.  The *other* Jan (jchalupa) is the
IssueZilla admin and can make changes.  I'm copying him on this issue.

I have re-opened the internal issue asking our documentation group to
review the verbage on the documentation issue.

I'm changing the summary of this issue again and moving it back down
to P3.

To quote Jan's quote : "On this URL, it is said that I can give more 
than one vote on an issue."  This is wrong, and this is not fixed
(despite this issue being marked fixed!).

Please re-read my proposed soloutions for issue 1.

We are well aware of how voting works.  The point is that A) the
docs don't reflect how voting is currently set up, and B) that if 
*we* (NB/IZ admins) can configure voting, then either *we* need to 
be  able to update the docs to reflect our changes, or the docs need
to be very generic and cover all bases.

Sorry Jack- didn't understand, didn't actually mean to be pedantic.  I
would say he paraphrased what the vote help says.  I will quote it
below for clarity.

"The number of votes allocated to you are yours to use in any manner
you choose. You may vote for the same issue more than once. You can
cast multiple votes for one issue and one vote on multiple issues. No
matter how you choose to use them, you are llimited by the number of
total votes you have available."

The help specifically says that you are limited by the number of total
votes you have available.  It seems apparent to me that if that number
is 1, then you have only 1 vote to apportion how you wish.  However, I
could see that someone might become confused.  I have submitted a
request for clarification of this help doc.

Since Jan didn't actually *quote* the original help doc in his
original request, only paraphrased it, it was not apparent that we
have changed this doc to make it more clear; however, apparently it is
still not clear enough, and I have asked for it to be changed again.

Further notes (I missed one parameter above).  From the internal issue:

The documentation 'does not reflect the fact that in the "component"
editing page, you can choose "Votes per user" and "Max votes per
issue" seperately.  If, for example, "Votes per user" is 20, and "Max
votes per issue" is one, then the user can only vote once per issue,
and he gets confused.'

This documentation change is targeted for the SC1.2 release.

Created attachment 2854 [details]
proposed change to documentation

Jan & Jan, does the new documentation look comprehensible and accurate
to you?  If so, this change will be included when we upgrade NetBeans
to SC1.2.

Is voting stuff relevant to fixing the issues?

For example, 100 people vote for issue # xxxx,
and 0 for issue # yyyy,

Do module owners responsible for fixing issue xxxx first, 
even if it is more complex one?

Target milestone was changed from not determined to TBD

This has been fixed in SourceCast 1.2. We can verify or 
reopen if necessary when we upgrade.

verified in 2.6.