Apache OpenOffice (AOO) Bugzilla – Issue 65006
The issue management for votes is faulty
Last modified: 2008-06-14 07:16:06 UTC
It would be safe to assume that issues get higher priority based on the following- (a) Impact on the product (OOo). (b) Number of votes given by users. (c) "first-come-first-served" basis (i.e., older issues taken up first). (d) Defects would be taken up before enhancements. This issue will explain how this principle is defeated because of faulty management of the issuetracker. Different aspects are discussed in this single issue for continuity's sake. If you want, I will split them into separate issues. 1. Faulty tallying of votes: Issues are supposed to be prioritized by the number of votes they get. But the thanks to a faulty management of the issue tracker, votes are not collected properly, as explained below: Many issues are found to be duplicate of other issues and closed. Some are copied into other issues and then closed. In many of such cases, the closure is done a long time after initialization. In the meantime, the issue attracts a lot of votes. When the issue is closed, however, these votes are not transferred to the other issue. Once a visitor votes for an issue, he wouldn't keep a watch on it, and if that issue is copied into a new one (or closed as a duplicate), he is not likely to transfer his vote to the new issue. IssueZilla certainly does not do this automatically. Let me illustrate this with an example: Issue 2977 had 59 votes. Issue 33851 has only 37. So, assuming that these votes are mutually exclusive, issue 33851 should have 59+37=96 votes as on today; making this one of the top-ranking issue. Against that, we have a paltry 37 votes there! So, when copying an age-old issue into a new one, we spoil its ranking by splitting the votes. 2. Loss of age-weightage: In some cases, issues are combined into a new issue. All the older issues are closed. This is a dangerous practice because the problem appears to be freshly raised. Also, the original "observed in-" information is reoplaced in a recent version. In our example, issue 2977 is >4 years, but the transformed issue appears only 9 months old! So, all other things being equal, issues older than that will now have their turn ahead of this one! 3. Enhancement vs defect: The issue handlers classify a problem as enhancement as "defect" only if OOo does NOT "work as designed". Compare that with some internationally recognized standards: >> www.isixsigma.com defines a "defect" as (a) Any type of undesired result is a defect, or (b) A failure to meet one of the acceptance criteria of your customers. >> ISO 9000 defines a defect as "nonfulfilment of a need for a stated or intended use". Further, it defines that this need can be stated or implied. The problem with such classification is that the urgency to tackle the problem is lost when it is identified as an enhancement. There are many issues where the user may lose data, yet it is identified as an enhancement. An example is Issue 2977 or Issue 33851, where a defective behavior can overrite data; resulting in unforeseen changes in the spreadsheet. This issue is treated as an "enhancement". Another example is when the behavior is not defined under some circumstances. Such issues are classified as "enhancement" even if the user stands to lose data!
This is more or less a DUP of Issue 22519. @raindrops: For details that might not be covered by Issue 22519, please open a new issue! *** This issue has been marked as a duplicate of 22519 ***
.
Well, that issue talks about adding all votes when issues are declared "Duplicate". This issue describes TWO other issues clearly stated. In other words, this issue is NOT a full duplicate of that other issue. If 1/3rd of this bug is already reflected somewhere else, why close this entire issue? It will unnecessarily raise the number of bugs in the system! Just deal with the rest! Rephrase if necessary, and split it if you want. The responsibility of the user is to prove his point with data. If something is not clear to you, you should ask for clarification WITHIN a reasonable period. IMO 7 months is too long a time. I got this response after a gap of 7 months. Now am I MARRIED to this issue? Do I have to take care of it till death do us part?? Do you really expect all users to monitor their issues lifelong? After a long delay, the handler should own the issue himself, rather than throwing it back to the initiator again: The initiator may have walked away after all that time! Even if he sticks around, he may no longer have the required supplementary data. In that case you would close the issue, thus nullifying the effort put by the reporter. And suppose you don't get anyone to split this issue. What then? Will you close this issue? Who's the loser in that case?
We can not handle different problems within one issue. The first enhancement request is a DUP of an other issue, so I will close this issue again after I limited the subject to the "votes problem". For the resting listed problems please see my following comments. @raindrops New issue for every problem! Please divide your requests (as you offered in your report) into separate issues, so that decisions concerning each of your requests can be found separately. I do not see good prospects that your points 2 and 3 might be considered in near future. 1. Faulty tallying of votes --------------------------- duplicate of issue 22519. 2. Loss of age-weightage ------------------------ I don't believe that "seniority" has much importance for the developers when they decide what issue should be fixed for next. If you believe that consideration of this could improve the bug fixing process, please state that plausible in a new issue. 3. Enhancement vs defect: ------------------------- I do not see that difference to common use of those terms. If you believe that a new definition could improve the bug fixing process, please state that plausible in a new issue. *** This issue has been marked as a duplicate of 22519 ***
The Issue you raised has been marked as 'Resolved' and not updated within the last 1 year+. I am therefore setting this issue to 'Verified' as the first step towards Closing it. If you feel this is incorrect, please re-open the issue and add any comments. Many thanks, Andrew Cleaning-up and Closing old Issues ~ The Grand Bug Squash, pre v3 ~ http://marketing.openoffice.org/3.0/announcementbeta.html
As per previous posting: Verified -> Closed. A Closed Issue is a Happy Issue (TM). Regards, Andrew
Andrew, I doubt whether you ever read through this issue. Probably this is a software-generated post attached to ALL old issues. The "sweeping-under-carpet" has reached a new low. I am absolutely disgusted with how Bugzilla is misused in dealing with the problems. It has sunk so low that now it is nothing more than forum posting. The issuezilla is meant to detect problems and track them to closure. While the users do the first part, the Sun/OOo staff should do the rest. So why ask the originator to raise another issue? Just clone the topic into a new issue and start off discussion on it! The Issuezilla management policy (DOES IT EXIST??) needs to be changed.
Dear 'raindrops', Thank you for taking the time to reply. I will try to answer some of your important concerns as briefly as possible. I also want to assure you that it was not my intention to cause you any distress! (1) Andrew, I doubt whether you ever read through this issue. Probably this is a software-generated post attached to ALL old issues. - Correct (partly). The first stage - stirring up User feedback- was automated based on reasonable criteria. In this case, you had over 1 year to argue against the 'resolved' status and change it to 're-opened'. The second stage (as you can see) will require QA time to go through every response and individual issue. The reason step 1 was automated, is that there are thousands (~5k issues) which are old and gathering dust. It is much more efficient if the original reporter takes responsibility for their Issue and closes it if possible, to minimize this effort. It is about distributing rather than centralizing the task load. (2) The "sweeping-under-carpet" has reached a new low. - This is the exact opposite. The point of my actions is to bin old and irrevelant Issues and highlight long outstanding ones. Remember, even when an Issue has been closed it will always be available, so your comment just doesn't stand. (3) While the users do the first part, the Sun/OOo staff should do the rest. So why ask the originator to raise another issue? Just clone the topic into a new issue and start off discussion on it! - And here is the key point(s)... Sun (company) does not equate to OOo (community). OOo doesn't have staff (as such), just keen volunteers such as myself - and yourself! You have just as much responsibility as a custodian for the bug report you raised, as any other member of the OOo community. If you bothered to raise an Issue, it is reasonable to assume you may be the only person in the world who cares about it. I also want you to note that I have acted as an individual, just keen to try and improve the current IssueTracker situation. (4) The Issuezilla management policy (DOES IT EXIST??) needs to be changed. - There are fairly clear guidelines and policies. This brings us back to your original Issue. Reviewing rainerbielefeld's QA (spot-on as usual), this Issue is clearly a duplicate and breaks the principle policy of IssueTracker: One Problem One Issue. This is will be Closed. Please fell free to email me if you have any further questions, to avoid treating IssueTracker like a forum... Regards Andrew *** This issue has been marked as a duplicate of 22519 ***
Closed.
Well, let us assume a scenario: Someone stops me at office and tells me, "Your tie is askew and your fly is open." Is it logical for me to say- "Unfortunately you clubbed two unrelated issues!! The only way I will close my fly is you will have to tell me again. I know what's wrong, but policy is policy!" You see, there is a risk that the guy will not bother again. He would not be so passionate and caring about my closing the fly. Worse, he will simply go around and tell others what a lout I am. So a policy-maker in OOo community has to wake up to this problem and explain to the front-ending QA guys NOT to bounce valid inputs in the name of policy. Just thank the public for bothering at all, and take care of the ISSUE at hand!