On Tue, Mar 19, 2013 at 9:43 PM, Guenter Marxen <guenter.mar...@googlemail.com> wrote: > Hi, > > I have a little bit the impression, that Rob and Jürgen are not > understanding, what is meant. > > There is no demand, that special issues shouldt be resolved asap. > There is no demand, to give a date or release, when the issue is resolved. > > There is only the wish, issues not to reset or to delete, that users find > _important to make their work with OpenOffice easier and better_. > > The fact, that a user does not repeat his comments or requests each year, > does not mean, that he is no longer interrested in the issue. > > It was good practice in the "old" community (as far as I know), that issues > and comments and votes never were reset or deleted. And it would be > contra-productive to begin with such "customs" in the "new" community. > > There is no missunderstanding (at least on my side) about this project, the > ressources and possibilities and I read (or remember) not any comment by > others in this thread, that could be interpreted in this sense. > > But to mention it here, Rob: There was one developer who "cared" for 5608 in > 2008 (see "down under"). >
Hopefully we agree on more than we disagree about. Specifically, I hope we agree that: 1) User feedback is important. If we're not producing what users want then we're in trouble. 2) Getting accurate user feedback is more important than getting just any user feedback. In other words, if user feedback is important, then it is also important that we get user feedback in a way that is accurate, unbiased and reflective of typical user preferences. 3) Knowing what users want *today* is more important than know what their preferences were 10 years ago. This is living project not an archive of trends and fads from 2002. Although we might all have *opinions* on what user preferences are today, and we might even *believe* that they is unchanged over the last decade, this *belief* is an inadequate substitute for actually measuring what user preferences are today (Again, if it is important, then it is important to do it right). 4) The rank ordering of preferences is what counts, not any absolute vote count. Whether the #1 issues has 4000 votes, 400 votes or 40 votes, does not matter, provided the votes are representative and unbiased. 5) If user preferences in fact have not changed over the last decade then resetting the vote counts would have no effect on the rank ordering. We would quickly arrive at the same rankings, although there would be a different absolute vote count. But if preferences have changed then the ranks might be different. But either way, whether this confirms the past preferences or shows new preferences, this information is very valuable to have, more so than preserving a museum of historical votes. Hopefully we agree on the above. Given that, I believe the existing historical vote counts have strong methodological problems and are almost useful for determining what user preferences actually are. Consider: Since 2002 we have received 9569 feature/enhancement requests. Of those 2747 received at least one vote. But that means that most of them, 71%, received no votes, not even from their original submitters. This suggests lack of awareness that voting was even possible. There is also evidence that many who voted were targeted by various lobbying efforts, via list or forum posts, or even blog posts, to "please vote for my issue". So high vote counts are the product of political efforts by project insiders, astroturfing more than actual typical user preferences. We know, from other feedback mechanisms, like Facebook, the users mailing list, etc., that the #1 feature request *today* is for an iOS or Android version of OpenOffice. We get requests like this every day, sometimes more than once day. Guess how many votes this request has in Bugzilla? Zero. Actually, this is a trick question. No one has even bothered to enter this as a feature request in Bugzilla. But that proves the point. We have extremely strong reason to believe that the Bugzilla vote counts do not reflect user preferences today. The Bugzilla vote counts, in the large view of things, are extremely thin. around 400 votes for the top issue over a decade for a product that gets 1 million downloads a week. We have the ability to get real user feedback, in a much more representative way. Why would we be satisfied with the 10 year old dubious vote counts a small number of project insiders? In summary, I'm trying very hard to make user feedback count for something in this project. But that means we need good data. I could use your help, rather than your resistance, to encourage the project to gather accurate, representative, unbiased feedback. Again, I see no reason to fear this. If your particular issue is truly something users want, then it will rise to the top in any unbiased survey right? And if it is not something users want, then we do a disservice to the project if we falsely prop it up based on decade old votes. I hope you would agree. User feedback is important, so let's make an effort to do it right! -Rob > Some further comments inline: > > Am 19.03.2013 17:15, schrieb Jürgen Schmidt: >> >> On 3/19/13 5:04 PM, Rob Weir wrote: >>> >>> On Tue, Mar 19, 2013 at 11:19 AM, RGB ES <rgb.m...@gmail.com> wrote: >>>> >>>> 2013/3/19 Rob Weir <robw...@apache.org> >>>>> >>>>> On Mon, Mar 18, 2013 at 9:21 PM, Guenter Marxen >>>>> <guenter.mar...@googlemail.com> wrote: >>>>>> >>>>>> Am 18.03.2013 19:05, schrieb Dave Fisher: >>>>>> >>>>>>> There is no consensus here to eliminate or reset the votes. Some who >>>>>>> are >>>>>>> more in touch with users have stated that it would be harmful. I >>>>>>> trust >>>>> >>>>> their >>>>>>> >>>>>>> judgement. >>>>>> >>>>>> ... >>>>>> >>>>>> Look f.e. at issue 5608 >>>>> >>>>> >>>>> I suppose it depends on how you define "important". > > > There is nothing to suppose because I defined it: Working better on "...long > texts with (many) references". > That's surely far from being 'important for everyone'. > > > Since issue 5608 >>>>> >>>>> was entered, back in 2002, we've fixed 36054 issues in Bugzilla. >>>>> (31064 defects, 3839 enhancements and 1151 features). So that many >>>>> bugs were fixed, or enhancements/features implemented, while issue >>>>> #5608 was not. I don't know how you define "important", but to me >>>>> something that is behind 36,054 other items is as close to unimportant >>>>> as I can imagine. > > > Your arguing is not reasonable, because importance is never defined by mere > numbers. I accept, that "important" issues are not touched because of lack > of ressources. But f.e. the second mentioned issue 11901 is a great > disadvantage and "incompatibility" compared with the leading word processor. > > >>>>> Remember, what things a developer chooses to code on is also a vote. >>>>> They vote with their time. I count that kind of vote very highly, >>>>> since it is backed up by actions. Those 36054 issues were important >>>>> enough for someone to actually invest their time into fixing it. > > > They "vote" relying on their "preferences" and "likes". > > A developer, who never writes long texts with many references may say 5608 > is unimportant and I accept his opinion. But perhaps in short time, a new > volunteer really understands the issue and likes to work on it. > > >>>>> I don't mean to offend anyone by telling them that their issue is not > > > I am not extremly touchy. ;-) > >>>> Rob, I think you are missing the point here. I agree that the choice of >>>> a >>>> ... >>>> >>>> I insist: "we cannot do that now" is not the same of "we will not do >>>> that >>>> simply because nobody did it before". > > > RGB ES, you are right. Thanks. > > >>> But this is not a case of "we don't have someone right now to work on >>> it". It is not a case of "not today, but maybe next week". This is >>> not a case of "Sorry, we can't fit it in this release, but maybe we'll >>> do it in the next release." What this is is a case where no one, >>> absolutely no one, zero, zip, nada, gar nichts, nobody has cared to >>> deal with the issue in over a decade. That screams out UNIMPORTANT. > > > Strange logic and false. That only screams out, that there was (or remained) > nobody, who understood the function or who had the time to work on it. > > But see comment #38 by Mathias Bauer (StarDivision/Sun, 2008), who "cared" > and targeted 5608 to 3.x. The reason why it was not resolved then, seems > clear to me. > > >>> Remember, there is such thing as false hope. And if ever there was an >>> example of false hope it is someone hoping for a decade old issue in >>> Bugzilla that has been passed by by thousands of other issues. > > > Strange logic. I'm not in a sentimental mood. But resolving enhancement > issues like 5608 and 11901 would be a valuable improvement for a not so tiny > group of users (f.e. at universities and alike). > > But you are completely right, for the "tiny text writers" these issues are > "not important", they even do not need Writer. (Are this the target users of > AOO?) > > >> I believe this thread will not bring any new information and we should >> probably let die it. >> Issues with votes are seen still as valid by some people and so let >> these issues in BZ as they are. We should not give any guarantee that an >> issue with many votes will be fixed in a future version. We should >> better communicate that votes are one instrument to express additional >> demand for an issue or RFE that developers potentially take into account >> to set their own priorities. >> >> I don't see that we can do more now but we should watch these issues to >> ensure that we don't miss some really important ideas or bugfixes. > > > As said, I wish only, that such issues are not reset or deleted. There's > nothing to do. > > But it would be wonderfull, when all hard work is completely done and AOO is > finished for eternity then you resolve issues 5608 and 11901... > > > -- > Grüße > > Günter Marxen > > > --------------------------------------------------------------------- > 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
